[signet-ded9d4] docs(apas): separate each level's requirement from one vendor's implementation

[jamestexas]

Draft — this is the start of the v0.4.0 restructuring, not the whole of it. signet-ded9d4 requires the split be validated against a working second implementation (signet-96252e), which hasn't been built yet. Opening now so the shape can be argued before that work starts.

The defect

Every level stated a portable Requirement, then listed bullets — previous_chain_hash, dispatch manifests, bridge certificates, a shared CMS/Ed25519 primitive, ACP request_permission — in the position readers take as the criteria.

An implementer could not tell which lines they had to satisfy and which merely narrated how we did it. That is what makes APAS unimplementable by anyone who hasn't built our stack — not parochial properties, parochial prose.

The change

Each level now carries core properties (L2.1–L2.5, L3.1–L3.4, L4.1–L4.5), each with a stated falsification, and the original bullets are retained verbatim as a named reference profile. §2.0 gives the reading rule and forbids a core property from naming an algorithm, envelope format, protocol, namespace, predicateType, product, or file path — if it can't be stated without one, it belongs in a profile.

Why now: a second implementation exists (new §7.7)

An independently built agentic reconciler framework, whose unit of work is a key reconciled to convergence rather than a dispatch. It satisfies L2 while failing most of L2's bullets — and by the property that actually matters, an externally certified signing identity rather than a key held by the same component that writes the attestations, it is stronger than the profile that defined the level.

A conformance scheme that scores that as non-conformant is measuring the wrong thing.

Its other finding, which recurs at every level: it has the evidence and lacks the attestation. Run traces go to telemetry unsigned; input digests live in a resume-control record. Nearly everything L4 asks for is already captured and none of it is attested.

Two new properties, both learned rather than designed

L3.3 — bounded, declared, default-deny capabilities. Generalizes ACP request_permission. A runtime permission boundary and a declarative capability set are two encodings of one property; the declarative form is preferred because it is default-deny by construction — a tool absent from the host's callback set doesn't exist in the model's tool list, so there's no prompt to fatigue a human into accepting and no approval path to social-engineer. A runtime boundary that defaults to allow on timeout or missing policy does not satisfy it: the property is default-deny, not "a decision happens". Advisory annotations are explicitly not a boundary.

L4.5 — outcome distinguishable from completion. Taken from that second implementation, which documents at the type that committing a result is no evidence work succeeded, because executors steer a stuck model into submitting a degraded one. An attestation recording only completion is correctly signed and materially misleading — the worst combination, because it survives verification. We did not have this property and should have.

Deliberately not in scope

• The predicate-as-profile work (signet-ded9d4's original body) — needs the demo first
• Any namespace or predicateType decision
• L1, untouched

Section cross-references checked; §2.0 and §7.7 both resolve.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NbcVvbUMkJHvSXbz1MMw5n