Questions & Architecture Guide

Start with your question. Follow the explanation, example, and limits. Explore the architectural thesis by topic, with a glossary below when you need a definition.

Start with a question. Choose where to drill down.

A question-led guide to the architectural thesis, its demonstrations and their limits. The glossary below supports the answers; it is not required reading or an industry standard.

Choose a topic and read a short answer.
Follow its labelled explanation or example link, keeping the boundary in view.
Use the glossary when you need a definition, or share a direct question link.

Common questions

These questions and definitions are available without JavaScript. Reading them does not perform a simulation or create a decision.

New to the whole idea? Take the optional five-minute introduction. Have a specific question? Choose a topic here. Need an overview to share? Use the Executive Guide. These are reading choices, not workflow steps or permissions.

Start the five-minute introduction · Executive Guide

Choose a topic

Purpose — The problem this architecture is intended to address.
How it works — What a bounded handoff carries and what the receiver checks.
Human responsibility — Separate a rule result from a person’s decision and permission to act.
Evidence & verification — What a check establishes—and what it does not.
Models & coordination — Where model choice fits without replacing governance.
Distributed use — Explore logistics and commerce applications without assuming an operating mesh.
Maturity & demonstrations — What you can inspect, which examples are separate, and what remains proposed.

Go to the glossary

Explore by question

Purpose

The problem this architecture is intended to address.

What is Trust Artifact Architecture for?

It is a proposed way to structure governed work so that evidence, policy results, human review and outcomes leave inspectable records. It is an architectural proposition explored through synthetic examples, not an industry standard and not a deployed product.

Explanation · proposed architecture

Read the architecture

Architectural proposition · Read the Lab Thesis

Boundary: The architectural thesis is not evidence of a deployed system.

Link to this question

Why not just use email or chat?

You can use either. The proposed pattern makes the request, supporting basis, rule result, missing human decision and next-action limits explicit, instead of asking the reader to infer them from a message. Email and chat can carry those details too; the channel alone does not supply them.

Illustrative comparison · local vendor-payment fixture

Compare the two handoffs

Boundary: This is not a measured comparison of tools, time savings or outcomes.

Link to this question

How it works

What a bounded handoff carries and what the receiver checks.

What does an atomic trust unit carry between participants?

It describes one bounded handoff: the request, supporting evidence, limits, receiver checks and a linked outcome. The receiver must check the bundle against its own requirements before relying on it. Receiving a record does not automatically grant permission to act.

Explanation · proposed bounded-handoff pattern

Understand the bounded handoff

Local synthetic demonstration · Inspect the vendor-payment example

Boundary: There is no shared implemented packet schema or distributed atomicity guarantee.

Link to this question

Human responsibility

Separate a rule result from a person’s decision and permission to act.

How are policy, human approval and authority different?

A policy result applies a rule to a proposed action. Human approval is a person's explicit decision about an exact proposal and its evidence. Authority concerns who may decide or act and within which limits. Approval does not replace a separate, current execution grant enforced by the receiving system. These examples do not establish real operational authority, and receiving a record is not accepting it.

Explanation · human-review boundary

Read about human review

Local synthetic demonstration · Inspect the pending-review stop

Boundary: The local fixture has no authenticated reviewer decision or payment execution.

Link to this question

Evidence & verification

What a check establishes—and what it does not.

What does verification prove, and what does it not?

Each verifier checks only its declared record properties. The vendor-payment checker recomputes three local fixture checks; it does not verify signatures. Some other examples check hashes or demonstration signatures against their own formats. Passing does not establish source truth, authenticated approval or payment authorization. An offline verifier reusing a shared library is a separate process, not an independent cryptographic implementation.

Local demonstration · fixture-specific checks

Inspect decision verification

Evidence register · Read the evidence and limitations

Boundary: A successful check is not source truth, human approval or payment authorization.

Link to this question

Models & coordination

Where model choice fits without replacing governance.

Where does EMCC fit, and what does model-agnostic mean here?

EMCC is proposed coordination software that could select a compatible model, supply permitted context and carry structured results between responsibilities. Model-agnostic means the design need not depend on one provider—not that every model is already compatible. Each provider needs an adapter, capability checks and tests. Model output does not replace policy authority, a human decision or a separately enforced execution grant.

Explanation · proposed coordination design

Explore proposed model coordination

Boundary: No model routing, tool execution or cross-provider interoperability is demonstrated here.

Link to this question

Distributed use

Explore logistics and commerce applications without assuming an operating mesh.

What would a distributed mesh require first?

Named accountable owners, agreed request, result, evidence and receipt formats, identity and key management, bounded permissions, conflict-handling rules and recorded integration tests would be needed. Missing authority, changed evidence, failed required review or unavailable policy evaluation must prevent continuation. The mesh remains proposed here; approvals alone would not complete its implementation.

Concept · proposed distributed architecture

Explore the mesh proposal

Separate browser-local synthetic examples · Explore logistics/commerce walkthroughs

Boundary: The walkthroughs do not establish a running mesh or shared authority.

Link to this question

Maturity & demonstrations

What you can inspect, which examples are separate, and what remains proposed.

What can a visitor actually try here?

You can follow the guided run of the vendor-payment fixture, explore the logistics and commerce walkthroughs in Watch, Try and Inspect modes, and inspect records such as receipts and proof packets. The three food and governance walkthroughs use local synthetic data in your browser. External destinations and recordings have their own stated scope.

Catalogue · separate local demonstrations

Open the walkthrough library

Boundary: Each example retains its own record format, runtime and verification limits.

Link to this question

How do the Architecture, the Engine and Proof Pilot differ?

The Architecture is the proposed pattern of roles and records. The Engine is separate reference source code that explores parts of that pattern; it is not connected to this showcase, and source code alone does not establish a running service. The Proof Pilot synthetic-claim demonstration has its own runtime. Proof Pilot/Gigi — Food Supply-Chain Demo is a separate, externally hosted sample-record experience, reached through Start Here / Demo. It is not that synthetic-claim demonstration. The vendor-payment REVIEW fixture ($8,500 request against a $5,000 threshold), the Hivewire recording and the food-distribution simulations are separate cases.

Reference map · separate prototypes and runtimes

See how the prototypes fit together

REFERENCE SYSTEM DESIGN / PROPOSED INTERACTION CONCEPT · Inspect the two Proof Pilot design decks

Boundary: Links between destinations are not live case transfers or proof of integration.

Link to this question

Are the demonstrations connected to real systems?

No. No real payment is made, no delivery is dispatched, no authenticated human approval is collected and no distributed mesh is running. Controls labelled approve or release change local demonstration state only.

Evidence register · maturity and limitations

Review evidence and limitations

Boundary: Proposed integration must not be read as an operating capability.

Link to this question

Terms used in the showcase

Atomic trust unit

An architectural pattern for one bounded, inspectable handoff: a specific request, its evidence and limits, checks by the receiver, and a linked record of the outcome.

Example: In a proposed producer-to-kitchen handoff, the receiver would check the submitted record version, applicable rules and required review before recording a result or a stop.
Boundary: Atomic means the smallest handoff considered as a unit, not all-or-nothing completion across systems. This is not a common packet format implemented across the demos. Receiving a valid packet does not prove source truth, approve a request or authorize execution. Missing authority, changed evidence, failed required review or unavailable policy evaluation must prevent continuation in the proposed integration.

Architecture and bounded handoffs · Link to this term

EMCC

A proposed coordination layer for bounded tasks, permitted context and workflow state across compatible models and tools, without depending on one model provider.

Example: It could request a structured model response, route a proposed tool call through governance checks, pause for required human review and link the result to the work record.
Boundary: EMCC is not running here. The adapter maps requests; TAE/Guardian owns the proposed policy verdict. Model output is not human approval or a current execution grant enforced by the receiving system. No model routing, tool execution or cross-provider interoperability is demonstrated.

Proposed EMCC coordination · Link to this term

Model-agnostic

Designed to work with compatible models from different providers rather than relying on one provider's model.

Example: A proposed coordinator could request the same bounded task through different provider adapters while keeping evidence and approval requirements explicit.
Boundary: This is a design aim, not tested interoperability here. Each provider needs an adapter, capability checks and tests for tool calling, structured responses and data handling. Models are not interchangeable in capability or results; changing models does not remove governance requirements.

Model choice and coordination limits · Link to this term

Trust artifact

A structured record that makes a proposal, evidence, rule result or decision inspectable, with its scope and responsible role stated where available.

Example: The governed-gate receipt records the vendor-payment rule result, while the human decision remains absent.
Boundary: A record does not make the underlying claim true or establish a decision that has not been made.

Governed-gate receipt · Link to this term

Evidence

The inputs a workflow relies on, such as invoices, readings or statements, recorded with enough detail to be referenced.

Example: A synthetic invoice amount of $8,500 attached to a payment request.
Boundary: Recording evidence is not checking that it is accurate or complete.

Evidence & provenance · Link to this term

Provenance

Where a piece of evidence came from and how it reached the record.

Example: Noting which source document and step produced a field.
Boundary: Stated provenance can be wrong; it is a claim about origin, not proof of it.

Evidence & provenance · Link to this term

Policy

Rules used to evaluate a proposed action and determine its permitted next step.

Example: In the vendor-payment fixture, an $8,500 request exceeds the $5,000 threshold and requires review.
Boundary: A rule result is not human approval. The local fixture is not a connected Engine policy service.

Governance adapter · Link to this term

Adapter

The component that maps workflow data into the policy layer and carries results back.

Example: Translating a payment request into fields the policy evaluator reads.
Boundary: The adapter maps and carries results; the policy verdict itself is owned by TAE/Guardian, not the adapter.

Governance adapter · Link to this term

Review record

A record of a reviewer's explicit decision, rationale and scope for a particular proposal and evidence.

Example: A local acceptance or revision request entered in a food walkthrough's simulated review step.
Boundary: Walkthrough review is simulated. The separate vendor-payment fixture remains pending, with no human decision recorded.

Human review · Link to this term

Execution grant

A separate, explicit permission to carry out a specific operation.

Example: A distinct step that would release a payment after approval.
Boundary: Approval is not an execution grant. No grant here causes a real payment or delivery.

Workflow coordination · Link to this term

Receipt

A record stating what happened at a step, issued after the step.

Example: The viewer experience receipt summarising pages you visited.
Boundary: Receiving a receipt is not accepting its contents.

Viewer experience receipt · Link to this term

Proof packet

A bundle of records and checks packaged so another party can inspect them offline.

Example: An exported walkthrough packet with hashes and demonstration signatures.
Boundary: A packet's integrity says nothing about whether the workflow inside it was complete or correct.

Walkthrough library · Link to this term

Verifier

A tool that checks specified properties of a record against stated rules and reference material.

Example: A walkthrough's matching offline checker recomputes hashes and checks demonstration signatures for that packet format.
Boundary: Verification is not source truth, approval or current permission. Demonstration keys do not authenticate a real issuer; a shared-library checker is not an independent cryptographic implementation.

Decision verification · Link to this term

Reconciliation

Comparing records from different steps or parties and resolving differences.

Example: Matching a planned delivery against a changed-conditions update.
Boundary: The walkthroughs simulate reconciliation; no real parties' records are reconciled.

Changing conditions walkthrough · Link to this term

Node

One participant in a proposed network that produces and checks records.

Example: A warehouse or distributor role in the mesh proposal.
Boundary: Nodes on this site are illustrations, not running services.

Distributed mesh · Link to this term

Mesh

A proposed network of participants exchanging records across bounded responsibilities.

Example: Supply-chain handoffs between several organisations.
Boundary: No live mesh exists here. Sharing records does not remove the need for accountable owners, operating agreements or enforced permissions.

Distributed mesh · Link to this term

Fixture

A fixed, synthetic scenario used to demonstrate behaviour repeatably.

Example: The vendor payment REVIEW fixture: $8,500 requested against a $5,000 threshold.
Boundary: A fixture shows how records behave in one case; it is not evidence of real-world results.

Guided run · Link to this term

Simulation

An interactive run that imitates operational events with synthetic data.

Example: The community food distribution walkthrough.
Boundary: Simulated events, decisions and signing keys do not represent real deliveries, people or authority.

Food distribution walkthrough · Link to this term