Skip to main content

Tegata

A Tegata (手形) is the declarative policy: a small JSON document that is the canonical source for one authorization policy. It answers "who may do what, to which resource, under which conditions" in one place, instead of as scattered if statements.

You do not enforce a Tegata directly. You compile it (see Authorization Compiler) into the code that runs. The Tegata is what you read and approve; the compiled output is what executes.

A real Tegata​

{
  "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 } ]
    }
  ]
}

Each rule reads like a sentence: an employee may view an invoice they submitted; a manager may approve an invoice up to ¥500,000. The evaluation semantics are fixed and non-configurable — conditions within a rule are AND-ed, same-effect rules are OR-ed, deny overrides allow, and with no matching allow the answer is deny. You express intent; you never wire up the resolution. See Tegata Schema for the full semantics and field reference.

Written by an agent, approved by a human​

A Tegata is small and declarative, so an AI agent can write it directly from a requirement and a human can review it as a diff:

  • The AI agent (or you) writes the Tegata from the requirement.
  • Sekisho inspects it at compile time and rejects dangerous ones.
  • A human approves it by approving its fingerprint (tegata_hash).

Same meaning, same hash​

The tegata_hash is computed over the meaning of the policy, not its byte layout. Human-facing metadata — descriptions, relationship labels, and the entire audit block — is excluded. So if an AI agent re-emits the same policy with rules or arrays reordered, or with reworded descriptions, the hash is unchanged: same meaning, same hash. A hash change always signals a real change in what is allowed. (Why approving the hash approves the running code: Authorization Compiler.)

audit.ambiguities: where the agent shows its work​

Natural-language requirements are ambiguous. When an AI agent turns "managers can approve invoices within ¥500,000" into a rule, it makes interpretation choices — is ¥500,000 exactly included? audit.ambiguities is where the agent declares them:

"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"]
    }
  ]
}

These notes are for the human reviewer. Because the entire audit block is non-canonical, it is excluded from tegata_hash and never compiled — it changes the review, never the decision. It is where an agent surfaces the assumptions you most need to check before you approve.