Policy as Code

Policy as Code is the practice of authoring AI-governance policy as a versioned, compiled, cryptographically signed artifact — rather than as hand-edited configuration scattered across services. policy-compute (service AP00019) compiles, signs, versions, and distributes those artifacts as Osyra's Pillar-4 control plane. Each consumer verifies and evaluates the bundle locally, so policy delivery does not add a synchronous service hop to its request path.

Consumer maturity is deliberately explicit. OME runs a verified OPA-WASM cascade live on its attested-memory operations. The Edge currently verifies, stores, hot-reloads, and evaluates AP00019 bundles in shadow mode; its embedded gateway.rego remains the authoritative allow/deny decision. POLICY_COMPUTE_REQUIRED=true can deny requests when the Edge has no valid signed bundle, but it does not make the shadow result authoritative.

The category framing mirrors AWS. IAM policies say what a principal may do; Service Control Policies (SCPs) say what the organization permits at all, as a guardrail above every account. Osyra already has the IAM half. policy-compute is the SCP half for AI: org-wide, workspace-wide, and resource-scoped guardrails, compiled into signed bundles and distributed uniformly for local evaluation. Each consumer's separately tested cutover determines whether that evaluation is authoritative or shadow-only.

Why it matters

Three properties make signed, compiled policy distribution worth the architecture:

• One authority, many consumers. A published version carries a signed, hash-pinned compiled module. Consumers that receive that version can verify the exact payload before loading it, independent of their implementation language.
• Change propagates without redeploys. Publishing a new policy version flips a pointer and pushes a signed update to subscribed consumers; each verifies it and can hot-swap it in place. The current service has a real push stream; platform-wide, multi-replica propagation-time evidence is still a deployment gate rather than a public latency guarantee.
• Authorship and enforcement are decoupled in time and place. Policy can be authored, reviewed, and compiled centrally, then enforced locally and independently at each point of use.

The load-bearing decision: control plane, never the request path

The single most important architectural fact about policy-compute is that it is never on the request path. Enforcers never make a synchronous call to it to decide a request.

        CONTROL PLANE (slow, infrequent, central)
  policy author ─▶ policy-compute
                    author → validate → compile(rego→WASM)
                    → resolve cascade layer → sign manifest → store
                    → publish to subscribed enforcers
                         │ push (signed bundle updates)
        ─────────────────┼──────────────────────────────────────
        DATA PLANE (fast, per-request, decentralized)
          ┌──────────────┴──────────────┐
   AP00001 EDGE                    AP00011 OME
   verify/store/hot-reload          verify/cache signed cascade
   evaluate WASM in shadow          evaluate WASM live for
   gateway.rego enforces            attested-memory operations
   optional no-bundle deny gate     fail-closed in that gate

Three consequences fall out for free:

• No request-time dependency. A policy-compute outage cannot add latency to a request, because no request ever calls it.
• Fail-static distribution, scoped fail-closed evaluation. Consumers retain their last-known-good verified bundle if distribution is interrupted. OME's attested-memory gate denies when its live cascade cannot make a valid decision. At the Edge, the embedded policy remains authoritative; required mode additionally denies if no valid signed AP00019 bundle is present.
• Payload identity is verifiable across languages. A published bundle binds the compiled module hash, so Go and Java consumers can prove they loaded the same version's payload. That does not imply every consumer currently uses the bundle as its authoritative decision.

How it works

policy-compute is a deterministic compile-and-distribute pipeline. The same canonical source plus the same pinned toolchain yields the same source digest and compiled WASM payload. The complete signed envelope is intentionally version-specific: its version, creation time, scope, key version, and parent layer binding can change its bytes even when the authored policy does not.

A signed bundle is a (manifest, payload) pair. The manifest is the signed object; the compiled payload is hash-bound by it. Load-bearing manifest fields:

| Field | Purpose | |---|---| | cascade_level | platform, org, or workspace | | scope_id | empty for platform; the org id; or the workspace id | | wasm_sha256 | SHA-256 of the compiled payload — the binding between manifest and payload | | source_sha256 | SHA-256 of the canonicalized authored source (provenance) | | compiler_toolchain | pinned build identity for reproducibility | | abi_version | the ABI version the payload targets (enforcer-compatibility contract) | | parent_layer_sha256 | the payload hash of the layer above, forming a verifiable cascade chain |

The policy cascade

Policy composes in three layers — platform, org, workspace — and each layer is signed by its own authority. This is the security crux: a workspace admin's key can sign only the workspace layer; it can never forge an org or platform guardrail.

Each layer's signature is checked against the authority allowlist for that layer's cascade_level and scope_id. Workspace-layer enforcers carry both the workspace id (the scope) and the parent org id (for cross-layer authority checks), and an enforcer's identity is established by its mTLS peer certificate so it can only ever request bundles for its own scope.

How Policy as Code relates to the rest of Osyra

The Edge gateway (AP00001) and memory engine (AP00011) both consume signed bundles, but at different enforcement stages. The Edge loads and evaluates its cascade asynchronously for shadow comparison while gateway.rego makes the enforced decision. OME uses the verified cascade as the live policy decider for its attested-memory gate; that statement does not extend to every OME RPC. The frontend authoring surface (AP00010) calls the control plane to validate, preview, compile, and publish policy. policy-compute ships the artifact, never the per-request verdict.

Scope and roadmap

Org/workspace authoring, validation, deterministic compilation, signing, versioning, and push distribution are built in V1. OME's attested-memory path is the current live enforcement integration. Edge authoritative cutover, broader OME operation coverage, and multi-replica propagation evidence remain gated work. Remote platform authoring is deliberately unavailable until the operation-bound N-of-M approval contract described above is implemented and verified. The WebAssembly bundle format is the primary distribution mode; a raw-Rego distribution mode for policies needing non-WASM built-ins is reserved in the manifest and on the roadmap. Resource-layer cascade overlays beyond workspace, staged/canary rollout of a bundle version, and additional enforcers are roadmap items.