Architecture

How PolicyFuse works

PolicyFuse separates policy authorship, action intent, semantic consensus, deterministic consequence derivation, and authorization currentness. The contract evaluates meaning; it does not custody assets or execute downstream actions.

The LLM does not choose ALLOW or DENY directly. Validators agree on an exact ordered rule-state vector; contract code derives the outcome deterministically.

The four durable layers

Policy

An immutable versioned rule set with a fingerprint, lifecycle state, allowed action types, and bounded lifetimes.

Intent

An exact action core, consumer, action type, clarification, deadline, policy fingerprint, and canonical digests.

Decision

Validator-agreed PASS / FAIL / UNKNOWN states for every rule, plus the deterministic resulting decision.

Authorization

Created only for ALLOW and bound to exact policy, intent, requester, consumer, action digest, rule vector, and validity window.

Consensus-to-consequence binding

Contract code checks lifecycle and deadline deterministically.
Required policy and intent fields are copied from storage into ordinary memory.
The leader evaluates every rule against the exact frozen action.
Validators independently evaluate the same frozen inputs.
The proposed normalized rule vector must match the validator's own result exactly.
Only after consensus returns does contract code derive the consequence and write state.

No tolerance crosses the authorization boundary. Missing rules, duplicates, malformed states, validator divergence, or consensus failure never become ALLOW.

Deterministic derivation

ALL PASS

ALLOW

Every rule is PASS.

ANY FAIL

DENY

At least one rule is FAIL.

ANY UNKNOWN

REPAIR_REQUIRED

No FAIL, but at least one UNKNOWN.

Repair without action substitution

A repair creates a new immutable intent revision. The policy binding, requester, consumer, action type, canonical action core, and action-core digest stay fixed. Only clarification/context and the deadline can move within policy bounds. The prior repair-required intent becomes historical.

Authorization currentness

Historical authorization existence is intentionally insufficient. A downstream consumer should call is_authorization_current_for with the expected consumer and action-core digest against durable final state.

Currentness includes policy lifecycle, fingerprints, intent/decision/authorization identities, time validity, exact consumer, exact action type, action-core digest, full intent digest, and rule-vector digest.

Explicit non-goals

No payable entrypoint or GEN/token custody.
No escrow or arbitrary downstream contract execution.
No claim of atomic single-use consumption across another contract.
No assumption that a policy owner is fair, lawful, or benevolent.
No claim that semantic interpretation is mathematically objective.