Skip to main content

Authorization Compiler

An authorization compiler turns a reviewable authorization specification into executable policy artifacts. In Ninka, that specification is a Tegata (手形).

Requirement
    ↓
Tegata                 human review surface
    ↓
Sekisho                mechanical checks
    ↓
Ninka compiler         deterministic transformation
    ↓
Rego + metadata
    ↓
pinned OPA build       reproducible execution build
    ↓
Execution Bundle
    ↓
Consumer Projection
    ↓
Ninka runtime
    ↓
Decision

The important boundary is not “AI versus no AI.” AI may help author the specification. Human review decides whether that specification expresses the intended authorization requirement, and the toolchain controls how the accepted specification becomes executable policy.

Tegata to Rego is deterministic​

The Ninka compiler deterministically transforms a canonical Tegata into Rego. The same canonical Tegata compiled by the same Ninka release produces byte-identical Rego.

That guarantee stops at Rego. WASM is produced by a separate OPA build step. Ninka pins the default OPA toolchain so the execution artifact can be reproduced under the same build conditions.

same canonical Tegata + same Ninka release
    → byte-identical Rego

same Rego + same pinned OPA toolchain/build contract
    → reproducible WASM

Ninka therefore does not claim that its compiler alone deterministically emits WASM.

Approval integrity: three separate claims​

The chain from "a human approved this" to "these bytes are running" is not one statement. It is three, and they must not be collapsed into one:

  1. the same tegata_hash means the same canonical authorization specification;
  2. the same Ninka release derives byte-identical Rego from that specification;
  3. the running artifact is bound to that specification by rego_sha256, wasm_sha256, and the build lineage that joins them.

Collapsing them produces the most common misreading of Ninka: that tegata_hash identifies the executed bytes. It does not. It identifies the specification a human reviewed. The artifact hashes carry that identity forward.

Specification identity and artifact identity are different​

Different identifiers answer different questions:

  • tegata_hash — which canonical authorization specification?
  • rego_sha256 — which generated Rego bytes?
  • wasm_sha256 — which execution-module bytes?
  • generated_by / opa_version — which Ninka and OPA releases produced the artifacts?

The first three are identities for different objects. generated_by and opa_version are provenance, not alternate identities for the specification.

The artifacts carry these facts forward so later stages do not have to re-derive upstream decisions independently.

The compiler derives. Artifacts declare. The runtime verifies and executes.

For example, the compiler derives the policy entrypoint. Generated metadata declares the binding between policy, Rego, entrypoint, and execution bundle. The runtime verifies those declarations against each other and against the module; it does not implement a second entrypoint-naming algorithm.

If the required bundle identities or bindings do not verify, the bundle is refused rather than partially trusted.

See Generated Files for the exact artifact fields and formats.

verify checks reproducibility, with explicit skips when it cannot​

ninka-authz verify starts from the current Tegata and toolchain contract and reproduces the source-derived state for comparison. When the pinned OPA toolchain is available, verification also rebuilds and checks the execution bundle and replays the required validation against WASM.

A fully checked green verification therefore provides reproducibility evidence for the generated state it checked. It does not mean a human approved the Tegata, and it does not establish parity with an earlier authorization implementation.

If the pinned OPA toolchain cannot be obtained at all, the CLI can report WASM-related obligations as explicit not checked skips instead of pretending they matched. Those skips are part of the result and must not be read as evidence that the skipped WASM obligations were verified. See CLI Reference for the exact success, failure, and skip behavior.

verify also does not inspect Git. Repository tracking policy and filesystem verification are separate concerns.

Validation does not ask the compiler to grade itself​

Ninka derives validation inputs from the Tegata, while an independent reference evaluator determines the expected decisions from Tegata semantics rather than from the emitted Rego. The generated WASM is then required to agree with those expectations.

This separation prevents the compiler from validating its output only against expectations produced by the same transformation being tested.

Validation still has a defined scope. It checks translation obligations Ninka knows how to derive; it does not determine whether the underlying business requirement was correct. Human review remains a separate responsibility.

OPA is a build dependency, not the request path​

OPA builds the executable WASM artifact. At runtime there is no OPA server or OPA network hop in Ninka's decision path. The application evaluates the verified bundle in-process through the Ninka runtime.

Ninka is therefore not another hosted authorization server and does not ask applications to call OPA for every request. Its role is to put a reviewable authorization specification and a verifiable compilation/build pipeline between authorization intent and application enforcement.

Consumer Projection is the application boundary​

The Consumer Projection is the generated application-facing module. It carries policy references, typed input contracts, the execution bundle, and the metadata the runtime needs to verify that bundle.

application code
      │
      ▼
Consumer Projection
      │
      ▼
Ninka runtime → ALLOW / DENY

The application still owns when to call authorization, which concrete resource is being authorized, how the input is constructed, and how the returned decision is enforced.

Authorization Reference is a view, not another authority​

The Authorization Reference presents the Tegata and generated state in a form humans can inspect and try interactively. It does not edit or compile the project and does not define a second authorization semantics.

If the specification changes after the last compile, LIVE mode reports the compiled state as stale and disables evaluation instead of treating old bytes as the current policy.

See also​