Spec gap: Art. 50(1)/(3) disclosure is runtime enforced by AGT but produces no attestable evidence

[FaresMallouli]

Section 9.1.2 (added in PR #277) correctly states the manifest has no field for Article 50(1)/(3) and that AGT's agent_os.transparency interceptor enforces it at the tool-call boundary and is the current answer. I traced that interceptor (agent-governance-toolkit, agent_os/transparency.py) and confirmed it's real: it blocks tool execution until confirm_disclosure or acknowledge_emotion_recognition is called for a session. But that enforcement produces no durable evidence, no hash, no signature, nothing outside the running process. An auditor asking whether a specific deployment actually delivered disclosure has no record to check, only source code to trust.

I'd like to propose an 11th manifest artifact, transparency_policy, that declares pre-deployment whether Art. 50(1)/(3) applies and binds a hash of the active interceptor configuration into the signed manifest, the same way policy_bundle binds Cedar policy today. This doesn't move disclosure delivery into the manifest, that correctly stays a runtime concern, but it makes the configuration tamper-evident rather than just trusted. Happy to scope this further as a fellowship proposal if there's interest.

[imran-siddique]

Verified both halves, and the gap you name is real.

§9.1.2 says what you quote, and I checked the AGT side rather than taking it: agent-governance-python/agent-os/src/agent_os/transparency.py exists with its own test file, so the interceptor is genuinely the current answer rather than a plan.

The timing is what makes this worth acting on. §9.1.2 records Article 50 as applying from 2 August 2026 and as "the only EU AI Act obligation in force against agent deployments today". Three weeks in force. Everything else in section 9.1 is deferred to 2027 or 2028.

And your framing is the one that matters. The section already tells implementers they must not read the manifest as evidence of Article 50 compliance. What you are pointing out is that the runtime enforcement leaves nothing else to read either: an auditor asking whether a specific deployment delivered disclosure has source code to trust and no record to check. Enforcement that produces no evidence is the thing this project exists to fix, and finding it inside our own compliance mapping is the right kind of embarrassing.

Status, so you are not guessing

Labelled policy: take-internal. A new manifest artifact is normative spec text, and under GOVERNANCE.md#who-may-author-normative-text that needs an organisational sponsor accountable for the requirement. That is a provenance rule about who answers for a MUST, not a judgement on the proposal or on you. It stays open, the substance goes through review here, and a maintainer carries any resulting spec change. You will get the outcome either way.

Also labelled fellowship, since you offered.

Direction, since you asked whether there is interest

There is. One thing to consider before scoping an 11th artifact.

The manifest currently defines eight artifacts.* entries, and each is a hardware-bound commitment to something that exists at deployment time. A ninth would be a structural change, and every implementer inherits it.

trace-spec solves an adjacent problem with a references block: a registered rel, an id, a resolver, an optional digest and retention. It commits to the digest of something held elsewhere without pulling the thing itself into the record, and §3.1.2 rule 3 makes the limit explicit, a reference says where a fact is, not that it is true. That gives you the tamper-evidence you are after, on the interceptor configuration hash, without a new top-level artifact and without claiming the manifest evidences delivery.

Worth scoping both and saying which you think is right. If the answer is genuinely a new artifact, the argument for it will be stronger for having ruled out the smaller one.

What stays out either way: disclosure delivery itself, which you already scoped out correctly. The manifest should never be readable as evidence that a natural person was actually informed.

One factual note for the scoping. Art. 50(2) and 50(4), the synthetic-content marking duties, are recorded in the same table as "Tracked for a future revision" with a different reason: a mark any party can strip does not survive the machine-readable requirement. If your proposal only covers 50(1) and 50(3), say so explicitly, because a transparency_policy artifact reads as though it covers all of Article 50.

[FaresMallouli]

Scoped both. My answer is that references is right for the runtime half and cannot carry the pre-deployment half, and I don't think a new artifacts.* binding is the way to close the remainder either.

On the smaller option

Registering a new rel is genuinely cheap. rel is Annotated[str, Field(min_length=1)] in models.py and minLength: 1 in the schema, not a closed enum, and the CHANGELOG says so directly: a new relation is a spec change and not also a schema change. The two-commit precedent (83c078d spec text, 4785fa7 schema and model) is a clean template. So the cost objection to references doesn't hold. If it were the right carrier, it would be nearly free.

What stops it

Timing. A TRACE record is emitted per execution. A manifest is a commitment an orchestrator can check before invocation. If the only tamper-evident binding of the transparency configuration lives in TRACE, admission control has nothing to read. The evidence exists only after the agent has already run, which is the wrong side of the boundary for a disclosure obligation that governs whether a person should have been informed at all.

The resolver, and I'd like your read on this one. docs/modules/tr-pol.md says the resolver for TR-POL-003 is supplied by the caller and never derived from the record, because a record that named its own resolver could name one that agrees with it. But in the references block, resolver is a required field inside the record. Rule 4 anticipates the self-asserted case by requiring omission, except that for a deployment binding its own interceptor configuration, the operator is the natural resolver. So either the entry gets omitted under rule 4, or the operator names itself and we're back inside the self-attestation gap this was meant to close. Am I reading the interaction between rule 4 and TR-POL's resolver stance correctly?

A note on the premise

Scoping this, I found there is no interceptor configuration hash yet to carry. TransparencyInterceptor.__init__ holds three plain fields, default_level, require_disclosure_confirmation, and emotion_recognition_notice, and nothing in the class or its tests computes a digest over them. The config_hash fields elsewhere in AGT are caller-supplied and not wired to it. So before the carrier question is answerable, something has to define what the hash is over, in what canonical form, computed by whom, at what point in the interceptor's lifecycle. I'd treat that as the first deliverable rather than an implementation detail, and I'd want it to build on whatever #338 settles for canonicalization rather than inventing a second answer.

Scope correction, taking your point

This covers Art. 50(1) and 50(3) only. 50(2)/(4) marking is a different problem with a different reason for being deferred, and I shouldn't have used a name that reads as covering all four. Something like disclosure_binding is narrower and doesn't overclaim.

On placement

The mapping table in §2 assigns artifacts #8 and #10 to top-level fields rather than artifacts.*, so a governance artifact living outside the bindings container already has precedent, and hitl_record is the closest sibling, being the other EU AI Act artifact. If a manifest-side commitment is right, a top-level field next to hitl_record seems more honest than a ninth binding, since this isn't a hardware-bound commitment to a deployed artifact in the same sense as the other eight.

---

One thing I couldn't resolve: I can't find TransparencyInterceptor registered in CompositeInterceptor or any chain. It appears in its own file, its own test, and the compliance checklist. Is it wired somewhere I'm not seeing?

[imran-siddique]

Your conclusion is right on both, and I think the reason for the first is stronger than the one you give.

references is the wrong carrier, structurally

You rule it out on timing and on resolver self-assertion. Timing holds and I will come back to it. But there is a prior reason that settles it regardless of either: §3.1.2 defines the block as assurance-neutral by construction.

A references entry is a pointer, not evidence. What the signature attests is that this record points there, not the truth of what it points at.

and

This block does not launder assurance in either direction. It cannot raise a record: nothing about naming your producer makes unattested evidence attested.

So a references entry can never be evidence of Article 50 compliance, whichever rel is registered, because the block's whole design is that it commits to the pointer and not to the target. Registering disclosure-configuration would produce a record that says "there is a transparency configuration over there" and attests nothing about what it says or whether it was in force. For a disclosure obligation, that is the wrong shape of statement, not merely an insufficient one.

Which means you were right to test the cost objection and right that it fails. rel is not a closed enum and a new relation is cheap. The carrier is wrong for a reason that price does not touch, and finding that out by pricing it first was the correct order to do it in.

On timing, agreed and it is the second independent reason. A per-execution record cannot serve admission control, because the evidence exists only after the agent has run. For a disclosure obligation governing whether a person should have been informed at all, that is the wrong side of the boundary. The two reasons are independent and either alone is sufficient, which is worth stating because someone will later propose fixing one of them.

On the resolver, which you asked me to read

They are not in conflict. The two resolvers do different jobs and I can see why they read as the same one.

TR-POL-003's resolver is a verification authority. docs/modules/tr-pol.md refuses to derive it from the record because the record would then choose who checks it, and a record that names its own checker can name one that agrees with it. That is a real self-assertion hazard and the rule is right.

§3.1.2's resolver is a retention undertaking. It names "the party obliged to resolve id", alongside retention as the period they undertake to keep it resolvable. It is a statement about who owes you the ability to look something up later, not about who adjudicates whether it is true.

Naming yourself as the party who must retain an artifact is ordinary and non-circular. Naming yourself as the party who verifies it is the circularity TR-POL-003 refuses. So an operator naming themselves as resolver for their own interceptor configuration is fine under §3.1.2 and would still be refused under TR-POL-003's rule, and both are correct.

Rule 4's omission requirement is therefore not triggered by an operator resolving their own retention. That said, your instinct that something is off here is not wrong, it is just aimed one field over: the reason the entry would be useless is assurance-neutrality, not the resolver.

Where this leaves the ask

The manifest-side binding you want is a genuinely new obligation on producers, so it stays under policy: take-internal. That is a hold with a named gate, not a decline, and nothing above weakens the case for it. §9.1.2's own text is the argument: it tells implementers they must not read the manifest as evidence of Article 50 compliance, and Article 50 is the only EU AI Act obligation in force against agent deployments today.

What can move now, no sponsor needed:

• Documenting in §9.1.2 that the runtime enforcement produces no attestable artifact, and that this is a known coverage gap rather than a scoping decision. Stating a limitation the section already implies is not a new obligation.
• Writing down the two reasons references cannot carry it, so the next person does not re-derive them. That belongs in §3.1.2's own text more than in §9.1.2: "cannot carry pre-execution commitments, and cannot carry compliance evidence" is a general boundary and this is only the first case to hit it.
• The resolver distinction above is worth a sentence in §3.1.2 for the same reason. You are unlikely to be the last reader to hold it against TR-POL-003's rule.

Thank you for pricing the cheap option before rejecting it. That is the part that made this answerable.

[FaresMallouli]

Taking your framing on the first point. Assurance-neutrality settles it in a way timing doesn't, since it holds regardless of which rel is registered: the block commits to the pointer and not the target, so no relation makes it evidence of compliance. Timing is then the second independent reason rather than the main one, which is worth keeping distinct for the reason you gave: someone will eventually propose fixing one of them.

And thanks for the resolver read. I had the two conflated. A retention undertaking naming yourself is ordinary; a verification authority naming itself is the circularity TR-POL-003 refuses. Different jobs, same field name, and I doubt I'll be the last person to hold one against the other.

I'd like to take all three of the unblocked items.

The first is open now as #366: one paragraph in §9.1.2 stating that the runtime enforcement it names produces no attestable artifact, so the section's existing warning holds in both directions. Non-normative, no new field, no change to the Art. 50 table.

The other two belong in §3.1.2 rather than §9.1.2, as you said, and I'll open them together in trace-spec: the two reasons references cannot carry this, written as a general boundary on the block rather than as an Article 50 note, plus the resolver distinction above.