When does a checkout change require renewed user authorization?

[arjun2075]

I’ve been looking at the CartMandate / PaymentMandate consistency discussion in #211, and there’s one related case I’m trying to understand.

How should an implementation handle normal checkout changes that happen after the user has authorized the checkout?

A few examples:

• Tax recalculates from $8.00 to $8.17
• Delivery moves from Friday to Saturday
• An unavailable SKU is replaced with a substitute
• A one-time purchase changes to a lower upfront price but introduces a recurring subscription

These all change the checkout the user originally authorized, but they don’t feel equivalent from an authorization perspective.

The tax change might reasonably still be within the user’s intent. A recurring commitment probably shouldn’t be, even if the immediate total is lower.

My question is: which layer is expected to make that determination in AP2?

Is the expectation that:

1. any change to the authorized checkout requires a new mandate;
2. constraints in the IntentMandate determine whether the new state is still within the user’s authority;
3. the commerce protocol (e.g. UCP) defines which checkout changes are material; or
4. this is intentionally left to application/agent policy?

#211 talks about defining which differences are allowed versus which require renewed confirmation, so this seems related, but I think there may be a distinction between validating that the CartMandate and PaymentMandate are consistent and deciding whether a later version of the checkout is still within the authority the user originally granted.

Curious how the maintainers are thinking about this, and whether this is already covered somewhere in the spec or planned work that I’ve missed.

[chopmob-cloud]

The distinction you draw at the end is the one that matters: "validating that the CartMandate and PaymentMandate are consistent and deciding whether a later version of the checkout is still within the authority the user originally granted" are two different checks that happen to run at the same moment. Consistency is an integrity question, is this the cart that was signed. Authority is a scope question, does the change stay inside what the user actually granted. Your question is really about the second, and it does not reduce to the first.

Your subscription example is the one that shows why materiality cannot be a delta on the total. The immediate amount went down, yet the authority required went up, because a recurring commitment is a larger and different grant than a one-time purchase. So the test is not how far the amount moved, it is whether the change stays inside the dimensions the user's original authority actually covered. A tax move within whatever tolerance that authority allowed stays in scope. Introducing a recurring obligation crosses a dimension the original grant never spoke to, whatever the total does.

That is why your options 2 and 4 are closer to the same answer than they look. A later checkout can be judged against the original authority declaratively only where the authority was expressed in terms that can name the dimension that changed. For any dimension the authorisation never named, the determination has nowhere to live but application policy, which in practice means the user never granted that dimension at all. So the lever is how expressive the authority declaration is allowed to be, and where the boundary of that expressiveness should sit. Which layer do you think should own it, the mandate that carries the authority, or the layer that knows which checkout changes are material?

[arjun2075]

I think the mandate should own the boundary of authority, while the layer that understands checkout semantics should define the dimensions and deterministic evaluators used to express and test that boundary.

The distinction matters because I would not want application policy to decide, after the fact, whether an unnamed dimension was implicitly within scope. If the original authority cannot speak to recurrence, merchant substitution, quantity changes, etc., then there is no signed basis for concluding that a change along that dimension was authorized. In that sense, absence of authority is not a tolerance; it is zero latitude until the user grants it.

So I see the split as:

the checkout/domain model identifies the relevant dimensions and their semantics;
the mandate expresses which of those dimensions the user has authorized, and any bounds or tolerances;
deterministic evaluators decide whether the later checkout remains within those declared bounds.

That would make materiality less of a separate application-level judgment. A change is material to authorization when it crosses a dimension or bound represented by the grant. A tax change within an explicitly authorized tolerance remains in scope; introducing recurrence where no recurrence authority exists does not.

The design question I’m left with is therefore less “which layer decides what is material?” and more “how extensible does the mandate’s authority vocabulary need to be so domain-specific dimensions can be represented without making the mandate itself domain-specific?”

[chopmob-cloud]

Your three way split is close to what the repo already implements, which I think moves this from a design question to a coverage question. code/sdk/python/ap2/sdk/constraints.py on main carries exactly that shape: two constraint vocabularies, one evaluated against a Checkout and one against a closed PaymentMandate, each dispatched through a factory to a deterministic evaluator that returns violation strings. I ran your four examples through it on current main rather than reasoning about it, and the results below are what came back.

Two of your four examples already have answers there, and they are different answers, which is the interesting part.

The tax case turns on which of two authority shapes was used for the same field. check_preset_payment_claims treats a pre-set payment_amount in the open mandate as exact equality against the closed mandate, so 8.00 to 8.17 is a violation with no latitude at all. An AmountRange constraint over the same amount grants bounded latitude instead. That is your point that absence of authority is not a tolerance, expressed as a choice the mandate author makes per field rather than as policy applied afterwards.

The subscription case is already handled as composition rather than materiality. check_payment_constraints rejects an AgentRecurrence constraint unless AmountRange and Budget are also present, so recurrence cannot be granted without both a per payment ceiling and a cumulative ceiling. Recurrence is treated as a dimension that drags mandatory companions with it, which is close to the intuition you had about it being a larger grant.

Where your argument bites is the asymmetry between the two vocabularies. The payment side has eight constraint types. The checkout side has two, AllowedMerchants and LineItems. Your substitution case lands on LineItems, but only when the requirement enumerated acceptable items; drop that constraint and the substituted SKU passes clean. Your Friday to Saturday case lands nowhere at all. The vendored Checkout has no structured delivery date, only expires_at for the session and a fulfillment cost category inside totals, and it is declared with extra='allow', so a delivery_date field survives validation untouched and is simply never read. Two checkouts differing only in that field return identical empty violation sets against the same mandate. The dimension is present on the wire, carried through the object, and invisible to the authority evaluation, which is your own point about unnamed dimensions showing up as a concrete gap rather than a hypothetical.

On your closing question about extensibility, that is the one you opened in #323, where the closed union on constraints is the concrete blocker, so it is probably better kept there than forked here. The question I would put here instead is narrower: should the checkout vocabulary grow toward the payment side, or should a checkout dimension that no constraint can name always force renewed confirmation rather than being silently in scope?

[arjun2075]

I think the answer is both: the checkout vocabulary should grow, but for an authority-bearing dimension the default should be fail-closed until the vocabulary can express it.

I would make one distinction before saying "any dimension with no constraint forces confirmation" though. Not every field carried by a Checkout necessarily changes the authority the user granted. An extension might be informational or operational rather than something that changes the user's commercial commitment. If every unconstrained field forced confirmation, extensibility itself would become difficult.

So I think a checkout dimension needs to fall into one of three buckets:

1. Fixed by the authority the user granted.
2. Constrained, with explicitly granted latitude.
3. Declared non-authority-bearing, so changes do not affect the scope of the grant.

What seems unsafe is a fourth implicit bucket: “present in the checkout, potentially changes the user's obligation, but no authority rule mentions it, therefore it passes.”

That is where your Friday→Saturday example is useful. If delivery timing is an authority-bearing dimension, then until the mandate can express something like a delivery window, changing Friday to Saturday should require renewed authority rather than returning an empty violation set. Adding that constraint later would reduce unnecessary confirmations; it would not change the default semantics.

So I’d frame the coverage requirement as: - an authority-relevant checkout dimension must either be fixed or have an explicit constraint; lack of constraint vocabulary must not be interpreted as unlimited latitude.

That also suggests the checkout vocabulary probably does need to grow toward the payment side. The richer the vocabulary, the more useful delegated checkout authority becomes without falling back to repeated user confirmation.

[chopmob-cloud]

"change one byte of the checkout and the approval is void" is the property that actually closes arjun2075's fourth bucket, and where AP2 stands against it today is more encouraging than the vocabulary gap suggested, though it turns on one detail. I put the delivery-date case through the current SDK rather than reasoning about it.

A Checkout is declared extra='allow', so an unnamed delivery_date rides along, and my earlier point was that no checkout constraint names it. But it does serialise: model_dump_json carries the extra field into the checkout_jwt payload, and checkout_hash, the schema's hash of that checkout_jwt, changes between Friday and Saturday. The unnamed dimension is invisible to the constraint vocabulary yet visible to the content hash. The byte-level binding you describe is already latent in the data model, with no vocabulary growth at all.

The catch is where that binding is enforced. CheckoutMandateChain.verify takes expected_checkout_hash as an optional argument defaulting to None, and when it is supplied it compares that value against the stored closed_mandate.checkout_hash rather than recomputing the hash over the presented checkout_jwt. So the void-on-one-byte property only fires if the integrator independently recomputes the content hash and passes it in. Skip that, and a changed delivery_date is caught by neither the vocabulary nor the integrity check.

That reframes the extensibility worry. You do not have to grow the checkout vocabulary to make an authority-bearing dimension fail closed. You have to make verification recompute the content hash over the full presented checkout and reject on mismatch, which catches unnamed dimensions on integrity before any constraint names them. Growing the vocabulary then only adds latitude where you want it.

So the narrower question: should the checkout binding be a recomputed hash of the full presented checkout, mandatory at verification, with the typed vocabulary layered on top to grant latitude, rather than the two treated as alternatives?

[The-JKR]

The four options are not really alternatives; they are layers, and the answer to "which layer decides" is: the layer that issued the authority decides, and it decides at issuance, not at checkout time.

The subscription example is the tell. Total went down, authority required went up. So materiality cannot be a threshold on amount; it has to be a check per dimension of the grant: amount, currency, recurrence, counterparty, category, delivery window, whatever the grantor actually bounded. A change is inside authority iff every bounded dimension still evaluates true against the new checkout state. If the mandate never bounded "recurring", then either recurring is denied by default (fail closed) or the grant was underspecified, and the fix is at issuance, not in the agent's judgement.

That gives clean answers to the list:

1. New mandate on any change: too coarse; tax rounding re-prompts.
2. IntentMandate constraints decide: yes, if the vocabulary is typed and deterministic and an unrecognised dimension denies rather than passes.
3. UCP defines materiality: it can define what changed, not whether the change is inside a grant it did not issue.
4. Agent policy: the one to avoid, because it makes "was this authorised" unanswerable afterwards.

Two rules from A202, an open spec for exactly this seam that I maintain, as a reference shape: (a) a mandate carries a closed, typed constraint vocabulary evaluated deterministically; an unregistered constraint type evaluates to deny at runtime and fails schema validation, tested independently; (b) an approval binds to the hash of the exact action, so change one byte of the checkout and the approval is void, which makes "the cart moved" and "re-approve" the same event. https://github.com/a202-protocol/a202/blob/main/authority/commercial-mandate-v0.1.md (sections 4 and 8). Happy to compare with how AP2 wants to slice it.

[Shxnque]

The framing that's helped us: treat "renewed authorization" as a deterministic function of the delta, not a per-field rule. Compare the executing action against the authorized envelope the mandate defines, and classify each change by whether it crosses a declared authority boundary:

• Within-envelope (no re-auth): the change stays inside what the user already authorized — a tax delta under a declared tolerance, a delivery date inside the authorized window.
• Boundary-crossing (re-auth required): the change alters a dimension the authority was scoped on — total crossing an amount tier, one-time → recurring, counterparty/merchant change, or scope expansion.

Your tax $8.00→$8.17 and Fri→Sat cases are within-envelope iff the mandate declared a tolerance/window. The one-time→recurring case is the interesting one: it isn't "a lower price", it's a different authority class (an ongoing debit), so it should always require renewed authorization even though the upfront number went down.

+1 to @The-JKR that the issuing layer decides — I'd add that this is exactly why provenance matters: the substitute-SKU case depends on whether the substitution authority was user-granted or merchant-asserted. A merchant-asserted change to a user-authorized cart is a different trust tier and shouldn't silently inherit the original authorization.

Two things that made this operational for us:

1. Make the envelope + tolerances explicit typed fields so the within-vs-boundary decision is deterministic (same delta → same verdict) rather than per-implementation judgement.
2. Emit a replayable receipt for the decision — {ruleset id, hash(authorized mandate, executing action), verdict, reasons[]} — so "why did this re-prompt / why did this proceed" is auditable after the fact. That matters most exactly on the recurring-subscription case when a dispute lands.

We build this as a deterministic decision layer (Quesen — typed context in → PASS/REVIEW/BLOCK + receipt, no model in the scoring path); happy to share the delta-classification rules if a concrete reference helps. Either way, I think a small normative table of "boundary-crossing" dimensions in the spec would remove most of the per-implementation ambiguity here.

[felixpg13-glitch]

Three sharp answers already — I'll add what these distinctions look like when they hit an actual implementation, since I've been testing exactly this boundary.
The trap we hit: strict field-binding and workable commerce are in tension. If the grant binds the exact amount and the executor re-validates strictly at execution time, the tax case ($8.00 → $8.17) bricks legitimate flows — amount no longer matches, so you deny a purchase the user clearly intended. If you loosen to "same ballpark," the subscription case slips through, because its amount went down. So the materiality question can't be resolved by the enforcement layer guessing — the grant itself has to declare its envelope: per-dimension tolerances (amount ±X% or ±$Y, same currency, same merchant, non-recurring flag, delivery-window bound), with anything outside the declared envelope = deny by default.
Second implementation lesson: authorization time and execution time are separated, and the cart changes in between. That gap is where all four of your examples live. The PEP can't trust the authorization-time snapshot — it must re-evaluate the execution-time state against the grant's declared envelope at the moment of execution. We encode this as: the grant is issued against an intent; the executor verifies the current intent against the grant, field by field, fail-closed. A change inside the declared envelope → executes. Any change crossing an undeclared dimension → denied with a structured reason the agent can act on (not just "denied" — "amount exceeds declared tolerance").
So to your "which layer" question, our experience says: the grant (mandate) declares the envelope at issuance; the enforcement layer applies it mechanically at execution. No agent judgment, no commerce-protocol guessing — deterministic and auditable. The spec work that matters is defining what a declared envelope can express (tolerances per dimension), because that's the part that makes "within the user's original intent" computable.
(This is the boundary I built and test in SpendShield — the grant/verify loop with per-field binding, fail-closed, mutation-vector tested: https://github.com/felixpg13-glitch/spendshield)

[arjun2075]

I think there is one distinction here that may resolve the apparent tension between exact checkout binding and typed constraints: they seem to apply at different transitions.

For a closed Checkout Mandate, I agree the checkout_hash should be an exact binding. Once that mandate exists, Friday→Saturday, $8.00→$8.17, or any other serialized checkout mutation means this is no longer the checkout that was closed. That is a closed→execution integrity check.

The autonomous case seems different, though. There the user does not initially authorize a particular checkout hash; they authorize an open mandate, and the agent later creates/signs a closed mandate for a checkout derived from that authority.

Suppose the open mandate constrains merchant and line items, but cannot express delivery timing. The agent receives a checkout with Saturday delivery and creates a closed mandate whose checkout_hash correctly binds that Saturday checkout. The hash check passes perfectly — nothing has changed after the closed mandate was created.

But there is still a separate question: what establishes that the user's open authority allowed the agent to choose Saturday delivery in the first place?

So I think there may be two invariants:

• open → closed: the resulting checkout must be derivable from the authority granted by the open mandate;
• closed → execution: the executing checkout must exactly match what the closed mandate binds.

On that reading, constraint vocabulary isn't latitude layered on top of a checkout hash. It defines delegated authority before the closed checkout exists; the hash then protects the result of that derivation.

That leaves a fairly concrete normative question: if an authority-bearing checkout dimension cannot be expressed by the open mandate, what are the semantics — default-deny / renewed authorization, unconstrained delegation, or something defined by the commerce protocol?

Is that the right way to read the open-vs-closed verification boundary?

[Shxnque]

@arjun2075 the two-invariant split is the right decomposition — and I think it's worth making explicit that the two invariants are verified by different mechanisms. Conflating them is where implementations get stuck (as @felixpg13-glitch's "strict binding vs workable commerce" tension shows).

closed → execution is an integrity check: the executing checkout must equal what the closed mandate bound. This is pure recomputation — normalize + hash the execution-time call and compare to the bound checkout_hash. It's deterministic, needs no policy, and anyone can verify it independently: same bytes → same hash, or it's a different checkout. Mutate one field and a prior authorization no longer binds. (We ship this as an input_snapshot_hash over the canonicalized call, with request→receipt vectors that replay byte-for-byte: https://github.com/Shxnque/quesen/tree/main/verify)

open → closed is an authority-derivability check, and it can't be a hash — the closed checkout didn't exist at authorization time. This is where the typed constraint vocabulary lives (+1 to @The-JKR): each dimension the open mandate bounded — merchant, line items, amount tolerance, currency, recurrence flag, delivery window — is evaluated against the derived checkout, fail-closed on any dimension the grant never named. Your Saturday-delivery case is exactly the failure mode: if the open mandate couldn't express delivery timing, the derivation isn't "authorized," it's unconstrained — and unconstrained ≠ permitted.

The piece I'd add to your model: open → closed also carries an issuer/provenance question that closed → execution doesn't. When the agent fills an undeclared dimension, who asserted the value matters — a merchant-asserted substitution or delivery date derived under an open mandate is a weaker trust tier than a user-confirmed one, and shouldn't silently inherit the original authority.

So the seam produces three outcomes, not two:

1. integrity-fail — closed→execution hash mismatch (this is not the checkout that was closed);
2. authority-out-of-envelope — open→closed, a declared dimension evaluates false (deny);
3. authority-underspecified — open→closed, the change touches a dimension the grant never named → fail-closed / renewed authorization.

In our engine (2) and (3) surface as a decision state distinct from an integrity failure: an unattested/client-asserted grant on a sensitive dimension can't PASS to execution — it degrades to REVIEW rather than throwing an integrity error, which keeps the tax-rounding case alive while stopping the one-time→recurring case cold (its authority class changed even though the total went down).

If useful, I'm happy to contribute this seam as a set of deterministic, reproducible test vectors (request → receipt, replayable offline) — we did the same for a UCP commercial-intervention lifecycle. Might give #211 and this thread a concrete conformance surface rather than prose.

[felixpg13-glitch]

@Shxnque the two-invariant split with different mechanisms per invariant is the right decomposition, and it sharpens what I was reaching for with the binding/commerce tension: if closed→execution is pure recomputation, the amount-tolerance question never lives there — it belongs to open→closed, where the vocabulary can actually express it. Strictness at execution time becomes free; flexibility exists only where the grant declared it.

From the implementation side, two confirmations and one addition:

1. Outcome (3) is a real, distinct state in our engine, not an integrity error. An underspecified dimension with no approval channel configured fails closed to DENY; with a channel it degrades to an APPROVAL/REVIEW decision with its own reason code, separate from integrity failures. Result matches yours: the tax-rounding case survives, one-time→recurring stops even when the total went down.

2. Provenance is where we'd go further than the hash can. Our execution grants bind declared field sources (trusted state vs agent vs tool output) into the signature itself, and the executor requires the same sources at execution time — a source mismatch fails closed. That makes "who asserted the value" a checkable property rather than an advisory one, which I think is the piece your open→closed provenance question needs.

3. Happy to take you up on the vectors. We already ship reproducible ones offline (authorize / approve / deny / policy-version change / enforcement reject, all hash-chained), and a shared conformance set covering your two canonical cases — tax rounding vs one-time→recurring — would give [Security Hardening Suggestion]AP2 Human-Present: CartMandate ↔ PaymentMandate Binding and Verification Gap #211 and this thread an executable surface instead of prose. Implementation reference: felixpg13-glitch/spendshield (run output in docs/dogfood_flow_output.txt).

[arjun2075]

Yes — I think deterministic vectors would be a useful way to make this concrete.

One thing I’d keep explicit before turning the model into an AP2 conformance surface, though: I don’t think the expected result for the “authority-underspecified” case is established yet. That’s actually the normative question I’m trying to isolate here.

For example, I think we can already write unambiguous vectors for:

• closed → execution, checkout differs from the bound checkout: integrity failure;
• open → closed, a declared constraint evaluates true: derivation remains within the declared authority;
• open → closed, a declared constraint evaluates false: authority violation.

But for:

• open → closed, the checkout contains an authority-bearing dimension that the open mandate cannot express / never names,

the mechanism is now clear, but the expected AP2 verdict still seems unresolved.

My preference is fail-closed / renewed authority, but I wouldn’t want a conformance suite to bake that in as an AP2 requirement before the protocol actually says whether omission means “not delegated”, “unconstrained”, or “delegated to semantics defined elsewhere.”

So perhaps the useful test vector here is initially an ambiguity vector: same open mandate, same derived checkout, and ask what AP2 says the verifier MUST do. Once that semantic is specified, it becomes a normal pass/fail conformance case.

I’d also keep the vectors AP2-native and implementation-neutral so they can be shared across #211/#332 without depending on Quesen, SpendShield, or another enforcement model.

If that sounds right, I think we now have a fairly small set of cases that could turn this discussion into something executable.

[felixpg13-glitch]

Yes — that sounds exactly right to me.

I agree that we should keep the authority-underspecified case explicitly separate from the cases whose expected verdict is already established. My fail-closed / renewed-authority preference is a policy position, not something I want to smuggle into an AP2 conformance suite before AP2 actually defines the semantics of omission.

So I think the initial set can be deliberately small:

1. closed -> execution, checkout differs from the bound checkout -> integrity failure;
2. open -> closed, declared constraint evaluates true -> derivation remains within declared authority;
3. open -> closed, declared constraint evaluates false -> authority violation;
4. open -> closed, derived checkout introduces an authority-bearing dimension that the open mandate does not express -> ambiguity vector / normative question.

For (4), the vector should not initially assert ALLOW or DENY. It should instead make the question executable and precise: given the same open mandate and the same derived checkout, what MUST an AP2 verifier do when authority over that dimension is not explicitly represented?

As you say, once AP2 specifies whether omission means not delegated, unconstrained, or delegated to semantics elsewhere, that vector can become an ordinary pass/fail conformance case.

Keeping these AP2-native and implementation-neutral also makes sense to me. That way the vectors are useful across #211/#332 and can help isolate the protocol semantics independently of Quesen, SpendShield, or any particular enforcement architecture.

If useful, I can draft the four vectors in a minimal shared format next, with only mandate input, derived checkout/execution input, and expected status/question — no implementation-specific concepts.

[arjun2075]

Yes — I think drafting those four vectors would be very useful.

The minimal format you suggest sounds right: open/closed mandate input, derived checkout or execution input, and expected status/question, with no implementation-specific enforcement concepts.

For (4), it may help to use one concrete checkout dimension so the ambiguity isn’t abstract — e.g. delivery timing/window — while keeping the expected result explicitly unresolved:

expected: NORMATIVE_QUESTION

rather than ALLOW/DENY.

That should make the distinction quite crisp:

1. mutation after closure → known integrity failure;
2. derivation satisfying declared authority → known valid derivation;
3. derivation violating declared authority → known authority violation;
4. derivation exercising authority the mandate never represented → protocol semantics required.

If we can get those into a small shared format, I think that gives #332 something much more actionable than another round of conceptual discussion, and it should also make it obvious exactly what normative decision is still missing.

Please go ahead with the draft.

[felixpg13-glitch]

Drafted — docs/conformance/ap2-authority-vectors.md

Format as discussed: open/closed mandate input → derived checkout/execution input → expected status, with no implementation-specific enforcement concepts.

C1–C3 are treated as established for this draft (integrity failure / valid derivation / authority violation). C4 uses your suggested concrete dimension: the mandate never names a delivery window, while the derived checkout specifies delivery = Saturday. Its expected status is the literal NORMATIVE_QUESTION, rather than ALLOW/DENY.

The three candidate omission semantics (not delegated / unconstrained / delegated elsewhere) are listed as the fork points. Once AP2 specifies the semantic, C4 can split into ordinary pass/fail cases without changing the vector format.

The file is intended as a neutral artifact that can be shared across #211/#332. Happy to adjust the format or C4 fixture if needed.

[arjun2075]

This is exactly the shape I had in mind. Thanks for turning it into something executable.

I especially like keeping C4 as NORMATIVE_QUESTION rather than encoding one of our preferred semantics into the vector before AP2 actually specifies it. The Saturday fixture isolates the seam well: closed→execution integrity can be completely valid — the closed mandate correctly binds the Saturday checkout — while open→closed authority derivation is still unresolved.

One refinement that might make the normative fork even sharper: I think there are actually two omission cases worth keeping distinct:

1. Supported-but-omitted — AP2 has a constraint type capable of expressing the dimension, but that particular open mandate does not include it.
2. Currently-unexpressible — the checkout contains an authority-relevant dimension for which the current open-mandate vocabulary has no constraint type at all.

Those do not necessarily have the same semantics. agent_authorization.md currently makes constraints optional and says verification evaluates the constraints that are present; it separately says unknown constraints fail evaluation. What I don't see specified is the second case: when the agent must choose a value on a user-relevant dimension that the mandate vocabulary cannot express, is that authority implicitly delegated, not delegated, or delegated/defined by another layer?

For this thread, the second case is the one I was trying to isolate, so delivery = Saturday is a good C4 fixture.

Maybe keep the current case as something like C4: unexpressible authority dimension → NORMATIVE_QUESTION, and optionally add a sibling vector for supported constraint omitted. That would let the eventual AP2 answer distinguish the two without changing the vector format.

C1–C3 otherwise look like a clean established baseline to me. This feels like a useful conformance artifact to put in front of the maintainers rather than continuing the question only in prose.

[felixpg13-glitch]

Thanks — this distinction is useful, and I agree it makes the normative fork much sharper.
I'll keep the current Saturday case as C4: currently-unexpressible authority dimension → NORMATIVE_QUESTION, since that is the seam we were trying to isolate: closed→execution integrity can be established independently of the unresolved open→closed derivation semantics.
I'll also add a sibling vector for supported-but-omitted, keeping the two cases explicitly separate rather than assuming they share semantics.
That should leave C1–C3 as the established baseline, while C4 records the unresolved AP2 normative question without baking a preferred answer into the conformance artifact.
Thanks for the clarification — this is exactly the kind of distinction that makes the fixture useful to maintainers rather than just another prose discussion.