Tegata

A Tegata (手形) is Ninka's declarative authorization specification. One Tegata file defines one authorization policy: who may perform which actions on which resource, and under which conditions.

Instead of scattering authorization intent across application if statements or generated policy code, Ninka gives that intent one explicit document that a human can review.

A Tegata is not executed directly. Ninka deterministically compiles its canonical authorization content into Rego, and the pinned OPA build turns that Rego into the WASM the runtime evaluates.

A Tegata example

{
  "tegata": "0.1",
  "policy": {
    "id": "invoice-access",
    "description": "Invoice view / delete / approve"
  },
  "rules": [
    {
      "id": "allow-employee-view-own-invoice",
      "effect": "allow",
      "subject": { "roles": ["employee"] },
      "actions": ["view"],
      "resource": { "type": "invoice" },
      "relationships": [
        {
          "label": "own_submission",
          "subject_attribute": "user_id",
          "op": "eq",
          "resource_attribute": "submitted_by"
        }
      ]
    },
    {
      "id": "allow-manager-approve-invoice-within-limit",
      "effect": "allow",
      "subject": { "roles": ["manager"] },
      "actions": ["approve"],
      "resource": { "type": "invoice" },
      "conditions": [
        { "key": "resource.amount", "op": "lte", "value": 500000 }
      ]
    }
  ]
}

The first rule says an employee may view an invoice they submitted. The second says a manager may approve an invoice whose amount is at most ¥500,000.

The evaluation semantics are fixed rather than configurable: constraints within one rule combine with AND, rules of the same effect combine with OR, deny overrides allow, and the default result is deny when no allow rule matches. See Tegata Schema for the exact fields and semantics.

The review surface for human and AI-assisted authoring

A Tegata can be written by a person or proposed by an AI agent. The responsibility boundary is the same either way:

• the author maps the requirement into Tegata;
• Sekisho checks the structural and semantic properties Ninka can determine mechanically;
• a human reviews whether the resulting Tegata actually expresses the intended authorization requirement;
• the toolchain turns that accepted specification into executable artifacts.

Ninka does not maintain a local approval flag and does not certify that the business requirement itself is correct. Human acceptance belongs to the surrounding development/change-control process. See Review Authorization.

tegata_hash identifies the canonical specification

tegata_hash identifies the canonical authorization content used for compilation.

Before hashing, Ninka excludes non-canonical review metadata and normalizes ordering that does not carry authorization meaning. For example, changing policy.description does not change the hash, while changing a canonical rule field does.

The hash is not proof that a human approved the policy, and it is not the hash of the generated Rego or WASM. Those generated bytes have their own artifact hashes.

This separation lets the artifact chain answer different questions precisely:

Tegata specification  → tegata_hash
Rego bytes            → rego_sha256
WASM bytes            → wasm_sha256

See Authorization Compiler and Generated Files.

audit.ambiguities keeps interpretation visible

Natural-language requirements often require interpretation. For example, “managers can approve invoices within ¥500,000” requires a choice about whether the boundary value is included.

audit.ambiguities is where an authoring process can surface such choices to the reviewer:

"audit": {
  "ambiguities": [
    {
      "code": "assumed_interpretation",
      "message": "Interpreted \"within ¥500,000\" as resource.amount lte 500000 (integer, JPY). The boundary 500000 is included; use lt to exclude it.",
      "related_rules": ["allow-manager-approve-invoice-within-limit"]
    }
  ]
}

For tools that structure ambiguous natural-language requirements into Tegata, the specification requires interpretation choices to be surfaced rather than silently embedded in the canonical rules.

The audit block is review context, not authorization semantics. It is excluded from tegata_hash and does not affect the generated decision logic. See Tegata Schema for the allowed ambiguity codes and exact constraints.