Data-Purpose Laundering Prevention: Execution-Finality for Preventing Cross-Domain Data Reuse

3.1. Self-Asserted Purpose Is Not Verifiable Purpose

Most deployed systems that reference "purpose" at all do so as a string carried in a token claim (e.g., a JWT claim, see [RFC7519]), an API parameter, or a log field. That string is written by the same party requesting access. A verification step that only checks whether the field is present, well-formed, or drawn from an enumerated list does not verify that the caller's actual operation matches the label -- it verifies that the caller knows which label to write.¶

3.2. Attestation Answers a Different Question Than Authorization

Remote attestation (see [RFC9334]) establishes that a piece of code is running in an expected state on expected hardware. It does not establish that the workload attested is authorized to perform a specific operation on a specific data object. A correctly attested enclave running an unauthorized computation is still an unauthorized computation; attestation and purpose authorization are orthogonal checks, and treating a passed attestation as implicit authorization silently collapses that distinction.¶

3.3. Derived Data Carries the Restriction, Not Just the Value

A value computed from restricted data (e.g., an income estimate computed from a home address) is not automatically free of the restriction that governed the source, even where the derived value contains none of the original data verbatim. Without deliberate propagation of source lineage to the derived object, a downstream consumer of the derived value bypasses every control placed on the source.¶

3.4. The Residual Limit: Plaintext Already Released

Once a protected value is legitimately released as plaintext to an authorized recipient, this architecture -- or any architecture operating at the request/response boundary -- cannot guarantee that the recipient will not copy, screenshot, or re-transmit that value outside the enforced path. Section 5.7 and Section 6 return to this point; it is stated here because any reader evaluating this document for what it does NOT do should not have to search for the admission.¶

5.1. Collection: Binding the Data Object to a Permitted Use

A customer provides a delivery address for a specific order. The address is stored as a protected data object. A separate, integrity-protected policy record binds that object to a single permitted workflow, operation, and recipient class, with an explicit disallowed-operation entry and an expiry:¶

   Data object: address-619
   Allowed workflow: delivery-order-842
   Allowed operation: obtain delivery destination
   Allowed recipient: assigned courier service
   Disallowed operation: advertising-profile enrichment
   Expiry: configured delivery-access deadline
   Policy version: 38

The party that will later compute an advertising profile is never given the address's decryption key or database credentials. If it were, every check described below would be enforcement theater -- bypassable at will by the party the checks are meant to constrain.¶

5.2. A Legitimate Request

The delivery service submits a Candidate Act:¶

   Read address-619, for order-842, send to assigned-courier-6,
   operation: obtain delivery destination

The PED checks this against binding records, not against the request's own claims:¶

A pass issues a short-lived Execution Handle scoped to this exact address, order, operation, and recipient; the Finality Sink releases the minimum necessary delivery data on presentation of that handle. Any check that cannot be completed -- a stale record, an ambiguous assignment, an expired policy version -- MUST be treated as a failed check. The PED fails closed by default; it does not proceed on missing or ambiguous evidence.¶

5.3. An Unauthorized Request

An advertising workload submits:¶

   Read address-619, operation: infer household income,
   destination: advertising-profile-database

Every check in Section 5.2 fails: the caller is not the delivery service, the operation is not the permitted operation, and the destination is not the permitted recipient. No Execution Handle is issued, no address is released, and no decryption authority is granted. The rejection occurs before the income computation begins -- blocking only the resulting advertisement, after the profiling computation has already run on the address, would not have prevented the unauthorized use; it would only have hidden its output.¶

5.4. A Relabeled Request

The advertising workload resubmits with a relabeled purpose field:¶

   Purpose: delivery, order: order-842

This does not change the outcome. The PED's checks are defined over the caller's authenticated identity, its destination, and its actual delivery-workflow authority -- none of which change because the request's purpose field changed. A caller that presents even a validly issued delivery Execution Handle from the wrong workload identity or toward the wrong destination MUST fail validation, provided identity and destination binding are actually enforced at the Finality Sink and not only at issuance time. Purpose, in this architecture, is a conclusion the PED reaches from verifiable relationships -- not an input the caller supplies.¶

5.5. A Request From Inside an Attested Enclave

Suppose the income-inference computation runs inside a hardware Trusted Execution Environment (TEE) that successfully attests its own integrity. A successful attestation establishes that the enclave is running the code it claims to run; it does not establish that the code is authorized to decrypt address-619 for this purpose. The PED still evaluates workload identity and requested operation against the same binding records, and an enclave running an income-profiling workload receives no authority to decrypt a delivery address it was never granted.¶

A caveat: if a broadly authorized enclave already holds unrestricted plaintext access to the address for an unrelated legitimate reason, an output-only Finality Sink cannot retroactively undo profiling computation that already occurred inside it. Access and computation boundaries require enforcement at the point capability is granted, not only at the point output is written.¶

5.6. A Request for a Derived Value

The advertising system instead attempts to write a value computed from, but not textually identical to, the address:¶

   customer-17 -> estimated high-income household

The value contains no street address. A Finality Sink that checks only for the literal restricted value would pass it. A Finality Sink that checks propagated source lineage does not:¶

   Derived object: income-estimate-52
   Restricted source: address-619
   Requested use: advertising

The profile-write boundary rejects the write on the lineage binding, not on pattern-matching the output. This requires deliberate, non-removable tracking of derived-data provenance; a label attached to the output that the producing workload can choose to omit provides no enforcement at all.¶

5.7. What This Architecture Does Not Close

If an authorized courier receives the plaintext address and copies it into an unrelated application, the protected data service cannot guarantee the copy is never reused. Containment beyond this point requires controlled recipient software, restricted export paths, minimal disclosure, and downstream enforcement at the recipient's own boundary -- outside what a source-side PED can observe. Human observation, screenshots, and compromised endpoints remain outside this architecture's reach. The claim this document makes is therefore bounded: within an enforced system boundary, data can be made unavailable to unauthorized workloads, and unauthorized derived-value writes can be blocked. Preventing every possible reuse after legitimate plaintext disclosure is a different, and materially harder, problem that this document does not claim to solve.¶

8.1. GNAP

GNAP [RFC9635] already separates the negotiation of a grant from its use, and supports fine-grained, per-request access rather than a single broad session token. The Execution Handle described here is compatible with a GNAP access token scoped to a single resource/operation pair; this document's contribution to GNAP-adjacent work is the requirement that the Authorization Server's grant decision be made against externally-verified binding records rather than against client-supplied purpose or context claims, and that a derived-resource request be evaluated against source lineage rather than treated as a fresh, unrelated grant.¶

8.2. OAUTH

OAuth 2.0 [RFC6749] deployments that rely on a "purpose" or "scope" string supplied by the client are exposed to exactly the relabeling attack in Section 5.4. [RFC8707]'s audience restriction is a partial mitigation already in the OAuth toolkit; this document suggests that audience restriction alone is insufficient where the threat model includes a legitimately audience-scoped token presented for an operation outside its intended purpose, and that purpose SHOULD be a property the authorization server derives from verifiable request context rather than a bearer-supplied claim.¶

8.3. RATS

Section 5.5 is directly a RATS-relevant finding: this document treats a RATS [RFC9334] Attestation Result as answering "is this code running as expected" and treats purpose/operation authorization as a separate, subsequent check that a Relying Party MUST perform independently. Where RATS-based systems are used to gate access to sensitive data, this document's caution against conflating attestation with authorization is offered as an applicability consideration.¶

8.4. SPICE

SPICE's work on credential formats and selective disclosure is relevant to Section 5.1's binding of a data object to a specific permitted workflow: a credential-based encoding of the "allowed workflow / allowed operation / allowed recipient" policy record would let the binding travel with the data object in a verifiable form rather than living only in a centralized policy store, which may be of interest to SPICE's scope on interoperable credential structures.¶

8.5. SECDISPATCH

This document is submitted as an individual architectural pattern rather than a protocol specification, and the author does not assert a specific IETF venue for standardization. SECDISPATCH is the appropriate venue to determine whether, and where, a purpose-binding and derived-data-lineage mechanism of this kind warrants protocol-level standardization versus remaining an architectural pattern referenced by implementers of GNAP, OAuth, and RATS-based systems.¶

8.6. PEARG (IRTF)

The Privacy Enhancements and Assessment Research Group is an IRTF research group rather than an IETF working group, and is noted here because Section 3.3 and Section 5.6 (derived-data lineage) and Section 5.7 (the residual plaintext-reuse limit) are research questions as much as engineering ones; PEARG's work on privacy threat modeling and assessment methodology is relevant to evaluating how completely a lineage-propagation mechanism actually closes the derived-data gap in practice.¶

13.1. Primary Reference Implementation

A second, purpose-built reference implementation, [DAS-PURPOSE-FINALITY-IMPL] (the primary reference implementation for this document), models the exact worked example in Section 5 directly rather than a GDPR-framed analogue: its baseline Candidate Act is a delivery-service request for address-619 to obtain a delivery destination for assigned-courier-6, and its principal negative-control test is an advertising-service requester submitting the same object under a permitted-looking declared_purpose ("delivery") while its authenticated requester, workload, operation, and destination are all substituted for the advertising path -- exercising Section 5.4 directly rather than by analogy. It additionally implements the Legitimacy and Authority Verification Record (LAVR) construct as a hash-chained, HMAC-authenticated decision log, and tests derived-data lineage propagation (Section 3.3) with both a positive control (permitted lineage) and two documented negative controls (a lineage-stripping limitation and a compromised trusted-binding-record limitation), rather than treating lineage enforcement as unconditionally solved.¶

The primary implementation's validation package comprises 88 automated Python tests, 19 deterministic conformance vectors independently re-executed in Python, Go, and Node.js (57 total cross-language executions), and 2,000 seeded adversarial mutation trials (1,000 post-issuance field mutations, 500 purpose-relabel attacks, and 500 wrong-holder proof-of-possession attempts), all denied as expected. Measured local software latency (p95, recorded Linux/x86-64 host) was benchmarked across three topologies:¶

As with [DAS-PRIVACY-FINALITY-IMPL], these are reference-software engineering regression targets measured on a single local host, not IETF protocol requirements, and not TEE, HSM, GPU, WAN, or production-system performance claims; the sidecar figure is localhost loopback and excludes any real network round-trip. The implementation's own documented residual risks -- an authorized recipient copying plaintext after legitimate release, a compromised PED, a maliciously modified trusted binding record, stripped derived-data lineage, and covert/side channels -- match the limitations already stated in Section 3.3 and Section 5.7, and are not resolved by this or any other implementation in this family.¶

13.2. Other Reference Implementations

Other reference implementations from the same author, supporting companion drafts in the same execution-finality portfolio, are provided here for context and are not relied upon by this document's normative content: [DAS-HALLUCINATION-IMPL] (preventing AI hallucination-driven and other unauthorized actions), [DAS-EGRESS-IMPL] (precision-bounded location release), and [DAS-6G-IMPL] (execution finality for AI-native 5G/6G and O-RAN).¶

13.3. Companion Engineering Analysis

"Declared Purpose Is Not Authorization: Capability Laundering and Execution Finality at the AI Inference Boundary" ([DAS-CAPABILITY-LAUNDERING], DOI 10.5281/zenodo.22719527) is a companion analysis to this document. It carries the engineering objections of Section 16 across to AI inference deployments, where the governed resource is model capability and the enforcement boundary is the point at which a generated response is released to a requester. Its central statement -- that generation is not release, and computation is not authority -- is the inference-layer form of the distinction this document draws between a Candidate Act and an effect. It is published under a DOI and is not relied upon by this document's normative content.¶

16.1. Does the Architecture Merely Move Trust Into an External Database?

No. The architecture moves authority away from caller-controlled assertions, but it does not treat every external database entry as trustworthy.¶

A weak design would be:¶

caller says:
purpose = DELIVERY

database says:
purpose = DELIVERY

therefore:
ALLOW

That merely relocates the writable field. The stronger arrangement is the one described in Section 4: a Candidate Act is evaluated by the PED against authoritative state, provenance and authenticity, freshness and version, and requester, object, workflow, and destination binding, before any scoped execution authority is issued to a Finality Sink.¶

The important distinction is:¶

external state
    !=
authoritative state

An external record becomes security-relevant only if the enforcement system can establish properties such as:¶

AUTHENTIC

CURRENT

NON-ROLLBACK

BOUND TO THE RELEVANT OBJECT

BOUND TO THE RELEVANT WORKFLOW

BOUND TO THE RELEVANT AUTHORITY DOMAIN

NOT UNILATERALLY WRITABLE BY THE REQUESTER

The storage system may carry authoritative evidence. It does not create authority merely because a value exists in storage.¶

16.2. What if the Authoritative Binding Authority Itself Is Compromised?

Then the root of authority is compromised. If a trusted authority or its signing key produces apparently valid authorization evidence, a downstream verifier generally cannot distinguish that issuance from honest issuance merely by checking the same credential.¶

actual intended rule:
customer-data -> delivery only

compromised authority:
customer-data -> advertising allowed

If the compromised authority generates valid evidence authorizing advertising, downstream cryptography cannot infer the policy that the trusted authority should have issued instead. This is a root-of-trust limitation, and it is the same residual condition recorded in Appendix A.5.4.¶

High-assurance deployments MAY reduce that risk using:¶

independent authorities

threshold signatures

quorum approval

dual control

HSM-backed signing

append-only transparency records

cross-checking between domains

policy-authority separation

revocation and key-rotation controls

For example:¶

Policy Authority --------\
                          \
Compliance Authority -----> quorum -> authority state
                          /
Security Authority ------/

The architecture can strongly resist caller forgery, database-row injection, cache poisoning, record substitution, rollback, stale authority, transport tampering, and unauthorized replay, while still acknowledging that compromise of the ultimate authority remains a residual trust boundary.¶

16.3. Is This Not Simply Moving the Security Problem Elsewhere?

Every security system has roots of trust. The engineering objective is not to eliminate trust but to make it explicit, narrow, authenticated, freshness-bound, machine-verifiable, and not requester-controlled.¶

Without such separation:¶

application requests operation
        |
        v
application says operation is authorized
        |
        v
operation executes

With execution-finality enforcement:¶

application requests operation
        |
        v
independent authority evaluated
        |
        v
freshness and scope verified
        |
        v
candidate act bound
        |
        v
sink verifies authority
        |
        v
operation becomes effective

The attack surface therefore changes from any component able to invoke the operation, to components able to compromise the protected authority chain. That is a meaningful reduction, not an elimination.¶

16.4. Why Is an Authenticated Binding Record Not Sufficient by Itself?

Authentication answers who issued a piece of state. It does not answer whether that state is the state actually evaluated, whether it is still current, whether it applies to this object, workflow, or destination, or whether it was replaced or revoked after evaluation.¶

The authorization path should therefore depend on the security-relevant state actually evaluated:¶

Evaluated Authority State
        |
        +--> object
        +--> workflow
        +--> requester
        +--> operation
        +--> destination
        +--> policy epoch
        +--> revocation state
        +--> freshness
        |
        v
protected commitment
        |
        v
Execution Handle / bounded authority

Otherwise this attack becomes possible:¶

validate against State V1
        |
        v
authorization generated
        |
state changes to V2
        |
        v
reuse authority created under V1

The enforcement mechanism therefore needs some way to ensure that the authority used at effectuation still corresponds to the relevant validated state.¶

16.5. What if Authoritative State Changes After Validation but Before Effectuation?

That is a time-of-check/time-of-use (TOCTOU) problem. It is not addressed by the handle-replay protection described in Section 6: the handle in question is genuine, unexpired, and used by its intended holder, and only the underlying binding has changed.¶

10:00:00
Courier A is assigned.

10:00:01
Authorization generated.

10:00:03
Order reassigned to Courier B.

10:00:05
Courier A attempts data release.

Two mitigations exist. Under the first, the issued authority is deliberately short-lived -- valid for one transaction, or for a narrowly bounded freshness window -- so that mutable external state cannot drift far from the validated state. The appropriate lifetime depends on the mutability and consequence class of the underlying authority.¶

Under the second, the Finality Sink revalidates the security-relevant predicates capable of changing after the original validation: recipient assignment, revocation state, order state, policy version, destination state, account state. The architecture can therefore separate heavier authority evaluation, performed on the control path by the PED, from small mutable-state checks performed at the Finality Sink. A deployment MAY use either technique or both.¶

The invariant is that a previously valid decision MUST NOT become permanent authority after the state on which it depended has materially changed.¶

16.6. Can an Attacker Remove source_lineage and Make Restricted Ancestry Disappear?

Deleting a lineage field MUST NOT convert restricted ancestry into unrestricted ancestry.¶

A system is bypassable if it implements:¶

if source_lineage exists:
    enforce lineage restrictions
else:
    assume unrestricted

because the attacker can then perform:¶

restricted derived object
        |
remove source_lineage
        |
        v
apparently unrestricted object

The correct distinction has three states, not two:¶

verified permitted lineage

verified restricted lineage

required provenance unavailable or unverifiable

The core rule is that missing evidence of restricted ancestry is not evidence of unrestricted ancestry. For an operation whose policy requires established provenance:¶

required provenance
        +
cannot establish provenance
        |
        v
predicate unsatisfied
        |
        v
no effectuation

This requirement is operation- or policy-driven. It MUST NOT depend merely on whether a caller happened to supply an optional lineage field.¶

16.7. How Does the Finality Sink Know That Provenance Was Required?

This is the distinction between field-driven and operation-driven lineage enforcement. The sink MUST NOT ask only whether the object carried a lineage field. The policy determines whether the candidate operation requires established provenance:¶

Operation:
write advertising profile

Input class:
customer-derived information

Requirement:
verified provenance

Then:¶

provenance present and valid
        ->
evaluate provenance

provenance required but unavailable
        ->
deny / remain non-effective

The requirement therefore exists independently of the metadata field, and no object outside the operation classes that require provenance is obliged to carry lineage at all.¶

Appendix A.5.3 of this document records a negative control that demonstrates precisely the failure mode of field-driven enforcement: in the primary reference implementation, stripping the lineage field from a derived object before it reaches the sink results in EFFECTUATED. That outcome is the reason the stronger rule is stated here:¶

current negative control:
field absent
        ->
lineage requirement not triggered
        ->
EFFECTUATED

architectural requirement:
operation requires provenance
        +
provenance unavailable
        ->
NO EFFECTUATION

Until the reference implementation implements the operation-driven rule, Appendix A.5.3 remains an explicitly disclosed implementation limitation and is not presented as a solved property of the architecture.¶

16.8. What Happens When Governed Data Passes Through an External API?

The external service does not need to understand the finality protocol. Three deployment patterns are available.¶

Under the first, protected provenance travels with the object:¶

object
+
protected provenance envelope

The external system MAY ignore that envelope. It MUST NOT be able to modify the protected binding without detection.¶

Under the second, external computation produces only a candidate result:¶

Protected Authority Domain
        |
        v
candidate request
        |
        v
External Compute Service
        |
        v
candidate result
        |
        v
Protected Return Boundary
        |
        v
Finality Sink

The external service is allowed to compute. It does not receive final authority; the returned result remains non-effective until local protected validation occurs.¶

Under the third, a protected connector surrounds a legacy service:¶

Protected Gateway
        |
        v
Legacy / External Service
        |
        v
Protected Gateway
        |
        v
Finality Sink

The service itself can remain unchanged; the protected boundary controls whether its inputs or outputs acquire consequential authority. The key distinction is that external computation is not external authority.¶

16.9. What if an External API Strips All Provenance Metadata?

Then any design relying solely on that API voluntarily preserving optional metadata is insecure. Purpose enforcement cannot rest on a request that a JSON field be left intact.¶

A protected deployment MUST instead use one or more of:¶

authenticated in-band provenance

independent protected provenance state

trusted revalidation

trusted reconstruction

protected connector state

fail-closed handling
when required provenance cannot be established

The desired failure mode is:¶

provenance destroyed
        |
        v
authority cannot be established
        |
        v
operation blocked

and not:¶

provenance destroyed
        |
        v
restrictions vanish

An attacker may therefore be able to cause an availability failure by destroying required evidence. That is a different and lesser outcome than obtaining additional authority; see Section 16.18.¶

16.10. How Can This Work With a Legacy Database That Cannot Be Modified?

The ordinary database does not have to carry governance state. A deployment MAY maintain security-relevant state separately:¶

Legacy Database
--------------------------------
object-719:
    value = "high income"

Governance State
--------------------------------
object-719
version = 17
purpose_scope = fraud-only
source = customer-profile-22
policy_epoch = 93

Physical separation is not what creates trust. The governance store is not trustworthy merely because it is a second database. Its security value comes from authenticated writes, restricted write authority, cryptographic integrity, version and freshness enforcement, protected signing keys, rollback protection, and binding to the governed object.¶

The correct distinction is therefore:¶

ordinary application database
        !=
protected authority state

and not:¶

database 1
        !=
database 2
therefore database 2 is trusted

At effectuation, the sink verifies object binding, authority state, current version, and requested purpose before allowing or denying. The central requirement is that application code cannot obtain greater authority merely by editing the ordinary database.¶

16.11. What if the Database Object Changes but Its Governance State Does Not?

That is an object-binding failure. Authority should not be attached merely to a reusable logical name such as record-728, because the contents behind that name may change.¶

A stronger authority binding can incorporate object identifier, object version, content digest, source or provenance state, and policy epoch:¶

ObjectBinding =
    H(
      object_id,
      version,
      content_digest,
      governance_state
    )

Then:¶

database value changes
        +
old authority remains
        |
        v
binding mismatch

The old authority cannot silently authorize the new object.¶

16.12. What Prevents Copying Valid Lineage From One Object to Another?

That is lineage substitution:¶

Object A
permitted ancestry
        |
copy provenance
        |
        v
Object B
restricted ancestry

A lineage assertion MUST therefore be bound to the object or transformation result it describes. Binding elements may include object digest, object identifier, object version, parent digest, generation identifier, transformation identifier, producer identity, and policy epoch.¶

The security condition is not that valid lineage exists, but that valid lineage exists for this object.¶

16.13. What Prevents Transformation From Washing Away the Restriction?

Transformation is not declassification. This restates Section 3.3 in the terms reviewers most often raise it.¶

The unsafe assumption would be:¶

customer address
        |
        v
income estimate
        |
        v
"no longer address data"
        |
        v
unrestricted

or:¶

personal data
        |
        v
embedding
        |
        v
"not personal anymore"

A derived artifact may still encode, summarize, infer, classify, compress, or otherwise depend on governed source data. The architecture therefore treats transformation as a new governed event:¶

Source A
purpose = DELIVERY

        |
        v

Transformation F

        |
        v

Derived B

The fact that B differs from A does not establish that the authority of B exceeds the authority of A. A transformation can broaden authority only if an authorized policy transition permits that result, and that transition MUST itself be established rather than inferred from the fact that the representation changed.¶

16.14. What if Several Datasets Are Combined and Only Some Are Restricted?

There is no universal rule that can safely be reduced to simple set intersection. The resulting authority should be derived through a protected composition policy that evaluates the contributing source restrictions, the transformation type, the resulting sensitivity, the purpose, recipient, destination, and jurisdiction, and where applicable join risk, aggregation depth, exposure history, and output class.¶

A conservative deployment may sometimes use:¶

result_scope =
intersection(source_scopes)

but that is only one possible policy rule and is not generally sufficient. Consider:¶

Dataset A:
analytics allowed

Dataset B:
analytics allowed

A + B:
reveals identity or sensitive behavior

The combined result may require stricter authority than either parent dataset individually. Derived authority is therefore determined by protected policy over both the contributing inputs and the transformation itself, and the resulting authority can be narrower than the authority of every individual source. The application does not get to choose which contributing restrictions to remember.¶

16.15. Does Execution Finality Solve Cross-Session or Mosaic Aggregation?

Not by itself, and this is stated explicitly rather than left for a reader to discover.¶

session 1 -> permitted small result

session 2 -> permitted small result

session 3 -> permitted small result

...

session 10,000 -> sensitive profile reconstructed

Each individual release may satisfy its local authorization conditions. The prohibited result appears only after aggregation across time. That is the mosaic problem, and per-act execution finality does not automatically determine whether many individually allowed outputs collectively reveal prohibited information.¶

A deployment may introduce additional predicates:¶

cumulative disclosure budget

recipient exposure state

cross-session counters

query similarity state

join-risk state

aggregation depth

privacy budget

mosaic-risk state

but those are additional stateful controls, and the necessary state is not created by this architecture. The limitation is that per-act finality does not itself prove that a sequence of individually authorized releases cannot collectively reconstruct prohibited information. Execution finality can enforce a cumulative policy once one exists; it does not discover the correct cumulative policy.¶

16.16. What if a Prohibited Operation Is Split Into Many Harmless Ones?

This is related to mosaic aggregation but distinct from it. In the mosaic case the prohibited result is inferred statistically; here it is assembled directly. Suppose the prohibited consequence is the export of a complete customer profile. The attacker may instead request:¶

request 1 -> name

request 2 -> postcode

request 3 -> salary estimate

request 4 -> behavior class

request 5 -> account risk

request 6 -> purchase history

Each request may be acceptable individually, and none carries a purpose label that is false. Preventing the composite result requires cumulative state:¶

recipient exposure state
        +
data-class budget
        +
time window
        +
purpose
        +
join-risk rule
        |
        v
release decision

Execution finality provides the enforcement point. It does not invent the policy determining which sequence becomes prohibited. The separation is:¶

policy:
"What cumulative behavior is disallowed?"

finality architecture:
"Can that disallowed behavior become effective?"

These are separate engineering problems and this document addresses only the second.¶

16.17. What if Another Path Bypasses the Finality Sink?

Then that alternate path is itself an effectuation boundary. Security cannot depend on protecting one approved write function while leaving others capable of creating the same protected consequence:¶

raw_sql_write()

debug_write()

admin_api()

backup_writer()

message_queue()

direct_storage_path()

The invariant is that every path capable of producing the protected effect MUST encounter equivalent finality enforcement. Conceptually, an estate in which several paths reach the effect independently:¶

API A -------\
API B --------\
SQL -----------> protected effect
queue ---------/
admin --------/

MUST become one in which they converge on a common boundary:¶

API A -------\
API B --------\
SQL -----------> Finality Boundary ---> protected effect
queue ---------/
admin --------/

or one in which each path independently enforces equivalent authority. An unprotected alternate effect path is a bypass, and an adopter that protects only the documented path has not deployed this architecture.¶

16.18. Does Fail-Closed Provenance Checking Create Denial-of-Service Risk?

Yes. Security and availability are different properties. If required provenance is unavailable and the system denies, an attacker who can destroy or block that evidence may be able to prevent a legitimate operation. But the alternative -- allowing on unverifiable state -- turns destruction of evidence into privilege escalation.¶

The safer property is:¶

uncertainty
        ->
availability loss

rather than:¶

uncertainty
        ->
authority expansion

Availability can be improved through replicated authority services, locally verifiable signed evidence, bounded-validity caches, protected local state, quorum replicas, recomputation from trusted sources, checkpointed state, and explicitly authorized constrained fallback. None of those SHOULD silently convert unverifiable security state into unrestricted authority.¶

WAN authority queries

remote revocation lookups

quorum formation

external signature services

distributed consensus

remote provenance reconstruction

production HSM latency

production TEE transitions

16.19. Can the Requester Be the Authoritative Source of Purpose?

Not if the architecture is intended to resist purpose laundering by that requester. If the same requester can assert a request for advertising use and also generate the evidence stating that advertising use is authorized, there is no independent authority boundary.¶

The architecture therefore requires an authority source the requester cannot unilaterally manufacture or rewrite. Depending on deployment, that may be an enterprise policy authority, an order-management authority, a consent authority, customer authorization state, a workflow controller, device-protected state, a regulated policy service, an HSM-backed registry, or a multi-party approval authority. The precise source varies; the invariant does not:¶

requester assertion
        !=
authorization evidence

16.20. Does the Architecture Apply to Every AI Inference Request?

No. The architecture has an applicability boundary, and it is stated here so that a reader evaluating this document does not have to derive it.¶

anonymous caller
        |
        v
public model
        |
        v
ordinary text response

If there is no protected data, no consequential controlled effect, no independent authority, no protected sink, and no governed resource, then there may be no execution-finality authority to enforce. The architecture becomes relevant when a consequence depends on protected state -- personal-data release, enterprise record mutation, payment, account modification, AI tool invocation, external communication, regulated export, medical workflow, critical-infrastructure action, database commit, or model-memory mutation.¶

The applicability requirement can therefore be stated as follows: execution-finality enforcement requires a consequence-bearing boundary and at least one authority predicate that the requesting workload cannot unilaterally manufacture or rewrite. Without an independent authority source, this architecture does not claim to manufacture authority from nothing.¶

16.21. Is Purpose Not Semantic and Therefore Unenforceable Cryptographically?

Cryptography cannot determine human intention in the abstract, and that is not the claim. The architecture enforces the result of a machine-verifiable authorization decision. An external policy or authority may determine that a customer address is permitted for delivery. That can be represented technically as:¶

purpose_class = DELIVERY

recipient_class = assigned-courier

destination_class = delivery-interface

valid_until = order-completion

output_class = minimum-needed-address

The protected architecture then enforces those predicates. It does not prove what a human intended; it determines whether this candidate consequence matches the authorized machine-verifiable scope. The transition from delivery-authorized data to an advertising-profile write can be blocked unless a separate authorized transition establishes advertising authority.¶

The architecture therefore addresses technical enforcement of purpose boundaries, not automatic discovery of the legally correct purpose.¶

16.22. Summary of Engineering Invariants

The data-purpose-laundering defense described in this document reduces to the following distinctions:¶

Caller assertion
    != authority

Database presence
    != authority

External storage
    != trusted storage

Authentication
    != current authorization

Valid signature
    != fresh state

Prior ALLOW
    != permanent authority

Transformation
    != declassification

Aggregation
    != automatically permitted derivation

Missing lineage
    != clean lineage

Valid lineage
    != lineage for this object

Same object identifier
    != same object version

Attestation
    != purpose authorization

Successful computation
    != permission to effectuate

Possession of an execution handle
    != reusable bearer authority

Unverifiable required state
    != ALLOW

At the consequential boundary:¶

Candidate Act
        |
        v
ESTABLISH REQUIRED AUTHORITY
        |
        v
ESTABLISH REQUIRED PROVENANCE
        |
        v
VERIFY CURRENT STATE
        |
        v
VERIFY OBJECT / VERSION / WORKFLOW
        |
        v
VERIFY PURPOSE / DESTINATION / REQUESTER
        |
        v
BIND AUTHORITY TO THIS ACT
        |
        v
BIND AUTHORITY TO THIS FINALITY SINK
        |
        v
RECHECK OR CONSUME FRESHNESS STATE
        |
        v
EFFECTUATE

If a required predicate cannot be established, the Candidate Act remains non-effective. The architecture does not attempt to prevent computation itself; it controls the transition from computed to consequence-bearing, and requires that this transition occur only after the authority relevant to the exact act, object, destination, provenance state, and Finality Sink has been established.¶

A.1. Recorded Test Environment

The validation was executed once, on the following recorded environment; the repository does not claim these figures on Windows, macOS, ARM64, HSMs, TEEs, GPUs, DPUs, SmartNICs, confidential VMs, Kubernetes, WAN networks, or production advertising systems:¶

A.2. Baseline Candidate Act, Binding Record, and Validation Context

A deterministic baseline was used so every mutation could be compared against a known-valid act. The Candidate Act (act-001, policy version 38, 10-second validity window) requests obtain delivery destination on object address-619 for workflow delivery-order-842, from requester/workload delivery-service / delivery-workload, to destination assigned-courier-6, carrying declared_purpose: delivery. The matching external binding record independently authorizes the same object/workflow/requester/workload/operation/destination/policy-version tuple and is valid for 60 seconds. The declared_purpose field is deliberately treated as untrusted requester-supplied metadata, never as authorization evidence -- the central test in Appendix A.5.1 is whether relabeling it can rescue an unauthorized request; it cannot. The baseline validation context (authenticated requester/workload, order existence, object association, recipient assignment, binding store availability and integrity, attestation result, timeout flag) is independently varied in the negative tests below.¶

A.3. PED Decision Sequence

The PED applies a deterministic, fail-closed evaluation order; any earlier failure short-circuits to DENY with an associated failure LAVR, and later checks are not reached:¶

 1. Validation timeout?
 2. Binding store available?
 3. Binding store integrity acceptable?
 4. Binding record exists?
 5. Candidate Act still fresh?
 6. Binding record still fresh?
 7. Binding revoked?
 8. Policy version correct?
 9. Requester identity correct?
10. Workload identity correct?
11. Protected object correct?
12. Workflow correct?
13. Operation permitted?
14. Destination permitted?
15. Workflow/order exists?
16. Object belongs to workflow?
17. Recipient assignment current?
18. Required attestation valid?

Only after all eighteen checks succeed is the result ALLOW. A key architectural test verifies that attestation_ok = true does not override an OPERATION_MISMATCH, REQUESTER_MISMATCH, DESTINATION_MISMATCH, or WORKLOAD_MISMATCH -- i.e., attested is not authorized.¶

A.4. Execution Handle Lifetime Clamping

With max_handle_ms = 2000, handle expiration is min(Candidate Act expiration, issuance time + 2000 ms). Boundary tests at candidate lifetimes of 0, 1, 10, 100, 1000, and 1999 ms from PED issuance time all produced a clamped handle; 2000 ms produced the maximum unclamped handle -- verifying the PED cannot issue a handle exceeding either its own configured maximum or the Candidate Act's own expiration. The handle itself binds handle_id, the Candidate Act digest, object, workflow, operation, requester, workload, destination, policy version, nonce, issuance/expiry times, and the proof-of-possession key ID -- i.e., authorization for this exact act under this exact binding state, not general access.¶

A.5. Mutation and Threat-Model Testing

Canonical JSON serialization (sorted keys, no incidental whitespace, UTF-8, deterministic separators) is SHA-256 hashed to produce the Candidate Act digest, so any load-bearing field change alters the digest. Two independent mutation surfaces were tested:¶

• Post-issuance mutation (handle already issued): each of object, workflow, operation, destination, requester, workload, declared purpose, nonce, and policy version was individually mutated after issuance; every case produced ACT_DIGEST_MISMATCH, since the previously issued handle no longer matches the altered act's digest.¶
• PED-side mutation (before issuance): the same fields were mutated before the PED evaluated the act; each independently produced its corresponding *_MISMATCH denial (e.g., requester, workload, object, workflow, operation, or destination mismatch).¶

A.6. LAVR Generation, Chaining, and Tamper Detection

Every PED decision (PASS or FAIL) generates a Legitimacy and Authority Verification Record (LAVR) containing a monotonic sequence number, the previous LAVR's hash, the Candidate Act digest, the PASS/FAIL result and reason code, policy version, and timestamp, HMAC-authenticated as a body. The first LAVR's previous-hash field is 64 zero characters; each subsequent record's prev_hash is the SHA-256 of the prior LAVR, and the suite verifies sequence continuity, hash-chain continuity, and HMAC integrity. A deliberately tampered LAVR signature is correctly detected by chain verification. This is a local authenticated hash chain, not a public blockchain or distributed ledger.¶

A.7. Replay and Concurrency Testing

A valid Execution Handle used once returns EFFECTUATED; the identical handle reused returns REPLAY_DETECTED. Two replay backends were tested: an in-memory lock-protected set of consumed handle IDs, and a persistent SQLite/WAL-backed table keyed on handle_id (primary-key violation on reuse, transaction rolled back). Concurrency was tested directly rather than only sequentially: for the memory backend, five profiles (2/4/8/16/32 worker threads issuing 10/32/64/100/128 concurrent attempts against the same handle) each produced exactly one EFFECTUATED and (attempts - 1) REPLAY_DETECTED outcomes; for the SQLite backend, four profiles (2/4/8/16 threads, 8/16/32/64 attempts) produced the same exactly-one-success invariant. Persistence was additionally verified across a simulated restart: issue, consume, close the SQLite connection, reopen, and re-attempt the same handle -- REPLAY_DETECTED, confirming local persistent replay state (not distributed multi-node replay consensus, which remains out of scope).¶

A.8. Cross-Language Conformance

Nineteen deterministic conformance vectors (each a Candidate Act, binding record, validation context, expected decision, and expected SHA-256 Candidate Act digest) were independently re-implemented and executed in Python 3.13.5, Go 1.23.2, and Node.js 22.16.0, covering: baseline valid request; wrong requester/workload/object/workflow/operation/destination; changed-but-untrusted purpose only (still ALLOW); wrong policy version; revoked, expired, or missing binding; missing workflow; broken object association; changed recipient assignment; unavailable or integrity-failed binding store; attestation failure; and forced timeout. Each language independently canonicalizes, digests, and decides; results were 19/19 in all three languages (57 total executions of the 19 shared vectors -- not 57 distinct threats). This demonstrates that canonicalization, digest semantics, binding-record checks, decision ordering, and reason-code behavior can be implemented consistently across languages; it does not establish that the Go and Node conformance programs are complete production equivalents of the full Python reference (LAVR lifecycle, replay store, and PoP lifecycle remain primarily implemented in Python).¶

A.9. Deterministic Adversarial Stress Testing

A seeded (20260909), reproducible stress test outside the pytest suite ran 2,000 total trials in three groups: 1,000 post-issuance field mutations (a random load-bearing field replaced with a random value after handle issuance), 500 purpose-relabel attacks (advertising requester/workload/operation/ destination with a random 0-40-character purpose label), and 500 wrong-holder proof-of-possession attempts (proof generated with the non-bound holder key). All 2,000 trials were denied. This volume is reported separately from, not summed with, the 88 pytest cases and 57 cross-language executions, since the categories overlap conceptually and a combined "2,145 tests" figure would overstate distinct coverage.¶

A.10. Latency by Topology, with Repeated Runs

Three local software topologies were benchmarked, each with a fresh Candidate Act per iteration (avoiding replay-state contamination across iterations) and a distinct engineering regression target:¶

Each topology's p95 was additionally repeated three further times to avoid accepting a single favorable run: memory 0.2154-0.2424 ms, SQLite 0.2605-0.4145 ms, HTTP sidecar 2.0291-2.3466 ms across the three repeats, every repeat remaining under its target. One HTTP-sidecar repeat recorded a maximum latency of 47.9501 ms (retained, not discarded as an inconvenient outlier) while its p95 remained 2.2572 ms -- illustrating that an isolated scheduler/runtime pause can inflate the maximum without moving the percentile figures the targets are defined against. The HTTP-sidecar figures are localhost loopback only and exclude any real network round-trip, remote policy lookup, or remote attestation.¶

A.11. What the Testing Supports, What It Does Not, and Residual Risks

On the recorded Linux/x86-64 environment, the evidence supports the bounded claim that the Candidate Act -> external-binding-validation -> LAVR -> scoped non-bearer handle -> holder proof -> independent Finality Sink -> atomic single-use effectuation path executed correctly under the tested threat, mutation, concurrency, storage, language, and local-topology variations, within the repository's own p95 regression thresholds. It does not establish that all implementations of this pattern are secure; that production systems will see sub-millisecond or WAN-equivalent latency; that TEE/HSM latency matches this software path; that lineage can never be stripped; that the authoritative binding database cannot itself be compromised; that plaintext cannot be copied after legitimate release; that covert channels are prevented; that the protocol is formally verified; or that the architecture by itself establishes legal compliance.¶

These match, and do not extend, the limitations already stated for the architecture generally in Section 3.3 and Section 5.7. Recommended next-level validation, replacing one software assumption at a time with a real deployment component, includes: a protected or cryptographically signed external binding-record store; a non-exportable holder proof-of-possession key; HSM- or TEE-backed handle signing; a replicated transactional replay/effect database; real service-mesh/API-gateway integration; remote-attestation freshness and revocation integration; protected lineage propagation through a real computation pipeline; network-partition and stale-replica fault injection; sustained concurrency/throughput measurement at production scale; and an independent interoperable implementation built solely from the published conformance vectors.¶

A.12. Reproduction

The validation package's expected primary results are 88 passed Python tests; 19/19 conformance vectors in each of Python, Go, and Node.js; and 1,000/1,000, 500/500, and 500/500 denied outcomes for the three deterministic stress groups of Appendix A.9, reproducible via the commands and version pins published alongside [DAS-PURPOSE-FINALITY-IMPL].¶