Built-in and Attached: Designing a Decision Trace Fabric That Connects Enterprise Decisions

🎥 The YouTube version is also available:

Decision Trace Fabric: Connecting Enterprise Decisions Across AI, People, and Systems

Books: Decision Trace Fabric on AWS: Built-in and Attached – Connecting Enterprise Decisions

When introducing AI into an enterprise, initiatives often begin with individual business challenges.

In manufacturing: detecting equipment anomalies, analyzing quality issues, and identifying affected lots.
In retail: making pricing decisions based on inventory, demand, gross margin, and competitive conditions.
In procurement: selecting suppliers by considering quotation comparisons, delivery dates, quality, and past performance.
In review and finance: conducting additional checks on exceptional cases, changing conditions, and making approval decisions.
In sales and customer operations: handling inquiries, making proposals, escalating issues, and setting priorities.

These individual solutions can embed AI and support decisions in the field.

However, as the number of individual solutions increases, a new challenge emerges.

Does each system record its decisions?
Can the organization trace what evidence a decision relied on, who approved it, what was executed, and what outcome followed?
And can the decisions and lessons gained in one business area be reused in another?

This is where the Decision Trace becomes necessary.

A Decision Trace is neither a history of AI responses nor a simple audit log. It is a mechanism that connects changes in reality, evidence, decisions, actions, outcomes, and learning—and turns enterprise decision-making into a reusable asset.

To extend this mechanism across an enterprise, two approaches are required.

The first is Built-in Trace, in which Decision Trace is embedded from the outset in newly created solutions.
The second is Attached Trace, in which Decision Trace is added externally to existing ERP, MES, CRM, workflow, quality-management, and other systems.

The important point is not to make these two separate mechanisms.

The foundation that connects them through a shared specification is called the Decision Trace Fabric in this article.

Why Two Adoption Approaches Are Necessary

With a new solution, Decision Trace can be embedded from the stage at which the business flow, AI agents, data model, and approval interface are designed.

Consider a maintenance AI that recommends: “Stop the equipment and isolate the lots processed during the previous 24 hours.”

The rationale for the recommendation, the maintenance standards referenced, the equipment condition, the affected lots, alternative options, approvers, the stop operation actually performed, and the recovery result can all be recorded as a single connected Trace.

This is the environment for which Built-in Trace is well suited.

At the same time, enterprises already have many critical systems: ERP, MES, PLM, CRM, WMS, quality management, maintenance management, document management, and approval workflows.

It is not realistic to fully redesign or replace those existing systems solely for Decision Trace. Some have limited APIs, some cannot change their data models, and many are deeply integrated with years of operational practice.

This is where Attached Trace is needed.

While respecting the source data and business workflows of existing systems, a Trace Adapter is placed outside them. It captures events, state changes, approval records, document references, and execution results, while supplementing decision rationales and exception conditions that the original systems alone do not contain.

With both Built-in and Attached approaches, an enterprise can steadily accumulate decision assets through new AI solutions while also extending the capability incrementally to important existing operations.

What Is a Decision Trace Fabric?

A Decision Trace Fabric is not a massive data lake that gathers all data in one place.

It is a layer that connects decisions spanning multiple business systems, AI solutions, field devices, people, and agents through shared meaning and conditions of trust.

flowchart TB
  subgraph New["New solutions"]
    A["Business applications / AI agents"] --> B["Decision Trace SDK"]
  end

  subgraph Legacy["Existing systems"]
    C["ERP / MES / CRM / Workflow"] --> D["Trace Adapter / Gateway"]
  end

  B --> E["Decision Trace Fabric"]
  D --> E

  E --> F["Trace Graph<br/>Decisions, evidence, actions, outcomes"]
  E --> G["Trust Layer<br/>Identity, authority, provenance, integrity"]
  E --> H["Search, analytics, AI agents"]

The Fabric should provide four primary capabilities:

• A Trace Schema that represents decisions, evidence, actions, and outcomes in a common format
• A Trace Graph that retains relationships among Traces and business objects
• A Trust Layer that handles identity, authority, provenance, integrity, and time
• A Workspace in which people and AI can review, compare, and learn from decision history

With this foundation, manufacturing AI, quotation-evaluation AI, pricing AI, review AI, and customer-service AI can function independently while forming a network that accumulates enterprise-wide decision capability.

The Minimum Elements That Must Be Standardized

Whether a solution is new or Decision Trace is added externally to an existing system, the fundamental structure of the Trace must be shared.

At a minimum, it should contain the following elements.

Field	Meaning
Decision ID	A unique identifier for the decision
Decision Question	What needed to be decided
Scope	The relevant equipment, lots, products, customers, contracts, sites, and other targets
Actor	The decision-making entity: person, AI agent, system, device, and so on
Authority	Authority, delegation, and policies required to make or approve the decision
Context	The real-world state, constraints, and related events at the time of decision
Evidence	Documents, data, past cases, inspection results, and external information
Alternatives	Options considered and reasons they were not selected
Decision	The selected option, rationale, confidence, and conditions
Action	The action taken, owner, deadline, and execution result
Outcome	Quality, financial, customer, and safety outcomes resulting from the decision
Review	Post-decision evaluation, learning, and revisions to rules or procedures
Integrity	Timestamps, provenance, signatures, hashes, correction history, and version information

However, people do not need to enter every one of these fields every time.

For low-risk automated decisions, such as an equipment alert, the input event, applicable rule, and execution result may be sufficient.

For decisions such as shipment stoppages, credit exceptions, pricing exceptions, safety responses, or regulated decisions, the Trace may also need to include alternatives, approvals, reconsideration conditions, versions of evidence, and correction history.

The key is to design the system so that the density of the Trace can vary according to the importance and risk of the decision.

Built-in Trace: Embedding the Structure of Decision-Making in New Solutions

In newly created AI solutions, Decision Trace should not be treated as a logging feature added later.

AI makes a proposal. A person reviews it. A decision is approved. An action is executed. The outcome is evaluated.

Trace should be embedded into this business flow itself.

Four core components are required.

Decision Trace SDK

This is an SDK for emitting Traces in a common format from applications, AI agents, and rule engines.

For example, an application could record a Trace through the following sequence.

trace.open(question, scope, context)
trace.addEvidence(evidenceRef)
trace.propose(option, rationale, confidence)
trace.requestApproval(policy)
trace.recordDecision(selectedOption, actor)
trace.recordAction(actionResult)
trace.recordOutcome(metrics)
trace.review(learning, ruleChange)

This does not require developers to “record every internal process.”

It establishes a consistent minimum flow for every solution:

What needed to be decided?
What evidence supported the proposal?
Who ultimately selected what?
What was executed, and what result followed?

Decision Workspace

Trace should not be a back-end log visible only to developers and auditors.

A workspace is needed in which field personnel, managers, and approvers can review the evidence, alternatives, uncertainties, and reconsideration conditions behind a decision.

In particular, it is insufficient for a person simply to press “approve” or “reject” in response to an AI recommendation.

Which part did the person modify?
Which evidence did they consider most important?
What field condition did the AI overlook?
Why was this case treated as an exception?

These differences become Learning Traces for the next round of improvement.

Trace Store and Trace Graph

Storing individual Traces only as a time series is insufficient for enterprise-wide learning.

A single decision is connected to equipment, lots, products, customers, policies, documents, personnel, other decisions, and outcomes.

For example, a decision made in response to an equipment anomaly may have relationships such as:

• It relies on a specific equipment state as evidence
• It affects a specific lot
• It references a particular maintenance procedure
• It receives approval from a quality manager
• It triggers a shipment-hold action
• It creates a delivery impact for a customer
• It leads to a later revision of a procedure

A Trace Graph is the structure used to handle these relationships.

It makes it possible to answer questions such as: “What decisions were made previously under similar equipment conditions?” “Which departments frequently invoke exceptions to this policy?” and “Under what conditions do people modify AI recommendations?”

Review and Learning Loop

The value of a Decision Trace does not end when the decision is made.

The outcome after execution must be tracked, the appropriateness of the decision must be evaluated, and the result must feed back into policies, thresholds, prompts, agents, and business procedures.

This is the Learning Trace.

Even after AI is introduced, an organization will repeat the same exceptions, rework, and person-dependent decisions if it does not learn the relationship between decisions and outcomes.

Decision Trace becomes the foundation for moving AI from “a mechanism that provides answers” to “a mechanism that improves enterprise decision capability.”

Attached Trace: Adding Decision Context to Existing Systems

Existing systems already contain valuable data and operational history.

ERP holds facts about purchase orders, inventory, procurement, and accounting.
MES holds equipment, process, production order, and work-performance data.
CRM holds customer interactions, opportunities, proposals, and order history.
Workflow systems hold histories of requests, approvals, returns, and exception processing.

However, existing systems alone often cannot adequately answer the following questions.

Why was this decision selected at that point in time?
What alternatives existed, and why were they not selected?
Which policies and evidence supported the decision?
Under what conditions should the decision have been reconsidered?

Attached Trace does not replace existing systems. Instead, it extends their events and records into decision-ready context.

Trace Adapter and Trace Gateway

A Trace Adapter or Trace Gateway is placed outside an existing system.

The connection method is selected according to the system’s characteristics.

Connection method	What can be collected	Suitable targets
API / Webhook	Updates, approvals, state changes, execution events	SaaS and cloud business systems
Change Data Capture	Record additions, updates, and state transitions	Existing databases such as ERP and MES
Event / Message Integration	Equipment, IoT, and business events	MQTT, Kafka, and log platforms
Supplemental Ingestion of Documents and Conversations	Candidates for decision rationales, issues, and background	Email, meeting minutes, tickets, and reports

For example, an existing MES may provide information such as equipment alerts, production orders, lots, quality-hold flags, responsible personnel, and approval timestamps.

These can be mapped to a common Decision Trace.

Existing MES information	Meaning in the Decision Trace
equipment_alarm	Reality Trace
work_order_id	Scope
operator_id	Actor
quality_hold_flag	Decision or Action
approval_user_id	Authority / Accountability
change_timestamp	Time / Integrity
inspection_record_id	Evidence
disposition_code	Candidate Outcome

In this way, events within an existing system can be treated not as mere record changes, but as events that form part of a chain of decisions.

Information That Should Be Supplemented Externally

There is no need to force existing systems to hold information that they do not contain through extensive modification.

Only when needed, the following can be supplemented through a Trace Workspace, an approval interface, or AI-assisted drafting:

• Decision rationale
• Applicable policies and exception conditions
• Alternatives considered
• Unresolved matters
• Conditions for reconsideration
• Metrics for evaluating outcomes

For example, AI can create a candidate isolation decision and candidate evidence from meeting minutes, tickets, and quality records. A responsible person reviews it and, if necessary, corrects it before making it an official Trace.

AI is not the official author of the decision. It functions as an editorial assistant that structures distributed decision context.

Five Specifications Needed to Truly Connect the Two Approaches

Collecting events alone is not enough to connect Built-in Trace and Attached Trace.

At least the following five elements must be defined as shared specifications.

1. Identity

People, organizations, AI agents, devices, lots, documents, customers, contracts, and business objects need stable identifiers.

Traces cannot be connected across systems if the same equipment, lot, document, or person is treated as a different entity in every system.

2. Semantic Model

A semantic model is required to consistently handle concepts such as equipment, processes, lots, policies, evidence, decisions, approvals, actions, and outcomes across the enterprise.

There is no need to create a massive enterprise-wide ontology from the beginning. Start with the minimum vocabulary needed in one business domain, then extend it to related domains.

3. Evidence Reference

Rather than copying all source materials into the Fabric, retain references to the originals.

References should include document IDs, versions, issuers, acquisition routes, access permissions, hashes, and times of use.

This makes it possible to avoid unlimited replication of confidential information while respecting existing systems as the custodians of original records.

4. Trust Envelope

In addition to the content of a Trace, attach information on who recorded it, when, under what authority, and under which policy.

This is called the Trust Envelope.

{
  "trace_id": "dt_01J...",
  "trust_envelope": {
    "issuer": "maintenance-app",
    "actor_id": "user_123",
    "actor_role": "quality-manager",
    "authority_snapshot": "policy-role-v7",
    "source_refs": [
      "mes:alarm-0081",
      "qms:inspection-882"
    ],
    "source_versions": {
      "maintenance-procedure": "v4.2",
      "ai-model": "model-2026-10"
    },
    "created_at": "2026-10-31T10:02:00Z",
    "content_hash": "sha256:...",
    "previous_trace_hash": "sha256:...",
    "correction_policy": "append-only"
  }
}

The Trust Envelope makes it possible to verify afterward:

• Whether the Trace was created by AI, a person, or a particular system
• Which policies, authorities, and models were applicable at that time
• Where the source data was located and which version was used
• Whether the content has been changed afterward
• If corrected, who made the correction, why, and when

5. Event Contract

The state transitions of a Trace should be standardized.

For example, states such as proposed, approved, executed, reviewed, and superseded can be defined as a common contract.

This allows events from different solutions and existing systems to be handled through a shared lifecycle: whether they are still proposals, already approved, executed, or reviewed after outcomes have been assessed.

Trust Infrastructure Is a Verifiable Envelope for Decisions

Trust Infrastructure is not about introducing blockchain from the beginning.

Its essence is to attach information around a Decision Trace that makes its authenticity verifiable.

Who created it?
Did that person or agent have the necessary authority?
When was it created?
Which original records, versions, models, and policies were used?
Has it been altered afterward?
If an error was discovered, does the system retain the history of correction?

At the initial stage of implementation, append-only history, hash chaining, digital signatures, timestamp evidence, and authority snapshots are sufficient.

When trust across organizations becomes necessary—as in multi-enterprise transactions, supply chains, evidence records, and third-party audits—shared ledgers, third-party attestations, and verifier agents can be added.

Trust does not arise from the absence of mistakes.

It arises from the ability to verify afterward what decision was made under uncertainty, how it was revised as new information became available, and who accepted responsibility.

Recommended Adoption Sequence

Decision Trace Fabric should not be built from the outset as a large enterprise-wide common platform.

Instead, one Built-in Trace and one Attached Trace should be operated in a high-value business domain, while the common specifications are validated and expanded.

Phase 1: Decision Trace Core

• Common Trace Schema v1
• Specifications for Trace ID, Actor ID, and Evidence Reference
• An append-only Trace Store
• SDK integration into one new AI solution
• Trace Adapter connection to one existing system
• A Trace Viewer that displays decisions, evidence, actions, and outcomes over time

Phase 2: Decision Trace Workspace

• AI-generated Trace drafts
• Human review, approval, and correction
• Lightweight forms for exception decisions
• Links between Decisions and Outcomes
• Search and comparison of similar decisions
• Basic provenance, authority, and hash management

Phase 3: Cross-Solution Decision Graph

• Connection with the Semantic Digital Twin
• Visualization of decision relationships across multiple solutions
• Analysis of which groups of decisions are affected by a given change
• AI-agent recommendations informed by past decisions and outcomes
• A mechanism for improving policies, rules, and prompts through Learning Traces

Phase 4: Trust Network

• Signatures and attestations across organizations and enterprises
• Verification of delegation and approval authority
• Evidence packages for audit and regulatory compliance
• Restricted sharing with suppliers, customers, and third-party verifiers
• Externalization of Trust Infrastructure based on Decision Trace

From Individual AI Solutions to a Platform That Accumulates Enterprise Decision Capability

New solutions should include Decision Trace as a standard capability.
Existing systems should be supported through external Trace Adapters.
Both should be connected through a shared semantic model, Evidence References, Trust Envelopes, and a Trace Graph.

When this structure is in place, an enterprise is no longer merely increasing the number of individual AI applications.

Decisions on equipment anomalies.
Decisions on quality issues.
Decisions in procurement, pricing, review, and customer operations.
And the human decisions to adopt, modify, or reject AI recommendations.

These become not disconnected logs, but connected decision assets that accumulate over time.

The Semantic Digital Twin captures the real world as meaningful states.
Knowledge Flow circulates distributed knowledge, policies, experience, and outcomes.
The Decision Trace Model turns decisions, evidence, actions, and outcomes into reusable structures.
Trust Infrastructure makes it possible to verify that they were created, approved, and updated through genuinely trustworthy paths.

What Chinoba should aim to become is neither merely a collection of AI applications nor merely a data-integration platform.

It is a Runtime Platform that connects the real world and organizational knowledge, and accumulates enterprise decisions as a capability that can be explained, verified, learned from, and applied to the next decision.

AI is not prediction. It is decision.

And Decision Trace Fabric is the foundation that transforms those decisions into an enterprise’s enduring intelligence.