The policy check at batch start authorized work at that point, not a standing grant to publish hours later. Reading, generating, storing, and disclosing to a partner are different effects. A summary can be computed under one rule and become ineligible for that destination before delivery. I would stop new partner publication for this customer immediately at the authoritative sharing boundary, then inspect the exact timeline and the already visible outputs. We cannot unsend something a partner fetched before revocation took effect.

Each output needs provenance: source case IDs and revisions, tenant, classification, generation run and model version, the intended audience, policy decision and revision used at generation, and a stable publication operation ID. The publisher performs a fresh authorization against the customer, destination, content class, and current policy just before it commits each item or batch partition. The decision is made by a service with current authority, not by the model text or by replaying a cached allowed boolean. Open Policy Agent's decision logs include bundle revisions for evaluated decisions, and its status API reports an active bundle revision. Those fields help explain a decision. They do not by themselves guarantee that every region has seen the latest revocation.

We need an effective-time and propagation contract. If revocation is acknowledged to the customer at noon with a promise of no new partner disclosure, the publisher must fence stale regions before that acknowledgement, or block publication until they catch up to a required policy epoch. If the product contract allows a bounded propagation delay, state it and measure it. Do not silently call a delayed decision “current.” If the policy service is unreachable, partner publication waits. Internal generation may continue only if that processing remains authorized and the outputs stay in a protected staging area. Do not conflate cancellation of disclosure with deletion of the drafts.

Now the queue contains old publish messages. A consumer must not trust the policy result embedded in the message. It can use it to explain why the item entered the queue, but it rechecks eligibility at execution. Use the operation ID and version to prevent a retry from publishing twice, and mark denied items as held or discarded according to retention policy. A worker resuming after an outage needs the same check. A bulk atomic publish would make the boundary simpler if the external destination supports it, but a series of individual partner API calls does not become atomic because we named it a batch.

For already visible outputs, build the exposure set from publisher receipts, destination acknowledgements, access logs, and policy epochs. Some provider outcomes may be unknown. Reconcile those rather than assuming a timeout means the partner never received the content. Ask the partner to revoke or remove accessible copies where the contract allows, notify the customer truthfully, and follow the incident process for disclosure after the promised cutoff. Historical audit should retain enough to explain what happened under the permitted retention rules without making the summaries newly available to the partner.

What if the noon change was merely a new disclaimer requirement, not withdrawal of sharing? The action may still be permitted after rewriting or revalidating the output against the new rule. Do not throw away 80,000 summaries by reflex, and do not publish stale text by reflex either. Policy changes have different semantics. The success condition is a commit-time decision for each real disclosure, a clear rule for in-flight effects, and a customer-facing account of any output that crossed the boundary.