A compact guide to Trust Artifact Architecture: evidence, human review, inspectable records and their separate demonstrations. Miami pilot and packet services remain proposed.
This companion to the Executive Brief explains the lab’s approach and links each architectural responsibility to a bounded example. It does not join separate prototypes into one runtime.
The lab explores how communities and businesses can turn ideas into inspectable workflows: keep the evidence, make decision authority explicit, and carry the resulting context into the next handoff. This page is a short map of the demonstrations. Each link says what it shows and what it does not establish.
DEFINE: Shape the request. → GROUND: Attach the evidence. → GOVERN: Apply an explicit rule. → DECIDE: Leave the decision to an accountable person. → PROVE: Make the record inspectable. → RECONCILE: Keep the state honest across handoffs.
A proposed pattern for dividing responsibility, not an industry standard, certification or integrated deployment. The adapter prepares requests and carries results; TAE/Guardian owns the policy verdict. A human approval, a separate execution grant and a verification result do not substitute for one another.
These are architectural roles, not connected services. The separate Engine reference source includes policy, review, scoped authority, receipt and verification code; this showcase does not call those services. Its R1 synthetic integration remains proposed: as documented on October 16, 2026, owners are unassigned, ten gates are open and 36 integration tests are not run.
GROUND · a seeded recording with indexed reviewer notes; corrections keep their source locators.
Boundary: Recording only. Accepting evidence does not approve the claim; the claim stays Held. Separate from the vendor-payment fixture.
GOVERN · a local vendor-payment fixture compares $8,500 with a $5,000 threshold and requires human review.
Boundary: Local routing illustration, not a connected adapter. No live policy authority, payment or human decision.
Bounded evidence handoff and guided review, on a separate site.
Boundary: A separate synthetic-claim prototype with its own runtime. Recorded or simulated elements are not human decisions or production execution.
PROVE · three local checks: identity agreement, threshold recomputation and evidence-pointer resolution.
Boundary: Illustrative browser-side checking of an unsigned gate record. No cryptographic attestation or transaction proof.
A separate export-inspection surface described as checking against a pinned authority snapshot.
Boundary: Not the showcase gate checker. Historical integrity is not current permission, source truth or human approval.
RECONCILE · an illustrative pending gate and the next-stage responsibility.
Boundary: Proposed coordination only. Preserve input records and link later results separately; receiving a packet is not substantive acceptance or execution permission.
The whole vendor-payment fixture, stage by stage. Boundary: No shared case identity or runtime handoff with the Hivewire recording.
How the roles and the responsibility pattern fit together. Boundary: Proposed architecture, not a deployed system.
A proposed distributed-node application for supply chains, logistics and commerce. Boundary: Proposed concept. No live mesh, network identity or transactions.
Source-backed food-distribution and changing-conditions simulations, plus governance scenarios. Boundary: Synthetic scenarios and simulated events. No real deliveries or approvals.
An optional in-site community-food demonstration of staged handoffs and record checks. Boundary: Not the same case or runtime as the external Proof Pilot synthetic-claim prototype.
Proposed design, not executable evidence or production readiness.
An interaction concept, not a connected assistant or delegated decision authority.
Suggested paths are editorial recommendations, not claims validated by the demonstrations.
Use Proof Pilot and the bounded showcase exercises to explain evidence, review, authority and handoffs. Record comprehension gaps, friction and unresolved dependencies before choosing a field pilot.
Develop one scoped Miami civic pilot alongside an idea-to-prototype-packet service for business owners. Candidate projects include community meal distribution, maintenance handoffs and small-business intake coordination. A packet would hold the problem, participants, workflow, evidence and assumptions, demonstration, decision boundaries, implementation steps and measures of success.
Both stages are proposed. The Miami pilot and the packet service are not established offerings or commitments, and no affiliation, funding or endorsement is implied.
Bring one recurring coordination problem, its current handoff, an accountable owner and an observable success measure. A proposed first engagement would aim to produce a scoped packet for review, so an accountable person can decide whether a field pilot is justified.
Share this guide: https://trust-artifact-architecture-showcase-a-anglade999labs.org/executive-one-pager. This shares the page only, not a private case, recorded decision or simulation state.
The atomic trust unit: one bounded handoff describes a request, evidence and limits, receiver checks and a linked outcome—not automatic approval or permission to act.
Interactive controls require JavaScript. This reading guide remains available without it; reading this page does not perform a simulation or create a decision.
The Executive Brief explains the thesis through the vendor-payment fixture. This companion is a broader lab overview and demonstration link guide, including proposed community applications.
Link to this questionNo. The vendor-payment fixture, Hivewire recording, separate Proof Pilot synthetic claim prototype and logistics/commerce simulations are distinct examples. Navigation does not transfer a case or decision between them.
Link to this questionNo. Record checks do not establish source truth, human decision authority, approval or payment. Proposed pilots and services are not established offerings.
Link to this question