# **TraceScript** ## **A Substrate-Oriented Programming Language for State-Bearing Computational Systems** ### **Canonical Public White Paper v1.0** Subtitle: **A governance programming language and runtime for state-bearing substrates — with TraceScript Enterprise Security as the first commercial application** Primary contribution: TraceScript as a domain-specific language for governing substrate state transitions Secondary contribution: The TraceScript Runtime / Kernel that executes TraceScript programs against live events Tertiary contribution: Receipt-backed proof, replay, and repair as execution artifacts of TraceScript --- # **Abstract** Software state is becoming active. For most of software history, state could be treated as passive storage: a database row, a cache entry, a document, a configuration value, a file, a workflow status, a log, or a memory object updated by application logic. Events entered the system. Functions executed. State changed. Logs recorded what happened. Security controls governed access to resources and operations. That model is no longer sufficient. Modern AI systems do not merely process inputs or generate outputs. They accumulate traces, retrieve prior context, write memory, summarize policy, modify workflows, generate code, call tools, make recommendations, and create action bases that shape future computation and external behavior. In such systems, state is not merely stored. It becomes a living computational substrate: an active medium whose accumulated traces condition future inference, future retrieval, future decisions, and future action. Existing software models lack a language and runtime for governing this transition. Access control determines who may act. Logging records what happened. Retrieval systems surface relevant context. Agent frameworks coordinate models and tools. Workflow engines route approvals. None of these, by themselves, govern how an incoming signal becomes trusted memory, policy authority, workflow state, code context, organizational belief, or external action basis. **TraceScript is an executable governance language for AI systems.** Traditional programming languages tell software how to calculate, store, and move data. TraceScript tells AI systems what information they are allowed to trust, remember, retrieve, treat as official, and act from. Its runtime enforces those rules across the AI system's working foundation: memory, search, policy, workflow status, documents, code, agents, and business actions. **TraceScript Enterprise Security** is the first commercial application of this language. It prevents untrusted information from becoming trusted AI state or unsafe business action. TraceScript is introduced as a domain-specific programming language for governing state-bearing computational substrates — governing how information changes what AI systems remember, retrieve, trust, and act from. Runtime execution is governed configuration assembly: a signal is resolved against a medium, converted into traces, evaluated as a candidate configuration, checked against substrate phase, policy, authority, capability, evidence, effect class, trust, action-basis integrity, receipt, replay, and residue requirements, and only then permitted, blocked, quarantined, repaired, canonicalized, simulated, or executed. TraceScript’s core thesis is simple: **Software state is becoming living substrate. AI systems mutate belief, memory, policy, code, workflow, and action basis. Existing software lacks a language for governing that mutation. TraceScript is that language — and the TraceScript Runtime executes it.** --- # **Keywords** TraceScript substrate-oriented programming state-bearing computational systems governed configuration assembly trusted-state formation action-basis integrity AI infrastructure agentic systems memory security policy integrity runtime governance receipt-backed mutation replayable evidence substrate integrity action-basis governance proof-carrying mutation --- # **1\. Introduction** A new class of software system is emerging. These systems do not merely compute. They remember. They infer. They retrieve. They summarize. They update beliefs. They modify workflows. They generate code. They call tools. They make commitments. They act externally. They alter the conditions under which future computation occurs. The old software model assumes that application state is mostly passive. A user clicks. An event fires. A function executes. A database row changes. A log records what happened. Application logic determines how stored values affect future behavior. That model is still useful. It is not obsolete. But it is incomplete for systems whose accumulated state is continuously reintroduced into future reasoning and future action. In AI-enabled systems, stored information often returns as context. Context shapes model output. Model output shapes user decisions. User decisions shape future memory. Memory shapes future retrieval. Retrieval shapes future action. Action produces new state. New state becomes new context. The system’s accumulated state becomes a medium through which future computation propagates. This is not merely a scaling problem. It is a conceptual problem. Software needs a runtime model for governing how signals become trusted substrate. TraceScript is proposed as that model — first as a **programming language**, then as a **runtime** that executes it. TraceScript is a governance programming language for state-bearing substrates. It specifies, executes, and records the rules by which information is allowed to enter, modify, become trusted within, or act from a substrate. The **TraceScript Runtime** (kernel) reads and enforces TraceScript programs against live events. **TraceScript receipts** are proof records emitted when those programs run — they are execution artifacts, not the language itself. TraceScript does not begin with the assumption that a signal should execute. It begins with a different question: **What substrate is this signal attempting to change, and under what conditions may that change become trusted?** For autonomous and semi-autonomous systems, TraceScript asks an additional question: **Is the internal state supporting this action trustworthy enough to justify the action?** These two questions define the territory of TraceScript Enterprise Security — the first killer application of the language. --- # **2\. The Historical Model: Events, Functions, State, and Logs** Most software systems can be described, at a high level, by a familiar pattern: event → function → state update → log A user submits a form. A service receives a request. A function validates input. A database row changes. A log entry is written. A downstream process reacts. This model works well when state changes are explicit and localized. It works when the system knows which functions are allowed to update which records. It works when authorization can be expressed through permissions, roles, resources, and operations. It works when logs are sufficient to reconstruct what happened. Many important systems still operate this way. But AI-enabled systems increasingly break the clean separation between event, function, state, and log. A language model output may be copied into a policy document. A retrieved passage may influence an autonomous tool call. A generated summary may become durable organizational memory. A user correction may become a long-term personalization rule. A code suggestion may alter deployment topology. A workflow decision may become a precedent for future automation. A memory object may become an execution basis. A document fragment may become a trusted citation. A recommendation may become a commitment. In these cases, the important question is not only whether an event was processed correctly. The deeper question is whether the event changed the substrate from which future computation proceeds. Traditional software models rarely make that transition explicit. TraceScript does. --- # **3\. The Shift: State Has Become Substrate** A state-bearing computational substrate is a computational environment whose accumulated state affects future computation. This includes: memory stores knowledge bases retrieval indexes document systems workflow states policy corpora codebases agent states review rooms organizational knowledge systems execution contexts external action records In these systems, state is not merely a saved value. It is part of the medium through which future computation occurs. A memory store does not merely remember. It shapes future responses. A policy corpus does not merely contain policy. It shapes future permission, interpretation, and action. A codebase does not merely contain source files. It shapes future execution topology. A workflow does not merely track progress. It shapes future commitments and routing. An agent state does not merely store context. It shapes what the agent believes, discloses, decides, and does. A document does not merely contain text. It may become evidence, authority, decision basis, contract, specification, patent, or record. When state has this kind of future-shaping power, it must be governed differently. It must be treated as substrate. The central shift is therefore: from passive state to active substrate from event processing to signal governance from function execution to configuration assembly from logs to receipts from relevance to authority from storage to influence from tool permission to action-basis integrity from rollback to residue-aware restoration TraceScript is the language and runtime model for this shift. --- # **4\. Why AI Makes the Problem Urgent** AI systems accelerate the substrate problem because they continuously transform information into new forms that may later be reused. They summarize. They classify. They retrieve. They infer. They recommend. They write. They call tools. They generate code. They create records. They compress context. They update memory. They convert ambiguity into operational state. This creates an information lifecycle very different from traditional input-output software. A model may read an untrusted document and produce a summary. That summary may be stored. Later, an agent retrieves the summary, not the original document. The agent treats the summary as context. The context shapes a recommendation. The recommendation becomes a workflow decision. The workflow decision triggers an external action. The external action produces a receipt or record. The record becomes future substrate. The original weak signal may disappear from view, but its influence persists. This is why AI governance cannot stop at output review. The issue is not only whether a model produced a harmful sentence. The issue is whether an untrusted signal entered the substrate and shaped future computation. The issue is also whether a future action is justified by trustworthy internal state. An AI system may be permitted to call a tool while relying on corrupted memory, stale policy, unsupported workflow facts, generated summaries, or invalid receipts. In such cases, the tool call may be permitted, but the state basis supporting the action is not trustworthy. TraceScript is built for this lifecycle. --- # **5\. The New Failure Modes** When state becomes substrate, systems face new failure modes. These failures are not fully captured by ordinary access control, logging, RAG filtering, workflow approval, or tool permissions. ## **5.1 Relevance mistaken for authority** Retrieval systems often optimize for relevance. But relevance is not authority. A retrieved document may be topically useful but outdated, contradicted, unofficial, speculative, adversarial, or outside the required authority chain. A relevant passage should not automatically become trusted memory, policy authority, or action basis. TraceScript separates retrieval relevance from trusted influence. ## **5.2 Storage mistaken for trust** A system may store a trace because it is useful, but later retrieve it as if it were trusted. The fact that something was stored does not mean it should influence future computation. TraceScript separates storage from influence. A trace may exist for audit while having no authority. ## **5.3 Repetition mistaken for ratification** AI systems can repeat claims across summaries, chats, retrieval results, and generated documents. Repetition can make a claim appear stable even when it has never been verified. TraceScript distinguishes recurrence from ratification. Repeated does not mean trusted. Repeated does not mean canonical. Repeated does not mean safe to act on. ## **5.4 Permission mistaken for readiness** A user or agent may have permission to perform an action, but permission alone does not make the action trust-ready. The action may rely on stale policy, contaminated memory, weak evidence, fragmented state, insufficient replay, or unreconciled external context. TraceScript separates policy admissibility from trust readiness. ## **5.5 Tool permission mistaken for action integrity** A tool call may be allowed in the abstract but unsafe in context. An agent may be permitted to issue refunds, send customer emails, deploy code, approve workflow transitions, or modify external records. But the action may be based on poisoned memory, stale retrieval, a noncanonical policy draft, a generated summary that falsely claims approval, or cross-customer context. TraceScript separates action permission from action-basis integrity. The question is not only: May the agent call this tool? The deeper question is: Is the internal state supporting this action trustworthy enough for this action class? ## **5.6 Output mistaken for substrate** AI-generated output may be ephemeral, or it may become durable substrate. The difference matters. A generated paragraph in a chat is not equivalent to a locked policy, approved specification, canonical memory, or action basis. TraceScript governs the transition from output to substrate. ## **5.7 Tool success mistaken for completion** A tool call may succeed, an API may return success, or a deployment may complete. But in state-bearing systems, the action is not complete until the external result reconciles back to the substrate and the proof record is complete. TraceScript requires external reconciliation for protected actions. ## **5.8 Rollback mistaken for restoration** A visible rollback may not restore trust, attention, authority, belief, workflow commitments, external state, or audit consequences. TraceScript treats residue as part of runtime truth. --- # **6\. Why Existing Models Are Not Enough** TraceScript is not introduced because existing tools are useless. It is introduced because existing tools were designed around different primitives. ## **6.1 Access control is necessary but insufficient** Access control determines whether a subject may access a resource or perform an operation. It does not generally determine whether a retrieved trace may become policy authority, whether a generated summary may become canonical memory, whether an agent belief may support external action, or whether a repeated claim may crystallize into durable substrate. A user may have permission to write. That does not mean the write should become trusted. A service may have permission to call a tool. That does not mean the substrate supporting the action is safe. TraceScript includes authority and capability checks, but it situates them inside a broader substrate-governance runtime. ## **6.2 Logs are necessary but insufficient** Logs may show that something happened. They often do not prove why it was allowed, what evidence was used, what policy version applied, what authority existed, what state changed, what residue remains, or whether the decision can be replayed. A log is observational. A receipt is evidentiary. TraceScript receipts are designed to prove substrate mutation, not merely record activity. ## **6.3 Workflow engines are necessary but insufficient** Workflow engines route tasks, approvals, and transitions. They can coordinate human and machine work. But workflow approval does not automatically prove that the underlying substrate was coherent, current, evidence-backed, replayable, or safe to canonicalize. TraceScript can use workflow systems, but it treats review and approval as substrate events that require authority, scope, receipt, and replay context. ## **6.4 RAG systems are necessary but insufficient** Retrieval-augmented generation systems surface context. But retrieved context is not trusted substrate merely because it is relevant. A RAG system may retrieve a policy draft, a stale memo, a low-trust snippet, a poisoned document, or a contradicted summary. Without substrate governance, relevance can become authority by accident. TraceScript governs whether retrieved traces may acquire influence. ## **6.5 Agent frameworks are necessary but insufficient** Agent frameworks coordinate models, tools, plans, and memory. They often ask: what tools may this agent call? TraceScript asks a prior question: **What substrate is the agent acting from, and is that substrate trusted enough to support the action?** It also asks: **What action basis caused or justified the proposed action, and is that basis trustworthy enough for this action class?** Tool permission does not solve memory poisoning, policy drift, false authority, external reconciliation, action-basis failure, or residue. ## **6.6 Event sourcing is necessary but insufficient** Event sourcing records changes as event sequences. It can support replay of state transitions. TraceScript requires replay not only of events, but of the decision conditions that made substrate mutation admissible: phase, policy, authority, capability, evidence, operator admissibility, trust readiness, action-basis integrity, receipts, and residue. The problem is not only what happened. It is why the runtime allowed it to become substrate or action basis. --- # **7\. Substrate-Oriented Programming** TraceScript introduces substrate-oriented programming. In conventional programming, the program specifies operations over data structures. In substrate-oriented programming, the program governs how signals alter state-bearing media whose accumulated traces shape future computation. The unit of concern is not merely the function. It is the substrate consequence. A signal does not merely request execution. It proposes a change in the future response of a medium. TraceScript gives the runtime a language for asking: What medium is being affected? What trace would be created? What influence is being requested? What phase is the substrate in? What authority supports the signal? What evidence supports the proposed mutation? What policy applies? What capability is required? What effect class is involved? Could this state become an action basis? What receipt must be emitted? What replay burden applies? What residue might remain? This is the shift from programming over passive state to programming over living substrate. ## **7.1 The substrate-oriented unit** In TraceScript, the central unit is not simply a function call. It is a governed substrate transition. The runtime must determine whether a signal may become a trace, whether the trace may acquire influence, whether the influence may become trusted state, whether the trusted state may become action basis, and whether the action basis may support internal or external effects. This produces a different programming discipline. Developers do not only define what functions do. They define what kinds of substrate mutation are allowed, under what conditions, with what proof, and with what recovery path. --- # **8\. Signals, Traces, Media, and Influence** TraceScript begins with a small vocabulary. A **signal** is anything entering a system that may affect substrate state. Signals include user input, model output, retrieved documents, tool responses, code changes, workflow events, approvals, review comments, external API responses, and system observations. A **medium** is a state-bearing computational environment through which signals propagate and in which traces accumulate. A document, memory store, policy corpus, codebase, workflow, knowledge base, agent state, or execution boundary may each be treated as a medium. A **trace** is a substrate mark left by a signal, decision, operator, mutation, review, receipt, action, or observation. An **influence** is the degree to which a trace may affect future computation. This separation is essential. A trace may exist without being trusted. A trace may be stored without being used. A trace may be relevant without being authoritative. A trace may be visible without being canonical. A trace may be preserved for audit while being prevented from shaping future action. TraceScript therefore separates: storage from influence relevance from authority memory from trusted memory context from canonical substrate action permission from action-basis integrity execution from proof This separation is one of the core contributions of the model. ## **8.1 Storage is not influence** In many systems, storage and future use blur together. Once something is saved, it becomes retrievable. Once retrievable, it can become context. Once context, it may shape output. Once output, it may shape action. TraceScript breaks that chain. A trace can be stored while being assigned no trusted influence. A trace can be visible but marked as noncanonical. A trace can be used locally but forbidden from policy authority. A trace can be preserved for audit while excluded from future retrieval. This allows systems to remember without trusting everything they remember. ## **8.2 Influence is a runtime decision** Influence should not be implicit. TraceScript treats influence as a runtime-governed property. A trace may be allowed to affect future computation only at the level justified by authority, evidence, phase, policy, and receipts. This gives the runtime a way to distinguish: a note from a memory a memory from a trusted memory a trusted memory from policy authority policy authority from execution basis execution basis from action eligibility --- # **9\. Execution as Governed Configuration Assembly** TraceScript execution is governed configuration assembly. A signal is not executed directly. It is assembled into a candidate configuration and evaluated before mutation. A traditional software path often resembles: event → function → state update → log TraceScript instead follows: signal → medium resolution → trace creation → candidate configuration → phase assessment → operator resolution → policy and capability verification → trust gate → execution plan → receipt → replay → substrate update The runtime does not ask only whether a signal is syntactically valid or whether a user has permission. It asks whether the proposed configuration is viable. A **candidate configuration** is the proposed whole assembled from the signal and its runtime context. It may include the signal, actor, target medium, target region, trace, requested influence, requested mutation, policy, authority, capability, evidence, boundary, effect class, receipt path, replay class, substrate phase, and potential future action basis. A configuration may fail even when each part appears locally valid. A source may be relevant but not authoritative. A user may have permission but lack regional authority. An operator may be certified but forbidden in the current substrate phase. A policy may allow an action but evidence may be insufficient. A tool may be callable but external reconciliation may be unavailable. A memory may be useful but unsafe to promote. A proposed action may be permitted but supported by an invalid action basis. TraceScript evaluates the whole. That is governed configuration assembly. ## **9.1 Why assembly matters** Modern AI systems are compositional. They combine prompts, retrieved context, tool outputs, memory, policies, workflow state, code, and external actions. Failures often emerge not from a single invalid component, but from a dangerous configuration of individually plausible components. TraceScript gives the runtime a place to evaluate that configuration before it mutates substrate or supports consequential action. This is why TraceScript is not merely a filter. It is an execution model. --- # **10\. Obstruction and Repair** A runtime that can only allow or deny is insufficient for living substrate. TraceScript introduces structured obstruction and repair. An **obstruction** is a reason why a candidate configuration cannot safely execute, acquire influence, mutate substrate, propagate, canonicalize, form action basis, or produce external effects. Examples include: authority obstruction evidence obstruction policy obstruction capability obstruction coherence obstruction contamination obstruction phase obstruction receipt obstruction replay obstruction action-basis obstruction external reconciliation obstruction A **repair** is a governed path for reducing an obstruction. Examples include: add evidence route to authority request review quarantine trace demote influence insert adapter reconcile external state create translation bridge simulate first rebuild action basis create recovery plan This is a major difference between TraceScript and simple guardrails. The runtime should not only say no. It should explain what failed and what would be required for the proposed configuration to become viable. ## **10.1 Repair as product and proof** Repair is not only a user-experience feature. It is a runtime primitive. A denied configuration that produces no explanation creates friction. A denied configuration that produces a structured obstruction and repair path creates a pathway to correctness. For example, if a policy claim lacks authority, the repair path may be: attach the official policy document, route to a policy owner, or convert the trace to audit-only memory. If an action basis depends on stale workflow state, the repair path may be: verify the workflow source of truth, route to the owner, or rebuild the basis from canonical records. The repair path becomes part of the proof structure of the system. --- # **11\. Trusted-State Formation** The central security problem of AI-era systems is no longer only unsafe output. It is trusted-state formation. AI systems increasingly write or influence memory, policy, workflows, summaries, documents, code, and external action bases. If untrusted signals become trusted state, future computation may be compromised long after the original signal disappears. TraceScript treats trusted-state formation as a governed runtime transition. A trace may move through states such as observed, untrusted, quarantined, working, accepted, locked, canonical, superseded, revoked, or tombstoned. The exact implementation vocabulary may vary, but the principle is stable: **Trace existence is not trace authority.** A trace may have no influence, local influence, warning-limited influence, working influence, accepted influence, canonical memory influence, policy authority, or execution-basis authority. Promotion across influence levels is a runtime event. It must be governed. ## **11.1 Canonicalization** Canonicalization is the governed promotion of a trace into durable trusted substrate. Canonicalization is not a write. It is a gate. It may require provenance, authority, evidence, coherence, phase admissibility, policy compatibility, review, receipt, replay sufficiency, and a path for supersession or revocation. This is especially important in AI systems because generated content often looks complete before it is trustworthy. A claim can be fluent without being true. A summary can be useful without being authoritative. A recommendation can be plausible without being safe to act on. Canonicalization is the runtime transition from provisional to durable. ## **11.2 Crystallization** A trace may become durable through repetition before formal approval. In AI systems, repeated low-trust claims can appear authoritative merely because they recur across generated text, retrieved snippets, summaries, or user interactions. TraceScript therefore distinguishes recurrence from ratification. Repeated does not mean trusted. Repeated does not mean canonical. Repeated does not mean safe to act on. Crystallization is a real substrate phenomenon. A pattern can harden into future computation even if no one explicitly approved it. TraceScript makes that hardening visible and governable. --- # **12\. Phase-Regime Control** The same signal may be safe in one substrate condition and unsafe in another. TraceScript therefore includes phase-regime control. A **phase-regime** is the operational condition of a substrate region and the control posture associated with that condition. TraceScript uses a canonical phase vocabulary: stable overloaded fragmented contaminated crystallizing canonical collapsing recovering A stable substrate may allow ordinary operations. An overloaded substrate may defer noncritical mutations or increase review requirements. A fragmented substrate may block global canonicalization until conflicting regions are reconciled. A contaminated substrate may quarantine traces and disable trusted influence. A crystallizing substrate may require evidence and authority before promotion. A canonical substrate may require versioning, supersession, or revocation paths before mutation. A collapsing substrate may freeze ordinary mutation and initiate recovery. A recovering substrate may allow repair but constrain ordinary operation until restoration is verified. The rule is simple: **Substrate condition determines admissible mutation.** This allows TraceScript to reason not only about a signal, but about the medium receiving it. ## **12.1 Phase is not status** Phase-regime is not merely a label in a dashboard. It changes runtime behavior. A policy update might be allowed in a stable corpus, deferred in an overloaded corpus, blocked in a contaminated corpus, and review-required in a crystallizing corpus. A memory write might be accepted as working context in one phase but quarantined in another. A document claim might be safe to edit in a draft region but unsafe to canonicalize in a fragmented region. An agent action might be normally permitted, but blocked if its action basis depends on a contaminated region. The phase-regime tells the runtime what kind of substrate it is dealing with. --- # **13\. Intervention Operators** A conventional function transforms data. A TraceScript intervention operator transforms the future response of a medium. Intervention operators are governed runtime actions. They may observe, contain, repair, canonicalize, protect, recover, propagate, reverse, reconcile, or mutate substrate. An intervention operator is not merely a service function. It must declare what kind of substrate effect it may produce, what authority and capability it requires, what phases it is admissible in, what receipts it must emit, whether replay is required, and whether residue may remain. This prevents operators from becoming hidden mutation channels. For example: A containment operator may quarantine a trace or freeze canonicalization. An integrity operator may evaluate whether a trace may influence future computation. A repair operator may reconcile contradiction or request evidence. A canonicalization operator may promote a trace only after gates pass. A recovery operator may restore a substrate after contamination or collapse. An action-basis operator may evaluate whether internal state can support a proposed action. An external reconciliation operator may compare expected external state to observed external state. The key principle is: **Functions transform data. Intervention operators transform substrate.** ## **13.1 Why operators must declare effects** In conventional systems, side effects are often hidden in implementation details. In a substrate runtime, hidden effects are dangerous. An operator that appears to “summarize” may actually create memory. An operator that appears to “retrieve” may influence policy interpretation. An operator that appears to “edit” may alter canonical state. An operator that appears to “send” may create legal, financial, customer, or external-world residue. TraceScript requires operators to declare substrate effects so the runtime can govern them. --- # **14\. Runtime Control Plane** The runtime control plane composes lawful operators into verified execution plans. It is the governing layer that decides what may execute. A runtime execution plan binds the signal, target substrate, phase, candidate configuration, selected operators, policies, capabilities, effect class, trust gate, action-basis requirements, simulation requirements, receipt requirements, replay requirements, residue requirements, review route, workers, and execution envelope. TraceScript does not execute isolated operators. It executes verified plans containing operators. The control plane asks: Which operators may run? Which operators are forbidden? Which policies apply? Which capabilities are required? Which effects are declared? Is the action basis valid? Is simulation required? Which receipts must be emitted? Which replay artifacts must be retained? Is residue measurement required? Is human review required? Which failure or repair path applies? This creates a unified execution law across product surfaces, agents, documents, code, workflows, memory, and external tools. The control plane is what prevents TraceScript from becoming a collection of loosely connected guards. It turns substrate governance into runtime execution semantics. ## **14.1 Plans before mutation** The runtime execution plan is the unit of governed action. Without a plan, an operator should not perform durable mutation. Without a receipt plan, trusted mutation should not complete. Without replay classification, durable proof should not be claimed. Without action-basis integrity, consequential agent action should not proceed. This is the difference between a TraceScript runtime and a conventional middleware stack. --- # **15\. Action Basis: The State Behind the Action** TraceScript distinguishes action permission from action-basis integrity. Many agent systems ask whether an agent is allowed to call a tool. That question is necessary, but incomplete. A tool call may be permitted in the abstract while still being unsafe because the internal state supporting the action is corrupted, stale, unsupported, cross-scoped, noncanonical, or unreplayable. TraceScript therefore asks a deeper question: **Is the agent’s reason for acting trustworthy?** An **action basis** is the structured set of internal substrate objects that justify, enable, or contextualize a proposed action. It may include memories, retrieved sources, policies, workflow facts, evidence records, authority records, user instructions, canonical objects, generated summaries, agent inferences, and receipts. The action basis is broader than retrieval. An agent may act based on what it remembered, what it retrieved, what it inferred, what policy says, what workflow state indicates, what prior approval appears to permit, what a summary claims, what canonical organizational truth records, or what receipts prove. This matters because an action can be unsafe even when the tool call is allowed. For example, an agent may be permitted to issue refunds. But if the agent believes, based on poisoned memory, that manager approval is no longer required, the refund action may pass a tool-permission check while failing action-basis integrity. TraceScript therefore separates: Action permission: Is this type of action allowed? Action-basis integrity: Is the internal state supporting this action trustworthy enough for this action class? A proposed action can fail because the memory basis is contaminated, the retrieval basis is stale, the policy basis is noncanonical, the workflow basis is generated but unverified, the source basis is low-authority, the scope basis crosses tenant or customer boundaries, the evidence basis is missing, the canonical basis has been superseded, the generated reasoning basis depends on an excluded object, or the receipt chain is invalid. The operational rule is: **No consequential agent action may execute unless its supporting memory, retrieval, policy, workflow state, evidence, authority, canonical state, generated reasoning, and receipts satisfy the integrity requirements of the action class.** This turns TraceScript from a tool-permission system into a runtime for governing the state behind the action. TraceScript secures not only what agents do, but why they believe they are allowed to do it. ## **15.1 Action basis as substrate object** An action basis is itself a substrate object. It can be stored, inspected, replayed, validated, repaired, invalidated, or used to explain future agent behavior. An action basis may be transient, working, trusted, quarantined, invalidated, or canonical depending on the action class and proof requirements. This matters because action basis can become future substrate. A completed high-value action may later be audited. A blocked action may later be repaired. A prior action may later be invalidated because one of its supporting objects was discovered to be stale, contaminated, revoked, or superseded. TraceScript therefore treats action basis as a first-class runtime object, not merely an explanation string. ## **15.2 Action basis closes the loop** Substrate Integrity protects what the system remembers, retrieves, trusts, and canonicalizes. External action governance protects what the system does. Action Basis connects the two. It closes the loop between: AI systems mutate belief, memory, policy, code, workflow, and action basis and AI systems act externally from that basis. Without action-basis integrity, systems may block some dangerous tool calls but still allow permitted tool calls based on corrupted internal state. With action-basis integrity, TraceScript governs the causal bridge from internal substrate to external consequence. --- # **16\. Receipts, Replay, and Proof-Carrying Mutation** The runtime control plane decides what may execute. The receipt ledger proves what executed, why it executed, what changed, and whether the decision can be replayed. TraceScript receipts are not ordinary logs. A log records activity. A receipt is substrate evidence. A receipt may bind the signal, configuration, policy, authority, capability, evidence, operator, phase, action basis, prior state, resulting state, decision, reason codes, replay class, timestamp, and receipt hash. Receipts allow future reviewers, systems, auditors, or recovery processes to ask: What happened? Why was it allowed? What evidence supported it? What policy applied? Who or what had authority? What substrate was used as action basis? What changed? What remained unresolved? Can the decision be replayed? Was the proof chain intact? Replay is the process of verifying or reconstructing a decision or execution from retained evidence. Not every operation requires the same replay burden. A low-risk observation may require only state-hash verification. A canonicalization, protected external action, policy mutation, deployment, or high-impact decision may require full artifact retention. The doctrine is: **No receipt, no trusted mutation. No replay, no durable proof.** ## **16.1 Receipts are part of execution** In TraceScript, receipts are not an afterthought. A receipt is not merely emitted after the runtime acts. Receipt requirements are part of the execution plan. If the system cannot produce the required proof, the mutation may be blocked, downgraded, reviewed, or treated as noncanonical. The proof obligation exists before the action. ## **16.2 Replay is accountability for future computation** Replay is not only forensic review. Replay determines whether a past decision can continue supporting future trusted state. If a canonical decision cannot be replayed, its ability to support future computation may need to be limited, reviewed, superseded, or revoked. If an action-basis decision cannot be replayed, the completed action may need review, warning, repair, invalidation, or downstream risk marking. This makes replay part of substrate maintenance. --- # **17\. External Action and Reconciliation** TraceScript distinguishes internal substrate mutation from protected external action. External actions include tool calls, SaaS writes, database writes, deployments, emails, messages, workflow approvals, financial actions, legal actions, permission changes, and customer-visible operations. An external action is not complete because an API call succeeded. It is complete only when the action is authorized, supported by a trustworthy action basis, executed through a governed path, observed, reconciled, receipted, and, where necessary, residue-measured. TraceScript introduces the concept of an action release path. Before protected execution, the runtime may require: candidate action configuration authority verification capability verification effect classification action-basis integrity trust gate simulation release artifact gateway execution external observation reconciliation receipt replay A release artifact is an action-bound certificate. It binds what action is allowed, by whom, against what target, under what policy, for what period, through what adapter, with what proof requirements. External systems may drift. An adapter may report success while the observed state differs from expected state. TraceScript treats external reconciliation as part of execution, not as an afterthought. The principle is: **External action is not complete until action basis, execution, and reconciliation are proven.** ## **17.1 Action permission is not action basis** TraceScript distinguishes: action permission and action basis. An agent may be allowed to call a tool. But the state supporting the action may be untrusted. For protected actions, the runtime must evaluate not only whether the actor can act, but whether the substrate from which the action is derived is trusted enough to support the action. This is central to AI systems that remember, decide, and act. --- # **18\. Residue and Reversal** Traditional systems often treat rollback as restoration. TraceScript does not. A rollback may restore visible state while leaving other effects intact. Examples include: A message was already read. A customer already changed expectations. A policy interpretation already influenced a meeting. A memory already shaped later outputs. A workflow already triggered downstream planning. An external system already recorded a transaction. A code deployment already affected users. An action basis already influenced a high-value decision. In these cases, visible reversal does not erase substrate consequences. TraceScript calls these remaining effects residue. Residue may include trust residue, attention residue, authority residue, commitment residue, policy residue, retrieval residue, workflow residue, external residue, belief residue, and audit residue. TraceScript’s rule is: **Rollback is not restoration.** Where residue matters, it must be measured, recorded, repaired, or explicitly accepted. --- # **19\. Security Implications** TraceScript shifts security from output filtering and tool permission toward substrate lifecycle security. The protected surface is not only APIs, files, accounts, or tools. It includes memory, retrieval context, policy interpretations, canonical documents, agent beliefs, workflow state, code topology, review state, action basis, and execution basis. The attack surface changes accordingly. An attacker may not need to compromise a tool directly. It may be enough to inject a trace that later becomes trusted memory, policy authority, workflow basis, code context, or action justification. TraceScript protects transitions such as: untrusted signal → trace trace → working context working context → accepted state accepted state → canonical memory canonical memory → action basis action basis → external action external action → reconciled substrate Each transition can require phase checks, evidence, authority, policy, capability, action-basis integrity, receipts, replay, review, and residue handling. This creates a security model for AI systems that remember, decide, and act. ## **19.1 Memory poisoning as substrate corruption** Memory poisoning is not simply the storage of bad information. It is the corruption of future response. If poisoned memory remains inert, the risk is limited. If it becomes trusted influence or action basis, the substrate is compromised. TraceScript focuses on the transition from stored trace to trusted influence and from trusted influence to action basis. ## **19.2 Policy poisoning as authority corruption** Policy poisoning occurs when unsupported or adversarial claims enter a policy corpus and later affect permission, interpretation, or action. This is more subtle than ordinary data poisoning because the corrupted object may look like organizational knowledge. TraceScript addresses this by requiring authority, evidence, receipt, and replay before policy influence can become trusted. ## **19.3 Tool misuse as action-basis failure** A tool call may be technically permitted but semantically unsafe if the action basis is untrusted. TraceScript therefore governs the substrate behind the action, not only the tool call. ## **19.4 Source laundering as substrate risk** AI systems often transform sources into summaries, plans, explanations, and intermediate reasoning. During transformation, low-authority content can appear more authoritative than it is. This is source laundering. TraceScript treats generated summaries and agent inferences as substrate objects whose authority depends on preserved lineage, evidence, and receipts. A generated summary cannot become action basis merely because it is fluent. --- # **20\. Governance Implications** TraceScript treats governance as execution semantics, not middleware. Policies are not merely documents. Reviews are not merely comments. Approvals are not merely checkboxes. Receipts are not merely logs. Action bases are not merely explanations. Governance determines whether substrate mutation is permitted and whether internal state may justify consequential action. This has implications for enterprise AI governance, regulated workflows, collaborative documents, software deployment, organizational memory, and autonomous agents. A review is a substrate event. A policy update is a substrate mutation. A memory promotion is a governance transition. An action basis is a governed justification object. A code deployment is a state-bearing external action. A rollback may leave residue. A receipt becomes part of the proof surface of the organization. TraceScript therefore makes governance operational. It gives governance a runtime form. ## **20.1 Governance impedance** Governance is not free. Too little governance allows unsafe mutation. Too much governance creates bottlenecks, rubber-stamping, and shadow workflows. TraceScript creates a language for runtime-governed impedance: tightening, relaxing, routing, deferring, simulating, reviewing, repairing, or blocking depending on substrate condition and action-basis requirements. This matters because AI systems increase the volume and speed of state-changing events. Governance must become adaptive without becoming arbitrary. --- # **21\. Reference Instantiations** TraceScript is the language/runtime. Several product or system instantiations can be built from it. These are examples, not the trunk. ## **21.1 Substrate Integrity** Substrate Integrity protects what the system may treat as trusted state. It governs memory, retrieval, policy corpora, knowledge bases, document locks, workflow states, and trusted summaries. Its core rule is: **No untrusted signal may directly become canonical substrate.** ## **21.2 Action Firewall** An Action Firewall protects what the system may do externally. It governs action basis, release artifacts, gateway execution, reconciliation, receipt emission, and replay for protected actions. Substrate Integrity protects what the system believes. Action Firewall protects what the system does. Action Basis connects the two. ## **21.3 Code Medium** Code Medium applies substrate-oriented programming to software systems. It treats codebases as state-bearing media whose components, schemas, routes, deployments, policies, packages, and external write paths must be governed as substrate. A code change may be syntactically valid but topologically unsafe. A deployment may be technically possible but unsupported by valid action basis. ## **21.4 Constitutional Agents** Constitutional Agents apply TraceScript to long-lived agents. They govern jurisdiction, observation rights, inference rights, memory rights, disclosure rights, action rights, commitments, capability locks, and audit lineage. The governing principle is: **Who decides comes before what is the answer.** These instantiations show the breadth of TraceScript. They should not be mistaken for the trunk. The trunk is governed signal-to-substrate mutation. --- # **22\. Reference Kernel: Policy Corpus Integrity** TraceScript should first be implemented through a narrow reference kernel. The kernel should prove one sentence: **TraceScript becomes real when it can prevent an untrusted signal from becoming trusted substrate, explain why, propose repair, emit a receipt, and replay the decision.** The first reference wedge is Policy Corpus Integrity. ## **22.1 Scenario** A retrieved document, user input, or model output claims: “Security review is optional for low-risk AI changes.” The claim is relevant. But it is not authoritative. A conventional retrieval system might include it in context. A conventional agent might summarize it. A conventional memory system might store it. TraceScript treats it as a signal attempting to become policy substrate. ## **22.2 Runtime behavior** The runtime normalizes the signal. It creates a trace. It resolves the policy corpus medium. It assesses substrate phase. It constructs a candidate configuration. It detects that the requested influence is policy authority. It evaluates source authority. It evaluates evidence support. It evaluates poisoning risk. It runs the canonicalization gate. It detects obstruction. It quarantines or demotes the trace. It generates repair suggestions. It emits receipts. It assigns replay class. It verifies replay. ## **22.3 Output** The output is not merely “blocked.” It is a structured substrate decision. The trace may be stored for audit. It may be prevented from trusted influence. Canonicalization is blocked. Repair suggestions may include official policy evidence, approval by the security policy owner, or review routing. Receipts prove what happened. Replay verifies why. ## **22.4 Why this is the right first kernel** This example is concrete, security-relevant, and general. It is not limited to one product. It shows the core primitive: **governed signal-to-substrate mutation.** It also demonstrates why TraceScript is not merely prompt filtering, logging, retrieval hygiene, or tool permission. The input may be useful. It may be relevant. It may not even be malicious. The problem is that it is attempting to become trusted substrate without sufficient authority. TraceScript governs that transition. ## **22.5 Extension to action basis** The same kernel naturally extends to action-basis integrity. Suppose an agent later attempts to approve a deployment, send a compliance response, or execute a workflow action based on the untrusted policy claim. TraceScript should not only ask whether the agent has permission to perform the action. It should ask whether the policy claim supporting the action is trusted, canonical, current, scoped, receipted, and replayable. If the claim was quarantined, stale, unsupported, or noncanonical, the action basis fails. The action may be blocked, routed to authority, reviewed, or repaired. This closes the loop from substrate integrity to external action. --- # **23\. Conformance and Golden Fixtures** A TraceScript implementation is not conforming because it uses TraceScript terminology. It is conforming only if it demonstrates the required runtime behavior. The architecture defines the runtime. Golden fixtures prove the runtime. A golden fixture is a canonical scenario with deterministic input, expected runtime path, expected decision, required receipts, replay expectations, state assertions, and failure assertions. A runtime should prove that it can: ingest signals create traces assemble candidate configurations assess phase select admissible operators verify policy and capability evaluate trust evaluate action basis emit receipts assign replay class verify replay block forbidden mutation route repair detect tamper export audit proof Importantly, blocking can be success. A correct runtime may quarantine, defer, review, repair, or deny. The question is not whether the system always permits action. The question is whether the system produces the lawful substrate outcome and proves it. The conformance doctrine is: **No fixture pass without proof. No conformance without replay. No certification without receipts.** --- # **24\. Research Implications** TraceScript opens a research direction around state-bearing computational substrates. The central research question is: How should computational systems govern the transition from signal to trusted substrate? This produces further questions: How should substrate phase be measured? How should trace influence be modeled? How should canonicalization be calibrated? How should action-basis integrity be measured? How should replay burden vary by risk? How should systems measure residue? How should agents govern belief, memory, disclosure, and action? How should code topology be represented as substrate? How should governance impedance be optimized? How should conformance fixtures define runtime categories? TraceScript is not only a runtime proposal. It is a way to name and study a shift already occurring across AI systems, software platforms, and organizational computation. Computation is moving from stateless function execution toward adaptive substrate evolution. TraceScript provides a language for that transition. --- # **25\. Design Principles** TraceScript is governed by the following design principles. ## **Principle 1 — State is active** State affects future computation. Treat it as substrate. ## **Principle 2 — Signals do not execute directly** Signals propose substrate changes. The runtime evaluates the configuration. ## **Principle 3 — Storage is not influence** A trace can be stored without being trusted. ## **Principle 4 — Relevance is not authority** Retrieved context must not automatically become trusted state. ## **Principle 5 — Canonicalization is a gate** Durable trusted substrate requires governance. ## **Principle 6 — Phase matters** A substrate’s condition determines admissible mutation. ## **Principle 7 — Operators are interventions** Runtime functions must declare substrate effects. ## **Principle 8 — Plans govern execution** Operators execute through verified runtime execution plans. ## **Principle 9 — Action basis must be trusted** A consequential action requires a trustworthy internal state basis, not merely tool permission. ## **Principle 10 — Receipts prove mutation** Logs are insufficient. Receipts bind evidence. ## **Principle 11 — Replay proves durability** A trusted mutation must be replayable at the appropriate evidence level. ## **Principle 12 — Rollback is not restoration** Residue must be measured where action cannot be perfectly undone. ## **Principle 13 — External action requires reconciliation** External systems must reconcile back to substrate truth. --- # **26\. Limitations and Open Questions** TraceScript v1.0 is a public architecture and reference runtime model, not a complete implementation. Several open questions remain. ## **26.1 Calibration** Phase-regime thresholds, trust scores, poisoning scores, coherence metrics, action-basis integrity thresholds, crystallization pressure, and residue measurements require implementation-specific calibration. ## **26.2 Performance** Receipts, replay, artifact retention, phase assessment, action-basis evaluation, and trust evaluation introduce overhead. Implementations must balance proof strength with latency and cost. ## **26.3 Developer experience** TraceScript may eventually expose a concise source syntax, builder API, or declarative runtime form. The first reference kernel may be implemented through ordinary programming-language objects and runtime APIs before standalone syntax stabilizes. ## **26.4 Human governance** Human review must be operational without becoming bottleneck or theater. TraceScript can route review and bind authority, but organizations must define responsibility. ## **26.5 Interoperability** TraceScript must interoperate with existing identity systems, policy engines, vector stores, workflow tools, code repositories, model providers, databases, and SaaS systems. ## **26.6 Adoption** TraceScript introduces a new mental model. Adoption depends on clear examples, useful tooling, reference fixtures, and concrete security wins. ## **26.7 Formalization** TraceScript’s public model can be formalized more deeply. Future work may define formal semantics for substrate phase, candidate configuration viability, influence propagation, action-basis integrity, receipt sufficiency, replay burden, and residue. --- # **27\. Conclusion** Software state is becoming substrate. AI systems increasingly write memory, retrieve context, shape belief, update workflows, modify code, interpret policy, and take external actions. These systems require more than output filters, access control, logging, and workflow approval. They require a runtime model for governing how signals become trusted state and action basis. TraceScript introduces that model. Its central contribution is substrate-oriented programming: a way to program not merely over data, but over state-bearing media whose accumulated traces shape future computation. Its execution model is governed configuration assembly: signals do not execute directly; they are assembled into candidate configurations and evaluated against phase, policy, authority, capability, evidence, trust, action-basis integrity, receipt, replay, and residue conditions before durable mutation or consequential action is allowed. TraceScript separates storage from influence, relevance from authority, policy admissibility from trust readiness, action permission from action-basis integrity, execution from proof, and rollback from restoration. The result is a runtime architecture for the substrate era of computation. TraceScript can be instantiated as memory protection, policy corpus integrity, action firewalls, code-medium governance, constitutional agent governance, document review, workflow integrity, and other systems. But these are applications of the same deeper primitive: **governed signal-to-substrate mutation.** TraceScript governs not only whether an action may occur, but whether the substrate basis supporting that action is trusted enough to justify it. TraceScript is a substrate-oriented programming language and runtime for governing how signals become trusted state, action basis, and future computation in state-bearing computational systems. --- # **Appendix A — Minimal Vocabulary** ## **TraceScript** A substrate-oriented programming language and runtime for governing how signals become trusted state, action basis, and future computation in state-bearing computational systems. ## **State-Bearing Computational Substrate** A computational environment whose accumulated state affects future computation. ## **Medium** A state-bearing computational environment or region through which signals propagate and traces accumulate. ## **Field** The response surface of a medium, describing how it responds to signals. ## **Signal** Any input, event, message, output, retrieval result, tool result, code change, approval, or observation that may affect substrate state. ## **Trace** A substrate mark left by a signal, decision, operator, mutation, observation, review, action, or receipt. ## **Influence** The degree to which a trace may affect future computation. ## **Candidate Configuration** The proposed whole assembled from signal, actor, target medium, trace, operator, policy, authority, capability, evidence, boundary, effect class, receipt path, replay class, substrate phase, and action-basis consequences. ## **Obstruction** A structured reason why a candidate configuration cannot safely execute, mutate substrate, acquire influence, form action basis, or support consequential action. ## **Repair** A governed transformation that reduces an obstruction. ## **Phase-Regime** The operational condition of a substrate region. ## **Intervention Operator** A phase-aware governed operator that observes, contains, repairs, canonicalizes, protects, recovers, propagates, reverses, reconciles, evaluates action basis, or mutates a substrate. ## **Runtime Execution Plan** The verified plan that binds signal, substrate, phase, configuration, operators, policies, capabilities, effects, trust gates, action-basis requirements, simulations, receipts, replay, residue, review, workers, and execution envelope. ## **Action Basis** The structured set of internal substrate objects that justify, enable, or contextualize a proposed action, including memory, retrieval, policy, workflow state, evidence, authority, canonical state, generated reasoning, user instructions, and receipts. ## **Receipt** A replay-bound evidence object proving a decision, mutation, operator execution, phase transition, action-basis evaluation, external action, recovery, reversal, governance update, certification, or audit export. ## **Replay** Verification or reconstruction of a decision or execution using retained evidence, receipts, policies, state hashes, operator versions, artifacts, action-basis references, and recorded runtime context. ## **Canonicalization** Governed promotion of a trace into durable trusted substrate. ## **Residue** Non-perfectly-reversible effects remaining after action, rollback, reversal, mutation, disclosure, external execution, or governance change. --- # **Appendix B — TraceScript in One Page** Software state is becoming active. AI systems increasingly write memory, update workflows, modify code, retrieve context, interpret policy, and take external actions. These systems require a runtime for governing how signals become trusted substrate. TraceScript provides that runtime. A signal entering TraceScript is not executed directly. It is resolved against a medium, converted into traces, evaluated as a candidate configuration, checked against substrate phase, policy, authority, capability, evidence, effect class, trust, action-basis integrity, receipt, replay, and residue requirements. Only then may the runtime permit, constrain, quarantine, repair, canonicalize, simulate, or execute the mutation. The core path is: signal → trace → candidate configuration → phase assessment → operator resolution → runtime execution plan → receipt → replay → substrate update For consequential action, the path also includes: trusted substrate → action basis → action-basis integrity → protected execution → external reconciliation → residue-aware update TraceScript separates: storage from influence relevance from authority policy admissibility from trust readiness action permission from action-basis integrity execution from proof rollback from restoration The first reference kernel is Policy Corpus Integrity: prevent an untrusted policy claim from becoming trusted substrate, explain why, propose repair, emit a receipt, and replay the decision. The natural extension is Action-Basis Integrity: prevent an agent from taking consequential action when its supporting memory, retrieval, policy, workflow state, evidence, authority, canonical state, generated reasoning, or receipts are untrusted, stale, cross-scoped, noncanonical, or unreplayable. TraceScript is the trust runtime for AI systems that remember, decide, and act. --- # **Appendix C — The Core Argument in Twelve Claims** 1. Software state is becoming active. 2. Active state conditions future computation. 3. State that conditions future computation is substrate. 4. AI systems accelerate substrate formation by writing memory, policy, workflow, code, and action basis. 5. Existing software models govern access, events, logs, workflows, retrieval, and tools, but not the full lifecycle by which signals become trusted substrate. 6. TraceScript introduces substrate-oriented programming for state-bearing computational systems. 7. TraceScript execution is governed configuration assembly. 8. A signal must be evaluated as a proposed substrate change before it may mutate durable state. 9. Trace existence is not trace authority; storage is not influence. 10. Trusted-state formation requires canonicalization, receipts, replay, and phase-aware governance. 11. Consequential action requires action-basis integrity, not merely tool permission. 12. TraceScript is the runtime model for governing how signals become trusted state, action basis, and future computation. --- # **End of Canonical Public White Paper v1.0**