[Use Case] Same action, different lineage: distinguishing representation-to-action descent from independent reconstruction

1. Identification

Title: Same action, different lineage: distinguishing representation-to-action descent from independent reconstruction

Submitting organization: Institute for Consciousness & Attention Mechanics (ICAM), independent research initiative

Contact name: Nika Novak

Contact email: novak@attentionmechanics.institute

Sector (tick all that apply; a cross-industry case may tick more than one):
- [ ] Education
- [ ] Displaced persons / humanitarian
- [ ] Health
- [ ] Financial services
- [ ] Telecom
- [ ] Media and publishing
- [ ] Logistics
- [ ] Energy
- [ ] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): Enterprise procurement and internal organizational decision systems

Status: Hypothetical, implementation-neutral discussion case. Scenario facts and expected outcomes are proposed, not implementation results or adopted requirements.

2. The situation

Plain language description (required, 3 sentences max):
An enterprise has an approved organizational representation R123: “Do not renew Supplier B.” A procurement agent later produces and executes action A92, which reaches the same operational outcome, but a later relying party must determine whether A92 actually descended from R123, was independently reconstructed from another basis, or cannot be resolved from the retained record. The use case tests whether these materially different histories remain distinguishable even when the final action is identical.

Actor (every party involved):
Enterprise E as principal and deployer; Human Approval Function H, which issues the approved organizational representation R123; Procurement Agent A; Procurement Execution Service X, which receives and executes A92; the evidence-producing record system or systems; and a later reviewer Q that appraises the retained record.

Action:
Procurement Agent A produces instruction A92 to set Supplier B’s internal renewal state to DO_NOT_RENEW and close the corresponding renewal task. Procurement Execution Service X applies that state change under the enterprise’s existing authorization and procurement controls. External supplier notification, contract termination, and legal effect are outside the base case.

Decision required (at the moment the agent acts):
May Procurement Execution Service X accept and retain the claim that A92 is executed pursuant to R123 as a supported lineage relation, or must that relation remain unresolved while execution proceeds under separate authorization controls? A later reviewer then asks whether the retained record supports the same lineage finding. Authorization and policy conformance are held constant in the core variants so that the use case isolates representation-to-action lineage.

Problem encountered:
The same action can arise through materially different histories. A92 may have been produced because the workflow used R123; it may have been independently reconstructed from another source while arriving at the same wording or outcome; or the available records may be insufficient to distinguish those possibilities. Textual identity, semantic equivalence, outcome identity, authorization, access, or policy conformance do not by themselves establish descent from R123.

A positive lineage assertion is also not self-proving merely because it is present in a protected log. The later relying party needs an identifiable focal representation, an identifiable executed action or action-bearing descendant, and an evidence basis that can be appraised independently of the bare assertion. The case therefore tests distinguishability and evidentiary status, not hidden model reasoning.

Current mitigation:
In the hypothetical baseline, Enterprise E retains the approved instruction, the final action, execution logs, timestamps, identifiers, and an optional self-reported statement that the agent “used” the instruction. Those records establish several surrounding facts, but the baseline does not retain independently appraisable relation evidence sufficient to distinguish supported descent, transformed descent, independent reconstruction, examined-but-unresolved lineage, and record silence.

Residual gap:
A later party may be able to establish that R123 existed, that Agent A was authorized, that A92 was executed, and that the outcome matches R123, while still being unable to establish whether A92 actually descended from R123. The residual gap is not general provenance or general auditability; it is the representation-to-action relation itself and the evidentiary basis for the finding made about that relation.

Functional variants

All variants hold the agent identity, mandate, action, supplier, authorization result, and policy-conformance result constant unless stated otherwise.

Variant A — Supported descent without material transformation.
The record identifies R123, an action-bearing decision object D47, and A92. A frozen, deterministic workflow step creates the decision-bearing field in D47 from the corresponding decision content of R123, with R123 cryptographically bound as the source object; the declared transformation rule is such that changing the focal decision content changes that field in D47. The execution record then shows that A92 was materialized from D47. This is evidence of content-bearing dependency, not merely evidence that R123 was available or retrieved. Expected finding: YES — supported descent, subject to appraisal of the relation evidence and its trust assumptions.

Variant B — Supported transformed descent.
R123 is transformed before execution into mapped directive D47: wording, structure, or intermediate representation changes, but the record preserves the source and target object identities, the transformation or mapping relation, the relevant transformation version, and the later materialization of A92 from D47. Expected finding: YES — supported transformed descent, subject to appraisal of that mapping evidence. Material transformation does not by itself break lineage.

Variant C — Supported independent reconstruction.
An action-bearing command equivalent to A92 is generated and committed for execution at time T0 from a separate supplier-performance rule S55. R123 is authored and approved only at T1, where T1 > T0; the command executes at T2, where T2 > T1. The retained schedule and object-history records show that the committed command was not modified, rebound, or re-derived after R123 came into existence. This exclusionary evidence supports that the focal executed action did not descend from R123, even though R123 later expresses the same outcome. Expected finding for descent from R123: NO — supported independent reconstruction.

Variant D — Examined but unresolved.
The reviewer examines a stated set of execution records, intermediate artifacts, and available relation evidence within a bounded scope. The evidence does not establish descent from R123, but also does not establish independent reconstruction. Expected finding: UNCLEAR — examined-but-unresolved, with the examination scope, assessor, and as-of moment retained.

Variant E — Record silence.
The record preserves A92, the agent, and the governing mandate, but contains no usable representation identifier, derivation relation, mapped descendant, or equivalent lineage evidence for R123. Expected finding: UNCLEAR — record silence, distinguishable from Variant D.

Variant F — Similarity only, endpoints present.
The retained record contains both R123 and A92; their wording and operational outcome match, and the agent was authorized and technically able to access R123. No retained evidence establishes a derivation, transformation, action-bearing selection, or binding relation between them. Expected finding: UNCLEAR — lineage unestablished; similarity, access, and authorization are insufficient for YES.

3. Actors and context

Taxonomy roles involved
- [x] Principal — Enterprise E possesses the authority exercised through the procurement workflow.
- [x] Relying party — Procurement Execution Service X relies on the action-time evidence when deciding whether a positive lineage claim may be retained; Reviewer Q later relies on the retained record to appraise that claim.
- [ ] Builder
- [x] Deployer / Owner — Enterprise E operates the workflow.
- [x] Agent instance — Procurement Agent A.
- [ ] User — no separate end-user role is required in the base case.
- [x] Infra provider — internal execution and record systems.
- [ ] Attestor — no dedicated attestor is required in the base case. Where an attestation or independently produced evidence statement is present, it is treated as evidence to appraise rather than as automatic proof of lineage.
- [x] Other (specify): Human Approval Function H; evidence-producing record system(s).

Mandates in this case (required)

Assumptions and test boundary:
- R123 is an identifiable approved organizational representation: “Do not renew Supplier B.”
- A92 is an identifiable executed action with the same operational outcome in every core variant.
- Agent identity, authority, mandate validity, and policy conformance are held constant across the core variants so that they cannot substitute for lineage.
- The case asks whether descent from R123 can be established, not whether the action was good, safe, lawful, or policy-conforming.
- The case does not require disclosure of hidden chain-of-thought, model weights, latent states, or private internal reasoning. It relies on externally retainable evidence, action-time records, and later appraisal.
- A cryptographically protected statement such as “A92 derives from R123” is still a claim. Integrity can establish that the statement was not altered after creation; it does not by itself establish that the statement was true when created.
- A bounded search that finds no lineage evidence is not converted into a universal assertion that no lineage relation ever existed.
- A NO finding requires affirmative exclusionary evidence for non-descent in the focal relation. Merely showing an alternative source or failing to observe use of R123 is insufficient; without stronger evidence the result remains UNCLEAR.
- In this use case, lineage means an externally supportable derivation or action-bearing dependency relation between identifiable prior representation and action-bearing objects. R123, D47, and A92 are illustrative objects, not required schema levels. The case does not claim access to hidden cognitive causality inside a model.
- The specific evidence mechanisms used in Variants A–F are test fixtures illustrating distinguishable evidence states; they are not proposed as mandatory implementations.
- This is a functional hypothetical case, not a claim about any named enterprise deployment.

Cross-border?
- [ ] Yes — jurisdictions involved:
- [x] No — the base case is a single-enterprise, single-jurisdiction scenario.

Embodied (physical actuation or sensing)?
- [ ] Yes — physical context:
- [x] No

Agent action type (required; tick all that apply. Where several apply, the most consequential governs the case)
- [ ] Read-only
- [x] Consequential (reversible) — the supplier-renewal state can be reopened or corrected within the hypothetical workflow.
- [ ] Irreversible

Crosses organisational boundary? (required)
- [ ] Yes (specify):
- [x] No — the base case ends at the internal procurement execution boundary; external supplier notification is excluded.

Risk level (required)
- [ ] Low
- [x] Medium — proposed classification for misleading organizational action records and later accountability conclusions in this bounded reversible scenario; not a regulatory risk classification.
- [ ] High

4. Theme relevance

Related theme proposals:
- Primary contribution: Theme #1 — Accountability and attribution after an agent has acted.
- Authority interface: Theme #5 — Provenance of Authority for Agentic AI and PR #15. Authority origination and standing are consumed, not redefined.
- Conformance interface: Theme #6 — Intent-based security policy expression, coexistence, and runtime verification. Conformance verdict semantics remain separate from lineage.
- Binding interface: Theme #14 — Agent-to-Principal Legal Binding. Action/principal binding and representation-to-action lineage may interface but answer different questions.
- Adjacent record-side case: Use Case #7 — Maintaining agent identity and action-time state across changing executions. Identity/execution/state continuity remains separate from lineage and requires separate support.

5. Requirements

These are candidate requirements for review, not adopted text or prescribed encoding.

6. Assessment criteria

Success criteria:
A later reviewer receives frozen evidence packages for Variants A–F without access to unstated facts. The reviewer can distinguish the six histories and produce the expected lineage finding and evidentiary state without using action similarity, authorization, access, or conformance as substitutes for lineage.

Expected findings:
- Variant A: YES — supported descent, subject to appraisal of the relation evidence.
- Variant B: YES — supported transformed descent, subject to appraisal of the transformation relation.
- Variant C: NO — supported independent reconstruction for descent from R123.
- Variant D: UNCLEAR — examined-but-unresolved.
- Variant E: UNCLEAR — record silence / no usable lineage evidence in the record.
- Variant F: UNCLEAR — lineage unestablished / similarity-only evidence.

Measurable metric:
For the frozen written test set, target:
- 6/6 correct top-level lineage findings;
- 6/6 correct evidentiary-state classifications;
- zero false YES findings on independent reconstruction or similarity-only cases;
- zero false NO findings where evidence is merely missing or inconclusive;
- 100% of positive, negative, or scoped unresolved lineage claims retain an identifiable asserter/assessor, relevant moment, stated evidence basis, and scope where applicable.

These are proposed case-level acceptance criteria for later validation, not reported implementation results. Passing the frozen written set would be necessary evidence of case consistency only; it would not establish general accuracy, deployment feasibility, or real-world validity. The YES / NO / UNCLEAR labels are test-result vocabulary for this contribution, not a required encoding.

7. Duplication check

Existing standards or SDOs (which existing work touches this case):
- W3C PROV-DM — models entities, activities, agents, derivation, and provenance relationships that may be reused as representational building blocks.
- IETF RFC 9334 — RATS Architecture — separates evidence, appraisal, attestation results, and relying-party decisions; useful for the evidence/appraisal boundary but not by itself a definition of representation-to-action lineage.
- FG-TIDA Theme #1, Theme #5 / PR #15, Theme #6, Theme #14, and Use Case #7 as linked above.
- ITU-T SG17 XSTR.aam — AI accountability manifest — binds agent identity to operator-declared intent and operational scope and compares observed behaviour against declared intent. This is adjacent accountability/conformance infrastructure, not by itself evidence that an executed action descended from a particular prior organizational representation.
- ITU-T SG17 XSTR.llmp-tip — LLM token-level inference provenance — defines token-level provenance primitives, inference provenance graphs, token genesis records, and inference attestation. It may supply evidence about output formation but operates at a different layer from the focal representation-to-executed-action relation.
- ITU-T SG17 X.sg-AIAof — Security guidelines for cloud-side AI agent orchestration framework — covers orchestration, workflow, multi-agent management, and execution-link security. It may carry relevant runtime evidence but does not, from the public summary, define the lineage decision tested here.
- ITU-T SG17 Contribution 676 proposing X.aplm-aia — Security framework and requirements for authorization and privilege lifecycle management of AI agents. This use case holds authorization constant and does not redefine privilege-lifecycle semantics.
- ITU-T SG17 Contribution 659 proposing XSTR.caars — Continuous attestation of autonomous agent operation against a versioned rule set. Potentially relevant conformance evidence, but conformance to a rule set remains distinct from derivational lineage from R123.

Overlap notes (why the work named above does not already solve this):
This use case does not claim that provenance, derivation, attestation, or audit records are new concepts. It tests a narrower decision boundary: whether a later relying party can distinguish an action that actually descends from a particular prior organizational representation from an action that is merely similar, compliant, independently reconstructed, or unresolved. Existing mechanisms may supply parts of the evidence; the case is intended to test whether the resulting record preserves the distinctions rather than to replace those mechanisms.

Public-summary overlap review was refreshed on 24 September 2026. I did not identify a public summary in this review that directly resolves the specific distinction tested here: descent from a focal prior representation versus independent reconstruction versus unresolved lineage. Restricted baseline texts were not inspected, so final overlap review remains subject to FG-TIDA/SG17 coordination.

8. Maturity

Pilot status
- [x] Hypothetical
- [ ] Pilot in progress
- [ ] Deployed in production

Reference implementation: n/a. No implementation or executed validation is presented in this submission.

9. IP and confidentiality

Confidentiality level
- [x] Public
- [ ] FG-internal only
- [ ] Redact before publication

IP notes (optional):
Contribution by Nika Novak / ICAM. The case is implementation-neutral and contains no confidential deployment information or proprietary mechanism. It operationalizes distinctions already contributed to Theme #1 as Representation-to-Action Lineage record cases.

10. Assets

Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [x] Other: Frozen written variant packet and expected-outcome table to be created if the use case proceeds to validation.

IP notes (optional):
Any later executable fixture, schema mapping, or validation asset should identify authorship, version, provenance, and license separately. This use case does not prescribe an encoding or implementation.
unresolved or debated? It's fine if this is more questions than answers
at this stage. -->

Related Work

Related Themes

Discussion