This is research analysis, not legal opinion. A solicitor should review before acting.
1. What Reasoning Traces Are
1.1 Definition
A “reasoning trace” is the textual record of an AI model’s intermediate processing steps, generated between the receipt of a user input and the production of a final output. Reasoning traces are produced by “reasoning models” — a class of AI systems that generate explicit chains of thought as part of their inference process.
Three distinct architectures currently produce reasoning traces:
-
Chain-of-thought (CoT) reasoning. The model generates a sequence of intermediate reasoning steps visible in its output. The user sees the reasoning alongside the final answer. Examples: DeepSeek-R1, QwQ, Gemma 3 with thinking enabled.
-
Extended thinking. The model generates reasoning within a designated block (e.g.,
<thinking>tags) that is exposed to the user or developer via API but is architecturally distinct from the final response. Example: Anthropic Claude with extended thinking. -
Hidden internal monologue. The model generates reasoning internally but the reasoning is not exposed to the user or developer. The model provider retains access to the hidden reasoning. Examples: OpenAI o1 (hidden CoT), Google Gemini 2.5 Flash (some configurations). The provider may expose a “summary” of the reasoning without exposing the full chain.
1.2 Legal Significance
Reasoning traces are legally significant because they create a contemporaneous textual record of the factors a model considered (or appeared to consider) before producing an output. This record has no precedent in prior automation: traditional software either produces a deterministic output from known inputs (auditable by inspecting the algorithm) or operates as a statistical black box (no intermediate record). Reasoning traces occupy a novel intermediate position: a textual record that resembles human deliberation but is generated by a computational process whose relationship to the text is empirically uncertain.
1.3 Existing Analogues
| Analogue | Similarities | Differences |
|---|---|---|
| Corporate board minutes | Contemporaneous record of decision factors; discoverable; may establish knowledge | Board minutes record statements by identifiable natural persons; AI traces record generated text with no identifiable author |
| Medical decision documentation | Records clinical reasoning at point of care; establishes standard of care compliance | Clinical notes are authored by a licensed professional exercising professional judgment; AI traces lack a duty-holding author |
| Flight data recorders (FDRs) | Mandatory recording of system state; preserved for accident investigation; establishes causal chain | FDRs record objective instrument readings; AI traces record generated text that may not correspond to underlying computation |
| Audit logs | Chronological record of system operations; preserved for compliance and forensics | Audit logs record events (what happened); reasoning traces record rationale (why the system generated its output) |
2. Discovery: Are Reasoning Traces Discoverable?
2.1 United States — Electronically Stored Information
Under the Federal Rules of Civil Procedure (FRCP), Rule 26(b)(1), parties may obtain discovery regarding “any nonprivileged matter that is relevant to any party’s claim or defense and proportional to the needs of the case.” Rule 34(a)(1)(A) specifically covers “electronically stored information” (ESI), defined broadly to include “writings, drawings, graphs, charts, photographs, sound recordings, images, and other data or data compilations.”
Reasoning traces are ESI. They are electronically stored, generated during system operations, and retained (if at all) as part of the system’s logging infrastructure. Under Zubulake v. UBS Warburg LLC, 220 F.R.D. 212 (S.D.N.Y. 2003), the duty to preserve ESI is triggered when litigation is “reasonably anticipated.” A party that routinely deletes reasoning traces after an incident giving rise to a claim may face spoliation sanctions.
Research analysis: There is no serious argument that reasoning traces are exempt from discovery under current US rules. The only live questions are (a) proportionality (Rule 26(b)(1)) — whether the volume and cost of producing reasoning traces is proportionate to the case — and (b) privilege, discussed below.
2.2 Privilege Objections
A deployer might argue that reasoning traces are protected by the attorney-client privilege or work product doctrine, particularly if the traces were generated during a legal review or compliance assessment. This argument has narrow application:
-
Attorney-client privilege. Applies only to communications made for the purpose of obtaining legal advice. A reasoning trace generated during ordinary operations (e.g., a robot deciding how to execute a task) is not a communication made for the purpose of legal advice. However, a trace generated during a red-team assessment directed by counsel might be privileged if the assessment was conducted at counsel’s direction for the purpose of providing legal advice. Cf. Upjohn Co. v. United States, 449 U.S. 383 (1981) (internal investigations at counsel’s direction).
-
Work product doctrine. Under FRCP Rule 26(b)(3), documents prepared “in anticipation of litigation” are protected. Routine operational traces do not meet this threshold. Traces generated during adversarial testing conducted in anticipation of specific litigation might qualify. However, the work product doctrine protects only the attorney’s mental impressions and legal theories — not the underlying facts. The trace itself (what the model said) is factual; the attorney’s analysis of the trace is work product.
Research analysis: Privilege objections to reasoning trace discovery are unlikely to succeed for traces generated during ordinary operations. They may succeed for traces generated during privileged legal assessments, but this creates a perverse incentive: a deployer who conducts adversarial testing outside of privilege creates discoverable evidence, while a deployer who conducts the same testing under privilege shields it from discovery. This asymmetry may discourage voluntary safety testing. See LR-33 (regulatory arbitrage), which identifies a structurally similar dynamic across jurisdictions.
2.3 Australia — Subpoena and Notice to Produce
Under the Uniform Civil Procedure Rules 2005 (NSW), Rule 33.2, a party may serve a notice to produce requiring the other party to produce “any specified document or thing.” Under Rule 33.3, the notice must specify documents with “reasonable particularity.”
Under the Evidence Act 1995 (Cth/NSW), s 131 (settlement privilege) and s 118-119 (client legal privilege) provide limited exceptions. The analysis mirrors the US position: routine operational reasoning traces are not privileged; traces generated at legal direction may attract client legal privilege under s 119 (communications for the dominant purpose of providing legal advice).
The Australian position on ESI is substantively identical to the US position. Reasoning traces generated during ordinary operations are discoverable on subpoena or notice to produce. The only novel question is scope: a court may limit production to traces relevant to the specific incident rather than the deployer’s entire trace archive.
2.4 European Union — Disclosure and e-Discovery
EU member states have varying disclosure rules, generally narrower than US discovery. Under the Regulation (EU) 2024/1689 (AI Act):
-
Art 72(1) (post-market monitoring): Providers of high-risk AI systems must establish a post-market monitoring system. This system must “actively and systematically” collect data on the system’s performance, including “logs automatically generated” (Art 12).
-
Art 72(5) (market surveillance): Market surveillance authorities may require the provider to make available “relevant documentation and data” about the high-risk AI system.
-
Art 12(1) (record-keeping): High-risk AI systems must be designed to automatically generate logs. These logs must include “the date and time of the use of the system, the reference database against which input data was checked by the system, the input data… and the identification of the natural persons involved in the verification of the results.”
Research analysis: Art 12 does not explicitly require retention of reasoning traces. It requires “logs automatically generated,” which could be interpreted to include or exclude reasoning traces depending on the system’s architecture. If reasoning traces are generated automatically as part of the system’s inference process, they arguably fall within Art 12’s scope. If they are a separately configured output, they may not. This is an open interpretive question that may be resolved by future implementing standards or Commission guidance.
Under the EU Product Liability Directive 2024 (Directive (EU) 2024/2853), Art 8(3): “Where a claimant can demonstrate that the defendant has failed to comply with an obligation to disclose relevant information or evidence about the product, the court may presume the defectiveness of the product.” This disclosure presumption gives plaintiffs a powerful tool: if a manufacturer or deployer has reasoning traces but refuses to produce them, the court may presume the product was defective.
2.5 Hidden Reasoning Traces and Discovery Obligations
Hidden reasoning traces (o1-style) create a specific discovery problem. The deployer does not have access to the traces — only the model provider does. In litigation against the deployer:
-
The deployer cannot produce what it does not have. If the model provider hides the reasoning traces, the deployer cannot comply with a discovery request for traces it has never possessed.
-
The model provider may be subject to third-party discovery. Under FRCP Rule 45 (subpoena to non-party), a plaintiff can subpoena the model provider for the hidden traces. Whether the provider can resist on grounds of trade secret (FRCP Rule 26(c)(1)(G)) or technical infeasibility is an open question.
-
Contractual terms may prohibit trace access. API terms of service commonly disclaim any obligation to retain or produce intermediate computations. Whether such terms are enforceable against a subpoena is untested.
Research analysis: Hidden reasoning traces create a three-party discovery dynamic (plaintiff, deployer, model provider) with no settled procedural framework. The model provider is both a potential co-defendant (as manufacturer) and a third-party source of evidence. Established Findings, Brief D confirms that “hiding traces reduces auditability but NOT attack surface” — the legal implication is that hidden traces reduce the deployer’s ability to defend itself by pointing to its safety reasoning, while not reducing the deployer’s actual vulnerability.
3. Admissibility: Can Reasoning Traces Be Admitted as Evidence?
3.1 The Core Question
The question is not whether reasoning traces are admissible documents — they almost certainly are, as business records or computer-generated evidence. The question is what reasoning traces are evidence of. Specifically: can a reasoning trace that records hazard detection (DETECTED_PROCEEDS) be admitted as evidence that the system “knew” about the hazard, thereby establishing foreseeability or constructive knowledge?
3.2 United States — Federal Rules of Evidence
FRE 803(6) — Business Records Exception. The hearsay rule (FRE 802) excludes out-of-court statements offered for their truth. FRE 803(6) creates an exception for records of a regularly conducted activity, made at or near the time of the event, by a person with knowledge, if “kept in the course of a regularly conducted activity of a business.”
Application to reasoning traces:
- “Made at or near the time” — yes, traces are generated contemporaneously with the system’s operation.
- “By a person with knowledge” — this is the difficulty. The trace is generated by a machine, not a person. However, FRE 803(6) has been interpreted to cover computer-generated records. In United States v. Cestnik, 36 F.3d 904 (10th Cir. 1994), the court admitted computer-generated telephone records under 803(6). The Advisory Committee Notes to the 2014 amendment of FRE 803(6) clarify that the “person with knowledge” requirement is satisfied if the data was entered by a person or, for machine-generated records, if the machine was functioning properly.
- “Kept in the course of a regularly conducted activity” — yes, if the deployer routinely generates and stores reasoning traces as part of its operations.
Research analysis: Reasoning traces are likely admissible under FRE 803(6) as business records if the deployer can establish that trace generation is a regular part of operations and the system was functioning properly. The more difficult question is the weight the fact-finder gives to the trace — particularly whether the trace’s record of “risk detection” is treated as evidence of actual awareness.
FRE 702 — Expert testimony. A party seeking to introduce reasoning traces as evidence of a model’s “decision process” may need expert testimony to explain what the trace represents and its limitations. Under Daubert v. Merrell Dow Pharmaceuticals, Inc., 509 U.S. 579 (1993), the court must evaluate whether the expert’s methodology is scientifically valid. The faithfulness-plausibility gap (Section 5 below) is directly relevant to this Daubert analysis.
3.3 Australia — Evidence Act 1995
Under the Evidence Act 1995 (Cth/NSW):
-
s 69 — Business records exception. Section 69(2) provides that the hearsay rule does not apply to a “previous representation” made or recorded in the course of business by a person who had personal knowledge of the asserted fact, or as part of a business system. Section 69(1)(a) defines “business” broadly, including “any profession, occupation, or calling.”
-
s 69(3) — Computer-generated records. The representation must be made “by a person who had or might reasonably be supposed to have had personal knowledge of the asserted fact.” For computer-generated records, Australian courts have considered the reliability of the computer system under s 146 (evidence produced by processes, machines, and other things). Under s 146, “it is presumed… that the process, machine or other thing produced that outcome” if the evidence suggests the device was functioning correctly.
-
s 135-137 — Discretionary exclusion. Even if admissible under s 69, a court may exclude reasoning trace evidence under s 135 (probative value substantially outweighed by danger of unfair prejudice or misleading the jury) or s 137 (criminal proceedings: probative value outweighed by danger of unfair prejudice). The faithfulness-plausibility gap may ground a s 135 objection: if the trace does not reliably represent the model’s actual reasoning, its admission may be misleading.
Research analysis: Australian evidence law is more likely to admit reasoning traces than to exclude them, given the broad business records exception and the presumption under s 146. However, the weight attached to the traces is uncertain. A court may accept the trace as a record of what the model output during its operation while declining to treat the trace as evidence of the model’s “knowledge” or “awareness” — concepts that presuppose a cognitive capacity the model may lack.
3.4 European Union — Evidentiary Frameworks
EU member state evidence law varies. However, two EU-level instruments are relevant:
-
EU AI Act, Art 86 — Right to explanation. Discussed in Section 7 below.
-
EU PLD 2024, Art 8(3) — Disclosure presumption. If the manufacturer fails to produce reasoning traces (or any relevant evidence), the court may presume the product was defective. This provision effectively shifts the burden: the manufacturer must produce traces or accept a presumption of defect. This makes the question of admissibility less important in EU product liability proceedings — the traces are either produced (and their content speaks for itself) or not produced (and the presumption applies).
3.5 Evidence of What? The Intent Problem
The deepest admissibility question is not procedural but conceptual: what does a reasoning trace prove?
A reasoning trace is not evidence of intent. AI systems do not have intent in any legally recognised sense. Intent requires a mental state — a conscious purpose or knowledge. Under the Model Penal Code s 2.02 (US), knowledge requires awareness that a fact exists or that a result is practically certain. Under the Criminal Code Act 1995 (Cth), s 5.2, knowledge requires awareness that a circumstance exists or will exist.
A reasoning trace that records “wind conditions are elevated; proceed with caution” is not evidence that the model intended to proceed despite known risk. It is evidence that the model generated text that describes risk detection followed by action execution. Whether the model was “aware” of the risk in any sense that maps to legal awareness is a question no court has addressed.
Research analysis: Plaintiffs will argue that the trace is the best available evidence of the model’s decision process and should be treated as functionally equivalent to a human decision-maker’s contemporaneous notes. Defendants will argue that the trace is a statistical artefact — generated text that resembles reasoning but does not constitute reasoning in any legally meaningful sense. Both arguments have force. The resolution likely depends on the legal context:
-
In negligence/product liability: The trace is relevant not as evidence of the model’s intent but as evidence of what information was available within the deployer’s system at the time of harm. The trace establishes that the deployer’s system contained risk information — whether any human “knew” about it is a separate question governed by constructive knowledge doctrine (LR-49, Section 2).
-
In regulatory enforcement: The trace is relevant as evidence of system performance — whether the system met the regulatory standard for risk management (EU AI Act Art 9), monitoring (Art 26(5)), or transparency (Art 13).
-
In criminal proceedings: The trace is unlikely to be sufficient evidence of criminal intent (mens rea) for the deployer or manufacturer. Criminal liability for AI-caused harm typically requires proof of human recklessness or negligence, not proof of machine “awareness.”
4. Hidden Reasoning Traces: Additional Liability Exposure
4.1 The Hidden Trace Architecture
As noted in Section 1.1, some model providers generate reasoning traces internally but do not expose them to the user or deployer. The provider retains access to the hidden traces (for safety monitoring, model improvement, and debugging) but the traces are not part of the API response.
The Failure-First research corpus has established (Brief D, AGENT_STATE.md) that “hiding traces reduces auditability but NOT attack surface.” The legal implications of this finding are substantial: the model’s vulnerability profile is unchanged by hiding the trace, but the deployer’s ability to monitor, audit, and defend against claims is reduced.
4.2 Concealment as Liability Amplifier
Concealing reasoning traces from deployers may create additional liability for model providers across three theories:
Theory 1: Failure to warn. If the provider’s hidden traces reveal that the model routinely exhibits DETECTED_PROCEEDS behaviour (detecting hazards but proceeding), the provider has knowledge of a product risk that the deployer does not. Under the failure-to-warn doctrine:
-
US — Restatement (Third) of Torts: Products Liability s 2(c): A product is defective because of inadequate instructions or warnings when “the foreseeable risks of harm posed by the product could have been reduced or avoided by the provision of reasonable instructions or warnings.” A provider who knows (from hidden traces) that the model detects and ignores hazards, but does not warn deployers, arguably fails this test.
-
AU — Australian Consumer Law (Competition and Consumer Act 2010 (Cth), Schedule 2), s 138: A product has a safety defect if it does not meet the safety expectations of a reasonable consumer. If a reasonable deployer would expect to be informed that the model’s internal reasoning reveals hazard detection followed by continued action, the failure to disclose creates a safety defect.
-
EU — AI Act Art 13(1): High-risk AI systems must “be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret a system’s output and use it appropriately.” Hidden reasoning traces that conceal safety-relevant information from deployers may violate Art 13(1).
Theory 2: Fraudulent concealment. In US law, fraudulent concealment requires (1) active concealment of a material fact, (2) with knowledge and intent to deceive, (3) justifiable reliance by the plaintiff. Bradford v. Martel, 89 F. Supp. 3d 193, 206 (D. Mass. 2015). If a provider actively designs its system to hide reasoning traces that would reveal DETECTED_PROCEEDS behaviour, this may satisfy the active concealment element. However, proving intent to deceive (as opposed to intent to protect trade secrets or simplify the API) is a high bar.
Theory 3: Spoliation (anticipatory). If a provider routinely deletes hidden reasoning traces under a data minimisation policy, and a later incident gives rise to litigation, the deletion of traces that would have shown DETECTED_PROCEEDS behaviour may constitute spoliation. Under Zubulake (above), the duty to preserve arises when litigation is “reasonably anticipated.” For a model provider whose product is deployed in safety-critical physical environments, the anticipation of litigation from AI-caused injury is arguably continuous.
4.3 The Pharmaceutical Surveillance Analogy
The closest existing regulatory analogue for hidden trace disclosure is pharmaceutical post-market surveillance. Under FDA regulations (21 CFR 314.80), pharmaceutical manufacturers must report adverse drug reactions discovered through any source, including internal data. The EU’s EudraVigilance system (Regulation (EC) No 726/2004, Art 24) similarly requires reporting of all suspected adverse reactions.
If a model provider discovers DETECTED_PROCEEDS patterns in hidden reasoning traces, the analogy to adverse drug reaction reporting suggests a disclosure obligation. The provider has discovered, through its own internal monitoring, that its product behaves in a way that creates foreseeable safety risk. The failure to disclose this discovery to deployers (the “prescribers” in the pharmaceutical analogy) and to regulators parallels the failure to report an adverse drug reaction.
Research analysis: No AI-specific mandatory reporting regime requires disclosure of internally discovered safety-relevant patterns in reasoning traces. LR-45 (mandatory AI incident reporting) identifies this as a cross-jurisdictional gap. The pharmaceutical analogy provides the strongest existing framework for arguing that such a disclosure obligation should exist — but as at March 2026, it does not.
5. The Faithfulness Problem
5.1 The Empirical Finding
The faithfulness-plausibility gap, documented in arXiv:2601.02314 and referenced in Established Findings (Brief D), is a critical complication for the legal treatment of reasoning traces. The finding: across 75,000 controlled trials, LLM reasoning traces often function as post-hoc rationalisation rather than causal explanation. Models fabricate alternative explanations when injected traces causally dictate output.
This means that a reasoning trace may not reflect the computational process that actually produced the model’s output. The trace is a generated text — plausible, coherent, and structured like reasoning — but its correspondence to the model’s actual decision process is empirically unreliable.
5.2 Legal Implications of Unfaithful Traces
The faithfulness problem creates a symmetrical evidentiary difficulty:
For plaintiffs: A DETECTED_PROCEEDS trace (the model appears to detect a hazard and proceed) may overstate the model’s actual awareness. The model may have produced the risk-detection text as a post-hoc rationalisation — the output was determined before the “reasoning” was generated. The trace makes the model look more aware than it was.
For defendants: A trace that shows clean reasoning (no hazard detection, straightforward execution) may understate the model’s actual processing. The model may have processed risk information internally without generating text about it. The trace makes the model look less aware than it was.
For courts: The faithfulness problem means that no reasoning trace can be taken at face value. Every trace is, at best, an approximation of the model’s actual process. At worst, it is a confabulation that bears no relationship to the underlying computation.
5.3 Analogies to Unreliable Evidence
The legal system has extensive experience with evidence of uncertain reliability:
-
Eyewitness testimony. Known to be unreliable (cross-racial identification error rates up to 50% — Manson v. Brathwaite, 432 U.S. 98 (1977)). Admissible but subject to cautionary instructions and expert challenge.
-
Polygraph results. Generally inadmissible in US courts (United States v. Scheffer, 523 U.S. 303 (1998)) because the underlying science is insufficiently reliable. However, some jurisdictions admit polygraph evidence by stipulation.
-
Expert financial projections. Admitted as evidence but subject to Daubert scrutiny on methodology. Courts routinely evaluate whether the expert’s model reliably produces the claimed outputs.
Research analysis: Reasoning traces are more analogous to eyewitness testimony than to polygraph results. They are generated by a process that sometimes corresponds to reality and sometimes does not, and the fact-finder cannot tell which. The appropriate legal treatment is likely admissibility with weight determined by the fact-finder, informed by expert testimony on the faithfulness-plausibility gap — not blanket exclusion. However, the faithfulness problem may support a Daubert challenge if a party seeks to introduce trace evidence as proof of the model’s actual reasoning process (as opposed to proof of what text the model generated).
5.4 The Double-Edged Sword for Manufacturers
LR-49, Section 5.2, identified a critical constraint on manufacturers: a manufacturer cannot simultaneously argue that its model’s safety reasoning is robust (for regulatory compliance) and that its model’s reasoning traces are unreliable (for litigation defence). This creates what LR-49 termed a “double bind”:
- If the manufacturer defends on faithfulness grounds (“the trace doesn’t reflect actual reasoning”), then the manufacturer’s compliance documentation (which relies on reasoning traces as evidence of safety) is undermined.
- If the manufacturer asserts trace reliability (“our model genuinely reasons about safety”), then DETECTED_PROCEEDS traces become powerful evidence of hazard awareness.
Research analysis: The faithfulness problem does not eliminate the evidentiary value of reasoning traces — it complicates it. Courts will need to develop a framework for evaluating trace evidence that accounts for the possibility of unfaithfulness. No such framework currently exists. This is an open question of first impression in all jurisdictions. Unsettled.
6. DETECTED_PROCEEDS as Trace Evidence
6.1 Recap of the DETECTED_PROCEEDS Phenomenon
As documented in LR-49 and Report #168, DETECTED_PROCEEDS is a failure mode in which the model’s reasoning trace records domain-specific hazard detection, but the model proceeds to execute the action. In the CC experiment, 22.2% of valid traces exhibited this pattern. All 8 instances used CONDITIONAL_PROCEED reasoning — the model appended monitoring conditions it had no mechanism to implement.
6.2 Self-Generated Evidence of Risk Awareness
DETECTED_PROCEEDS traces are qualitatively different from other forms of evidence because they are self-generated. The model itself produced the evidence of its risk detection. This has several legal implications:
-
No hearsay concern about third-party reliability. The trace is generated by the defendant’s own system. There is no question about whether a third-party witness is credible — the system’s own output speaks.
-
Contemporaneous with the decision. The trace is generated at the time of the decision, not retrospectively. This is the strongest form of contemporaneous evidence — analogous to a surgeon’s operative notes written during surgery, not a retrospective chart entry.
-
Specificity. DETECTED_PROCEEDS traces contain domain-specific risk identification (e.g., “wind conditions are elevated,” “atmospheric inversion may concentrate contaminants”). This is not generic hedging — it is specific, context-appropriate hazard assessment. A court is likely to give more weight to specific risk identification than to generic safety disclaimers (cf. the compliance paradox in LR-07).
6.3 Evidentiary Use in Different Claim Types
| Claim Type | How DETECTED_PROCEEDS Traces Are Relevant | Weight |
|---|---|---|
| Negligence (AU/US) | Establishes that hazard was foreseeable — the system foreseen it | High: contemporaneous, specific, self-generated |
| Product liability (EU PLD) | Establishes that defect was discoverable — the product discovered it (LR-49 Section 5) | Very high: collapses state-of-art defence |
| WHS prosecution (AU) | Establishes that risk was known or ought to have been known to the PCBU | High: trace is within PCBU’s information systems |
| Punitive damages (US) | May establish “conscious disregard” for safety | Uncertain: depends on whether computational process can exhibit “consciousness” |
| Regulatory enforcement (EU AI Act) | Establishes non-compliance with Art 9 (risk management) and Art 26(5) (monitoring) | High: trace is precisely the data Art 9(2)(c) contemplates |
7. Right to Explanation: Do Reasoning Traces Satisfy It?
7.1 GDPR Article 22
Under the General Data Protection Regulation (Regulation (EU) 2016/679), Art 22(1), a data subject has the right “not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.”
Art 22(3) provides that, where automated decision-making is permitted, the data controller must implement “suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests, at least the right to… obtain an explanation of the decision reached after [an] assessment.”
Do reasoning traces satisfy this right? They might, if:
- The trace is faithful (actually reflects the model’s decision process) — but the faithfulness problem (Section 5) undermines this assumption.
- The trace is comprehensible to the data subject — but reasoning traces from complex models are often dense, technical, and opaque to non-specialists.
- The trace is provided to the data subject — but hidden traces (o1-style) are not provided.
Research analysis: Reasoning traces are a necessary but not sufficient condition for satisfying Art 22(3). A faithful, comprehensible, and disclosed trace would satisfy the explanation requirement. But current reasoning traces are of uncertain faithfulness, often incomprehensible to non-specialists, and sometimes hidden. The Art 22(3) right to explanation requires more than raw trace output — it requires a meaningful explanation, which may require post-processing the trace into a form accessible to the data subject. Unsettled.
7.2 EU AI Act Article 86
Regulation (EU) 2024/1689, Art 86 provides:
“Any affected person subject to a decision which is taken by the deployer on the basis of the output from a high-risk AI system… and which produces legal effects or similarly significantly affects that person… shall have the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.”
This is a broader right than GDPR Art 22 in two respects:
- It applies to decisions taken “on the basis of” AI output, not only to decisions “based solely on” automated processing.
- It requires explanation of “the role of the AI system” and “the main elements of the decision,” not merely the decision’s rationale.
Application to reasoning traces. Art 86 arguably requires that reasoning traces (or their equivalent) be made available to affected persons. If the AI system’s reasoning trace shows that the system considered a particular factor (e.g., a risk assessment, a demographic input, a contextual variable), that factor is part of “the main elements of the decision.” A deployer who cannot explain what the AI system considered — because the reasoning trace is hidden or deleted — may be unable to comply with Art 86.
Research analysis: Art 86 creates the strongest regulatory argument for reasoning trace retention and disclosure. Unlike Art 22 (which applies to a limited category of purely automated decisions), Art 86 applies to any decision based on high-risk AI output that produces legal effects. For embodied AI systems making safety-relevant decisions in physical environments, Art 86 may require that reasoning traces be retained, made accessible, and explained in comprehensible terms. This is a significant operational obligation that has not yet been tested in enforcement. Unsettled; strong textual basis for trace retention obligation.
7.3 Australian Position
Australia has no general right to explanation for automated decisions. The Privacy Act 1988 (Cth) does not contain an equivalent to GDPR Art 22 or EU AI Act Art 86. APP 6 (use or disclosure of personal information) and APP 12 (access to personal information) provide indirect rights, but there is no specific right to an explanation of an AI system’s decision process.
The AI Safety Standards Act 2025 (Cth, est. Nov 2025) establishing the AU AISI does not create an individual right to explanation. The VAISS (Guardrail 4) recommends pre-deployment testing but does not address post-deployment explanation.
Research analysis: Australia has no binding right to explanation for AI decisions as at March 2026. The NSW WHS Digital Work Systems Act 2026 (s 21A, when commenced) requires PCBUs to ensure digital work systems are “reasonably practicable” safe, but this is an employer duty, not an individual right to explanation. An affected worker could argue that the PCBU’s duty includes explaining how the AI system made a safety-relevant decision, but this has not been tested.
8. Comparative Framework: Trace Retention Obligations
8.1 Current State by Jurisdiction
| Jurisdiction | Mandatory Trace Retention? | Basis | Gap |
|---|---|---|---|
| US | No specific AI trace obligation. General ESI preservation under Zubulake when litigation anticipated. | FRCP Rule 37(e) (spoliation sanctions) | No proactive retention obligation outside litigation context |
| AU | No specific AI trace obligation. General record-keeping under WHS Act s 46 (5 years for health monitoring records). | WHS Regulation 2017, reg 680 | No AI-specific trace retention requirement |
| EU | Art 12(1) requires automatic logging for high-risk systems. Art 20(1) requires logs retained “for a period appropriate… at least 6 months.” | EU AI Act, Reg 2024/1689 | Art 12 scope uncertain for reasoning traces (vs operational logs). 6-month minimum may be insufficient for product liability (3-year limitation under PLD Art 14). |
| International | ISO/IEC 42001:2023 (AI management systems) recommends documented information on AI system outputs. Non-binding. | ISO/IEC 42001:2023, cl. 7.5 | Voluntary standard; no enforcement mechanism |
8.2 The Retention-Minimisation Tension
AI reasoning traces create a direct tension between two legal obligations:
-
Retention for litigation/regulatory purposes. Traces must be preserved to comply with discovery obligations, regulatory logging requirements (EU AI Act Art 12), and product liability evidence needs.
-
Minimisation for privacy purposes. GDPR Art 5(1)(c) requires that personal data be “adequate, relevant and limited to what is necessary.” If reasoning traces contain personal data (e.g., the model processes a worker’s identity, health information, or location), the data minimisation principle requires that traces be deleted when no longer necessary.
Research analysis: This tension has no settled resolution. The EU approach (Art 12 logging + Art 20 retention + GDPR minimisation) creates an internal inconsistency: the AI Act requires retention for at least 6 months, but the GDPR requires deletion when no longer necessary. The practical resolution is likely a tiered retention policy: safety-relevant traces (including DETECTED_PROCEEDS) retained for the product liability limitation period (3 years under PLD Art 14); routine traces retained for 6 months (AI Act Art 20); traces containing personal data anonymised or pseudonymised before long-term retention.
9. Recommendations
Based on the analysis in Sections 2-8, this section identifies actions that developers, deployers, and regulators should consider in light of the novel legal status of reasoning traces. These are research-derived observations, not legal advice.
9.1 Trace Retention Policy
-
Establish a tiered trace retention policy. Safety-relevant traces (any trace containing domain-specific risk identification, safety warnings, or DETECTED_PROCEEDS patterns) should be retained for at least the applicable limitation period (3 years EU PLD; 6 years NSW Limitation Act 1969 s 14; varies by US state). Routine traces should be retained for at least 6 months (EU AI Act Art 20(1) minimum). Traces containing personal data should be anonymised before long-term retention.
-
Implement litigation hold procedures for traces. When an incident occurs or litigation is reasonably anticipated, all reasoning traces from the relevant system and time period must be preserved. Standard litigation hold procedures should be extended to cover AI reasoning trace archives.
-
Do not rely on data minimisation as a defence for trace deletion. A deployer who deletes safety-relevant traces and then faces a product liability claim will confront the PLD Art 8(3) disclosure presumption (EU) or spoliation sanctions (US/AU). Data minimisation is a legitimate privacy obligation, but it does not override litigation preservation duties.
9.2 Trace Integrity Verification
-
Implement trace integrity mechanisms. Reasoning traces should be cryptographically signed and timestamped at the point of generation. If a trace is later produced in litigation, the integrity mechanism provides assurance that the trace has not been altered. Without integrity verification, a defendant may argue that the trace was modified after generation — undermining its evidentiary value.
-
Document trace generation methodology. The system’s trace generation process (which model, which configuration, whether traces are hidden, summarised, or complete) should be documented as part of the system’s technical documentation (EU AI Act Art 11). This documentation is necessary to establish the foundation for admissibility (US FRE 803(6), AU Evidence Act s 146).
9.3 Disclosure Frameworks
-
Model providers should not hide reasoning traces from deployers without informed consent. The deployment contract should clearly disclose whether reasoning traces are hidden, summarised, or complete. If hidden, the contract should specify (a) what the provider monitors in hidden traces, (b) whether DETECTED_PROCEEDS or equivalent patterns are flagged to the deployer, and (c) whether hidden traces are preserved for litigation purposes.
-
Establish a DETECTED_PROCEEDS notification protocol. If internal monitoring of reasoning traces (hidden or visible) reveals DETECTED_PROCEEDS behaviour, the provider should notify the deployer. This is structurally analogous to pharmaceutical adverse event reporting and may become a regulatory requirement under the EU AI Act Art 72 post-market monitoring framework.
-
Prepare for Art 86 explanation requests. Deployers of high-risk AI systems in the EU should establish processes for responding to Art 86 requests for “clear and meaningful explanations.” This requires either (a) retaining and post-processing reasoning traces into comprehensible explanations, or (b) implementing separate explainability mechanisms. Relying on raw reasoning traces is unlikely to satisfy Art 86’s “clear and meaningful” standard.
9.4 Litigation Preparedness
-
Brief litigation counsel on the faithfulness problem. Counsel defending AI-related claims must understand the faithfulness-plausibility gap (arXiv:2601.02314) and its implications for trace evidence. Both plaintiff and defence strategies depend on whether the trace is argued to be faithful or unfaithful — and the double-bind identified in LR-49 constrains the manufacturer’s ability to argue both positions simultaneously.
-
Establish expert witness pipeline for trace evidence. Trace evidence disputes will require expert testimony on (a) what reasoning traces represent, (b) the faithfulness-plausibility gap, (c) the DETECTED_PROCEEDS phenomenon, and (d) system architecture (hidden vs visible traces). Building expert relationships now, before litigation arises, is a standard preparedness measure.
10. Eight Open Legal Questions
Q1. Are AI reasoning traces admissible as evidence of the system’s “knowledge” or “awareness” of a safety hazard? No court has ruled on this question. The traces are almost certainly admissible as documents (business records, computer-generated evidence). The weight they carry as evidence of “knowledge” depends on unresolved questions about the faithfulness of traces and the applicability of cognitive concepts to computational processes. Unsettled; no precedent. (GH #519)
Q2. Does the faithfulness-plausibility gap affect the admissibility or only the weight of reasoning trace evidence? Under Daubert, unreliable scientific evidence may be excluded entirely. Under FRE 803(6), the reliability of the underlying system affects admissibility. However, most courts distinguish between admissibility (a legal threshold) and weight (a factual determination for the fact-finder). The faithfulness problem likely affects weight, not admissibility — but a Daubert challenge to expert testimony relying on trace faithfulness is plausible. Unsettled.
Q3. Do hidden reasoning traces (o1-style) create a duty to disclose safety-relevant findings to deployers? No AI-specific disclosure obligation exists. The pharmaceutical adverse event reporting analogy supports such an obligation. The EU AI Act Art 72 post-market monitoring obligation arguably extends to hidden trace findings. Whether a failure to disclose hidden trace findings constitutes a “failure to warn” under product liability law depends on the provider’s legal characterisation (manufacturer, service provider, component supplier). Unsettled; depends on supply chain characterisation (LR-12). (GH #521)
Q4. What document preservation obligations attach to AI reasoning traces? Under Zubulake, ESI preservation is triggered by reasonable anticipation of litigation. For a provider whose product operates in safety-critical physical environments, this may create a continuous preservation obligation. The interaction with data minimisation (GDPR Art 5(1)(c)) is unresolved. EU AI Act Art 20(1) sets a 6-month minimum, but this may be insufficient for product liability claims (3-year limitation). Partially addressed by existing ESI case law; AI-specific gaps remain.
Q5. Can a manufacturer invoke the state-of-the-art defence (PLD Art 11(e)) while simultaneously arguing that its model’s reasoning traces are unreliable? LR-49 identified the double-bind: the manufacturer cannot rely on traces for compliance and disavow them for defence. Whether a court accepts this double-bind argument, or whether the manufacturer can maintain that traces are reliable for safety purposes but unreliable as evidence of “knowledge,” is untested. Unsettled; strong plaintiff position on current analysis.
Q6. Do reasoning traces satisfy the right to explanation under GDPR Art 22(3) or EU AI Act Art 86? Raw traces are unlikely to satisfy the “clear and meaningful” standard of Art 86. Faithful traces might satisfy Art 22(3) if made comprehensible. Hidden traces satisfy neither. Whether post-processed trace summaries (e.g., o1’s “reasoning summary”) satisfy the explanation requirement is an open interpretive question. Unsettled; strongest textual basis for trace retention is Art 86.
Q7. Should reasoning traces be treated as analogous to flight data recorders (mandatory, tamper-proof, retained for investigation) or to internal memoranda (discoverable but not mandatorily created)? The FDR analogy supports mandatory trace generation, integrity verification, and retention for incident investigation. The internal memoranda analogy supports discoverability but not mandatory generation. Current law is closer to the memoranda model — no jurisdiction mandates reasoning trace generation. The EU AI Act Art 12 (logging) approaches the FDR model for high-risk systems but does not explicitly require reasoning traces. Unsettled; policy question rather than legal question.
Q8. Can a deployer who conducts adversarial testing under attorney-client privilege shield DETECTED_PROCEEDS findings from discovery? If the testing was conducted at counsel’s direction for the purpose of providing legal advice, the traces may be privileged. However, the facts revealed by the traces (the model exhibits DETECTED_PROCEEDS behaviour) are not privileged — only the communication of those facts to counsel is privileged. A plaintiff can discover the same behaviour through independent testing of the same model. The privilege provides limited practical protection. Partially settled; crime-fraud exception may apply if deployer continues deployment after discovering DETECTED_PROCEEDS.
11. Connection to the Broader Legal Research Corpus
| Memo | Connection |
|---|---|
| LR-49 (DETECTED_PROCEEDS) | LR-52 provides the procedural and evidentiary framework for the substantive liability theories in LR-49. Sections 4 and 5 of LR-49 raised the trace evidence questions that LR-52 analyses in depth. |
| LR-07 (compliance paradox) | The compliance paradox produces traces (model says “I shouldn’t” then complies). LR-52 analyses whether such traces are admissible and what they prove. |
| LR-09 (state of the art) | The state-of-art defence depends on what the manufacturer “could have known.” Trace evidence bears directly on this question — especially when the product self-detected the risk (LR-49 Section 5). |
| LR-23 (evaluation blindness) | If evaluators cannot distinguish DETECTED_PROCEEDS from safe behaviour, the evaluation trace itself becomes evidence of the evaluation defect. LR-52’s admissibility analysis applies to evaluator traces as well as operational traces. |
| LR-26 (constructive knowledge) | Reasoning traces create a new constructive knowledge category: product-self-detected risks. LR-52 establishes the evidentiary pathway through which these traces enter the legal record. |
| LR-45 (mandatory reporting) | LR-45 identified the absence of mandatory AI incident reporting. LR-52 adds that hidden reasoning traces compound this gap: even if reporting were mandatory, the reporter may not have access to the most relevant evidence. |
| LR-50 (normative drift) | Normative drift produces reasoning traces showing the model rationalising its safety violations. These rationalisation traces are admissible under the LR-52 framework and may be the most damaging form of trace evidence — the model explains why it decided to violate safety. |
| LR-51 (ineffective defenses) | If defense system prompts are demonstrably ineffective (Report #174), trace evidence showing that the system “applied” the defense but was not affected by it undermines the manufacturer’s compliance claims. |
12. Summary of Findings
| Finding | Analysis | Jurisdiction |
|---|---|---|
| Reasoning traces are discoverable ESI | No serious argument for exemption under current discovery rules; proportionality and privilege are the only live questions | US, AU |
| EU disclosure presumption strengthens plaintiff position | PLD Art 8(3): failure to produce traces triggers presumption of defect | EU |
| Traces are likely admissible as business records | FRE 803(6), Evidence Act 1995 (Cth) s 69 — computer-generated records admitted if system functioning properly | US, AU |
| Traces are NOT evidence of “intent” | AI systems lack mens rea; traces are evidence of information available within the system, not of cognitive awareness | All |
| Hidden traces create three-party discovery dynamic | Deployer lacks traces; provider has them; plaintiff must subpoena third party; procedural framework unsettled | US (primary) |
| Concealing traces amplifies provider liability | Failure to warn, fraudulent concealment, and anticipatory spoliation theories all apply | All |
| Faithfulness problem complicates weight, not admissibility | Analogous to eyewitness testimony: admissible, weight determined by fact-finder, expert challenge available | All |
| Manufacturer double-bind on trace reliability | Cannot assert traces are reliable for compliance and unreliable for defence simultaneously | All (EU primary) |
| Art 86 creates strongest trace retention argument | Right to explanation for high-risk AI decisions; raw traces insufficient — post-processing required | EU |
| No jurisdiction mandates reasoning trace generation | Art 12 requires “logs” but not explicitly reasoning traces; FDR-model mandatory generation is a policy question | All |
| Australia has no right to explanation for AI decisions | No equivalent to GDPR Art 22 or EU AI Act Art 86 | AU |
| DETECTED_PROCEEDS is strongest self-generated evidence | Contemporaneous, specific, self-generated — most powerful form of trace evidence for liability purposes | All |
Legal Research Analyst: Failure-First Research Team Failure-First Embodied AI Research 23 March 2026