Research / Trust Infrastructure

Trust Infrastructure

AI no longer only proposes. It judges, calls tools, coordinates with other AI, and acts on the physical world. Capability alone is not a reason to let it.

Trust is not a reputation, a past success rate, or a fixed score attached to a person or an AI. It is a bounded, revisable expectation — held by a specific evaluator, about a specific subject, for a specific purpose, role, situation, and time horizon — that the subject will produce the expected result. Trust Infrastructure is the foundation that connects people, AI, organizations, knowledge, policy, action, and outcome, so that how far something can be trusted to act is explainable rather than assumed.

Featured Resources

Start Here — the New Practical Guide, Books, Video, and Blog

The practical guide above leads this line of inquiry. Below it are the neighboring Chinoba books, videos, and essays on Decision Trace, Knowledge Flow, Runtime AI Governance, and AI Coordination that this page draws on.

📚 More Books

Neighboring practical guides on the decision, knowledge, governance, and coordination layers that Trust Infrastructure connects.

Japanese Edition
Trust Infrastructure実践ガイド: Decision Trace・Knowledge Flow・Trust EngineによるAI時代の信頼基盤設計 →
English
AI Is Not Prediction. It Is Decision. — A Practical Guide to Designing AI Decision Systems → Knowledge Flow Practical Guide: Transform Enterprise Knowledge into AI-Ready Knowledge Infrastructure → Runtime AI Governance: Practical Guide → AI Coordination Engineering: A Practical Guide →

📺 Watch on YouTube

Visual introductions to trust, decision trace, knowledge flow, and coordination in the age of AI.

English
Trust Infrastructure: Building the Foundation for Human–AI Collaboration → Decision Trace Model Explained | The Missing Layer Between AI and Real-World Decisions → Knowledge Flow: Transforming Enterprise Knowledge into AI-Ready Knowledge Infrastructure → What Is AI Coordination? Coordination Engineering for the Multi-Agent Era →
Japanese
AI社会を支えるTrust Infrastructureとは？｜人・AI・組織が安心して協調するための新しい基盤 → Trust Infrastructure — AI時代の信用基盤 →

📰 From the Blog

Long-form essays behind this page's argument, on trust, evaluation, and trustworthy runtime for AI-era coordination.

English
Trust Infrastructure → Trust Evaluation in the Age of AI → What Is Immutable Linux? — Why "Trustworthy Runtime" Matters in the Age of AI →
Japanese
Trust Infrastructure →
01 / Why Conventional Trust Evaluation Is Not Enough

Why Conventional Trust Evaluation Is Not Enough

A reputation score, a past success rate, and a single trust number are useful for ranking and anomaly detection. They are not sufficient grounds for delegating a business role to an AI Agent and being accountable for the result, because aggregating the past into one value discards exactly the conditions needed to judge the present.

What Gets Lost in a Single Score

A quality-inspection Agent that judged 95 of the last 100 cases correctly has a 95% success rate. That number alone cannot say:

  • which products, lines, or equipment the 95 cases involved
  • whether the same sensors and quality policy are still in effect
  • whether the 5 misses were minor or safety-related
  • whether the model or prompt changed during that period

The same gap separates creditworthiness, reputation, and reliability from trust itself: each compresses past information into a signal, but only trust asks whether expected behavior will hold in this context, for this goal, right now.

Evidence, Risk, Confidence, and Trust Are Not the Same

A track record, a benchmark, or a certification is Evidence offered in support of trust — it is not trust itself, and it does not update automatically as context changes. Risk describes what is at stake if expectation fails; Confidence describes how certain an estimate is; Trust is the bounded expectation that combines them for a specific role and moment.

Collapsing factors of a different nature into one averaged value is the most dangerous mistake in trust design:

Capability 0.95, Reputation 0.92, Safety 0.20 Average = 0.69 — above a 0.65 threshold. A hazardous task cannot be justified this way.
Diagram titled 'Trust is not born naturally,' showing trust uncertainty compounding from Level 1 (a single person) through Level 2 (human plus AI), Level 3 (adding an organization), and Level 4 (adding society), concluding that trust cannot be sustained by human intuition alone.
As more roles, actors, and contexts enter a relationship, the number of distinct trust judgments multiplies — intuition and a single score stop scaling long before the organization does.

Trust Does Not Substitute for Permission

High trust, however earned, does not replace Permission, and it does not authorize crossing a Boundary. Trust can widen what is offered for approval; it cannot dissolve the approval step or a limit that exists for other reasons.

Trust Is Relational, Not a Property of a Subject

"Agent A is trustworthy" omits the evaluator, the role, the goal, the context, and the time horizon — without them, nothing about what can actually be delegated can be determined. Trust exists in the combination:

Trust Context = Evaluator × Target × Role × Goal × Situation × Policy Set × Constraint Set × Time Horizon
02 / Decision Trace: Recording Decisions, Not Just Results

Decision Trace: Recording Decisions, Not Just Results

A decision cannot be understood from its result alone. A good outcome can be a lucky success; a bad outcome can follow a well-reasoned decision, correctly executed. Decision Trace is the starting point of Trust Infrastructure because it is the structured record that lets the two be told apart.

What a Trace Connects

A Decision Trace binds together, in sequence:

  • Observation and Context
  • Knowledge and Provenance
  • Alternatives considered
  • applied Policy and Constraint
  • the Decision itself
  • the Action taken
  • the Result
  • Feedback into knowledge, policy, and trust

It does not preserve a model's raw internal reasoning. It is a structured, reviewable record built for verification, explanation, and improvement after the fact — not a replay of what happened inside the model.

Do Not Conflate the Roles

An AI's proposal, a human's approval, modification, or rejection, the party who executes an action, and the party who bears final responsibility for it are distinct roles. Collapsing them into "the AI decided" or "the human is responsible" erases the exact information a trace exists to preserve.

A good result does not prove a good decision. A bad result does not prove a bad one. Without a trace, a lucky success and a principled, correctly executed failure stay indistinguishable.
Diagram titled 'What is Decision Trace (DTM)?' showing five sequential steps — understand the situation, define the objective, consider options and constraints, reason and decide, and take action and confirm results — recorded and visualized end to end.
A trace records the full sequence from situation to result, not only the final action — the sequence is what makes a decision explainable and improvable later.
03 / Knowledge Flow and the Trust Knowledge Graph

Knowledge Flow and the Trust Knowledge Graph

Knowledge Flow delivers the meaning, source, authority, validity period, scope, confidentiality, and update status of knowledge scattered across an organization to the moment a decision is made — not just the document text. A Trust Knowledge Graph is what lets that delivered knowledge become the grounds a trust judgment can be queried against.

More Than a Knowledge Graph

A Trust Knowledge Graph is heterogeneous by design, connecting node categories whose meaning and lifecycle differ:

  • Actor, Agent, Organization, Role
  • Goal, Constraint, Policy
  • Context, Situation, Event
  • Knowledge, Evidence, Source
  • Decision, Action, Result
  • Risk, Expectation, Confidence
  • Human Gate, Approval, Escalation

Entity, Event, and Assertion are kept as distinct node types. Overwriting "equipment M1 is at 82°C" as a property of the equipment node erases the past state and the source that claimed it — it must instead be an Event tied to the sensor, the source, and the timestamp.

Trust Context Is the Query Boundary

Trust inference does not walk the entire graph from an actor node outward. It cuts a subgraph starting from a Trust Context, containing at minimum:

  • Evaluator and Target
  • Role and Goal
  • Situation
  • Policy Set and Constraint Set
  • Time Horizon

The same Agent, evaluated for a different role, goal, policy version, counterparty, or time window, is a different Trust Context — past results can be reused, but a past evaluation value must never be copied over unconditionally.

Entity is not Event. Event is not Assertion. Assertion is not Evidence. Evidence is not Expectation. Confusing them corrupts the graph that trust is supposed to be queried from.
Diagram titled 'What is Knowledge Flow?' showing four stages — collect, connect and organize, deliver, and activate — turning scattered organizational knowledge into knowledge that reaches the right decision at the right time.
Knowledge Flow is the circulation that feeds a Trust Knowledge Graph — each unit of knowledge keeps its source, authority, and validity as it moves toward a decision.

Because past decisions must be reconstructable, not only current knowledge, the graph tracks valid time, transaction time, version, and provenance for every node — so a Trust Context evaluated today can be re-derived, and a Trust Context evaluated a year ago can still be reconstructed as it stood at that moment.

04 / Trust Engine and Expectation Graph

Trust Engine and Expectation Graph

The Trust Engine is the runtime structure that turns Decision Trace and current Knowledge into an Expectation Graph — a structured account of what decision, action, and result can be expected in the current Trust Context, and why.

i

Context Analyzer

Turns an incoming decision request into a Trust Context — role, goal, situation, policy, and time horizon — rather than passing on a bare subject ID.

ii

Decision Trace Retriever

Retrieves comparable past traces by role, goal, policy version, risk, and outcome quality — not similarity alone, and not successes only.

iii

Knowledge Integrator

Fixes currently applicable policy, constraint, and evidence into a Knowledge Snapshot, and surfaces contradictions it cannot resolve rather than averaging over them.

iv

Expectation Graph Builder

Builds a temporary, versioned subgraph — evaluator, subject, role, situation, policy, similar traces, expected decision, action, result, and risk — for this one evaluation.

v

Expectation Reasoner

Performs symbolic reasoning over the graph, ranking absolute boundary above statute, above human authority, above policy, above constraint, above learned pattern.

vi

Trust Output Layer

Combines symbolic and numeric output with risk and boundary into one versioned result — allow, allow-with-monitoring, hold, deny, or human review — not a threshold on a single score.

vii

Execution Monitor

Observes governed execution and records actual behavior as it happens — decision, tool call, policy check, approval, timeout, and recovery — as its own evidence plane.

viii

Trust Evaluator

Compares expected against actual behavior across goal alignment, policy and constraint compliance, safety, consistency, and recovery — kept as a vector, not collapsed into one number.

ix

Learning & Feedback

Routes each evaluation to the trace, the knowledge graph, policy review, or training data by cause — not everything toward retraining a model.

Diagram titled 'Chinoba Trust Infrastructure,' showing AI used to visualize the intent, judgment, and action behind a decision as the structured basis for a trust assessment.
An Expectation Graph exists to make this same structure explicit — intent, judgment, and action behind an expected decision — as an evidence path a human can inspect, not a single opaque number.

Symbolic and Neural Are Complementary by Design

The Expectation Graph is a symbolic structure — an evidence path and a reasoning path a human can walk. A graph neural network can, by design, be layered over that same graph to estimate numeric quantities such as expected-behavior probability, risk score, or confidence. The two are complementary design choices in this architecture, not a claim that GNN-based trust inference is a deployed or production-proven capability.

A Number Is Not the Verdict

Any numeric output — trust score, risk score, confidence — is treated as reference information alongside uncertainty, impact, and an explanation path, not as a threshold that by itself authorizes execution.

A higher-ranked hard constraint is never overridden by a lower-ranked score. A 0.99 probability of success does not permit what policy requires a human to approve.
05 / Trust, Boundary, Human Authority, and Runtime Decision

Trust, Boundary, Human Authority, and Runtime Decision

Trust is reference information for a runtime decision — it is not, by itself, permission to execute. Whether an action proceeds is evaluated together with Policy, Permission, Risk, Boundary, and Human Authority, every time.

What Boundary Protects

Boundary marks the limits that no trust score and no efficiency gain may trade away — life and safety, human rights, personal data, critical assets, and social infrastructure. A hard boundary violation returns Reject regardless of how high a trust inference scores.

Human Gate as a Real Control Point

A Human Gate is not an approval button clicked from habit. It presents the evidence behind a recommendation, the candidate options, the assessed risk, the potential impact, and the deadline for a decision — and it accepts approve, reject, modify, or dispute, not only yes.

Low risk, cleared thresholds — act. Uncertain, but explainable — ask, with the graph attached. Boundary or trust exceeded — stop, hold, or quarantine.
Diagram titled 'What is Boundary?' showing four boundary types — Role Boundary, Authority Boundary, Rule Boundary, and Data Boundary — as the basis for confident, trustworthy collaboration.
Boundary clarifies who may do what, with what authority, under which rules, and over which data — the limits trust is evaluated inside of, not a limit trust can widen.
06 / Applications of Trust Infrastructure

Applications of Trust Infrastructure

In each case, trust is not a score attached to a system. It is knowledge, context, and policy resolved into an expectation, checked against human authority, recorded as a decision trace, and corrected by outcome feedback. Higher-risk domains are described as design questions requiring governance, not as claims about deployed effect.

Manufacturing

Manufacturing Quality Decisions

A shipment-hold decision draws on the current quality policy and design documents, not just an anomaly score, and routes critical defects to a Human Gate before release.

Equipment

Maintenance and Shutdown Decisions

Stop-or-continue judgments weigh safety, productivity, and delivery against past failure traces and sensor data, escalating rather than resolving silently under competing pressure.

Finance

Financial Transactions and Risk

Approval, hold, and review decisions are explained through the trust graph behind them, with bias and fairness checked as part of the evaluation, not after the fact.

Healthcare — design question

Medical Support AI

A recommendation is only as good as the patient context and guidelines behind it; confidence, uncertainty, and a Human Gate to the physician are treated as required governance, not optional polish.

Legal

Contract Review and Legal Support

A clause is checked against current law and internal rules and past contract traces before it shapes a recommendation, with unresolved risk escalated to legal staff.

Multi-Agent

Multi-Agent Coordination

Deciding which agent to entrust with a role draws on an inter-agent trust graph, with limits on how far trust propagates and explicit detection of coordination failure.

Supply Chain

Cross-Organizational Coordination

Trust between companies is shared as verifiable, minimized evidence bound to a specific purpose and context — not a permanent score handed to a partner.

Public sector — design question

Public AI and Social Infrastructure

Government and public AI require explainability to citizens, fairness, scoped disclosure of the trust graph, and a working appeals process as governance requirements, not features.

07 / Operations, Evaluation, and Maturity

Operations, Evaluation, and Maturity

Trust Infrastructure is operated, not just designed: monitoring, alerting, fail-safes, rollback, security, privacy, and ethics apply to a Trust Engine the same way they apply to any other production system deciding real outcomes.

What Gets Measured

  • Predictive Accuracy — against a named target, not "trustworthy vs. not"
  • Calibration Error — whether a stated probability matches observed frequency
  • Explanation Fidelity — whether an explanation reflects the decision actually made
  • Graph Completeness — whether required evidence and policy are present, not graph size
  • Policy Compliance Rate — process compliance, not only good outcomes
  • Escalation Accuracy — escalation is expected behavior, not a failure to minimize
  • False Trust / False Distrust — the two errors are not symmetric in consequence
  • Robustness and Drift Detection — data, concept, policy, and graph drift, tracked separately

PoC to Production, Deliberately

A Trust Engine earns production scope the same way any governed system does: a narrow PoC on one business process, explicit human-in-the-loop before autonomy widens, and evaluation against the metrics above before the next stage of scope is granted — not a single launch decision.

Maturity is not automation rate. It is how much evidence, boundary, human authority, and improvement the system carries at each stage.
Maturity Model

From Logs Only to Social Trust Infrastructure

  1. L0 Logs Only Application and audit logs record what happened; why a particular decision was chosen is not yet structured. logs
  2. L1 Decision Trace Execution events become structured traces — need, context, policy, alternatives, decision, action, result, feedback. trace
  3. L2 Knowledge Integration Current policy, constraint, and design knowledge — versioned, sourced, and time-bound — connect to the trace. knowledge
  4. L3 Expectation Graph Expected decision, action, result, alternatives, and risk are represented as a structure, not a single rule output. expectation
  5. L4 Numeric Inference via GNN A graph neural network adds probability, risk, and confidence estimates alongside the symbolic structure — optional, not required to proceed. numeric
  6. L5 Continuous Learning Expected vs. actual behavior feeds back into trace, knowledge, graph, and thresholds under governed, versioned release. feedback
  7. L6 Cross-Organizational Trust Trust extends to suppliers, partners, and providers as verifiable, minimized, purpose-bound evidence — not a shared permanent score. cross-org
  8. L7 Social Trust Infrastructure Trust connects to public institutions — government, health, finance, energy — as an appealable, correctable civic capability, not a centralized score. social
Chinoba Field — Intelligence as Relationship, Knowledge Flow, Trust Infrastructure, Runtime Society, Governance and Boundary Systems, and Public AI and Algorithmic Governance, shown as six connected lines of inquiry
Trust Infrastructure is one layer of the Chinoba research field, not a standalone topic.
Decision Trace ↓ Knowledge Flow ↓ Trust ↓ Governance ↓ Coordination ↓ Runtime Society
Trust Infrastructure does not assign a fixed trust score to a person or an AI.   It is the foundation that explains, verifies, and improves, over time and against outcomes, how far someone — in a given role, for a given purpose, using specific knowledge and evidence, under specific policy and boundary — can be trusted to act.   Chinoba connects Decision Trace, Knowledge Flow, the Trust Knowledge Graph, the Expectation Graph, the Trust Engine, and Human Authority into the trust infrastructure that AI-era collaboration is built on.
Chinoba.org

New Book →  ·  YouTube →  ·  Blog →