feat(spec): enforcement_mode gains "declared", for policy nothing evaluated

[imran-siddique]

Both framework adapters hit this independently today, which is what makes it a vocabulary problem rather than an adapter problem.

The gap

enforce, advisory and silent all assert that something evaluated the policy — enforce acted on the result, advisory did not, silent acted with the operational logs suppressed. There was no value for a policy that is named and bound into the signed record with nothing evaluating it.

That is not a corner case. An agent framework has no policy engine, so a record built by observing a LangChain or LlamaIndex run has a policy the operator declares and no evaluation of it anywhere. With three values such a record has to claim an evaluation that never happened.

Both adapters refused to default the field and documented that advisory overstates a bare run. Honest, and it still leaves every framework-produced record marginally untrue — which belongs in the vocabulary, not in two READMEs.

declared

The weakest value, and never a default:

• A producer that evaluates policy MUST NOT use it.
• A consumer MUST NOT read it as evidence that any rule was checked.
• A verifier appraising for enforcement SHOULD treat it as it treats an absent enforcement claim.

It says only: this is the policy the deployment states it was operating under.

Compatibility

Additive to a closed enum in the model and in both JSON schema copies — a test pins that adding a value did not turn the field into free text, and monitor is still rejected by both.

Same one-directional consequence as origin: a verifier older than this release rejects a record carrying declared. Producers should not emit it until their consumers are current.

246 tests, ruff and mypy clean.

Follow-up once released: both framework adapters can default to declared instead of refusing, which is the first time either of them will be able to fill that field truthfully without the caller thinking about it.

🤖 Generated with Claude Code

[solloek369-arch]

One narrow clarification on silent across the existing lineage.

#19 raised the original concern around silent. #28 then clarified it as allowing the governed action while suppressing operational logs and preserving every would-have-denied decision in the audit chain.

#143 later describes silent as having “acted” on the policy result. Current TRACE also describes it as “evaluated and enforced” in the schema, while §4.3 still specifies the audit/log behavior without explicitly stating the deny disposition.

So one narrow question:

policy decision = deny
enforcement_mode = silent

MUST the governed action be allowed or blocked?

Current cMCP allows a Cedar-denied call through in SILENT and projects that mode as TRACE silent.

Did #143 intentionally change the deny disposition established in #28, or is “acted” / “enforced” only meant to distinguish evaluated silent from declared?

I’m not assuming either answer; I just want to pin the intended semantics.