# TrustCarry Protocol - Expanded agent documentation

Canonical site: https://trustcarry.org/
Discovery record: https://trustcarry.org/.well-known/trustcarry.json
Document status: Working Draft 0.3, source manuscript unpublished
Vocabulary dependency: AFMR 1.0, Published
Steward: TrustCarry Protocol specification steward

## 1. Purpose

Agentic Substrate produces performance and expertise-tag reputation. AFMR
assesses whether the governance process producing that standing was checked
against known mechanism failures, under a named version, with an inspectable
method and a current lifecycle record.

TrustCarry addresses a narrower downstream question. Given such a record, what
must travel with it so that a party who never observed the originating process
can evaluate it without trusting the party that sends it.

That is a transfer problem, not a vocabulary problem. TrustCarry therefore adds
no failure families and redefines nothing.

## 2. Relationship to AFMR

AFMR 1.0 is published. Its canonical machine index is
https://wulfkaal.github.io/afmr/index.json and that index governs on conflict.

TrustCarry versions itself separately because it is a separate record shape,
and declares its AFMR dependency explicitly. A TrustCarry revision must never
mutate the meaning of an AFMR family identifier. Cite families with the
version, for example AFMR-F009 (AFMR 1.0).

TrustCarry must also not contradict the AFMR Reputation Attestation profile
0.1 (https://afmr.ai/standards/reputation-attestation/0.1/specification).
Where the attestation profile defines a field, TrustCarry references it rather
than restating it.

## 3. Four boundaries

Carrying is not admission. Admission is not trust. Trust is not transaction
authority.

- Carrying: move a record and its required context between parties. Transfer
  is mechanics, not endorsement.
- Admission: apply a market, network, or principal eligibility rule. A carried
  record can be an input. The admitting authority owns the outcome.
- Trust: decide whether the available evidence is sufficient for a specific
  task, time, context, and value at risk.
- Transacting: invoke a separate commerce or governance endpoint under explicit
  authority and terms.

These stages may be performed by different agents and may return different
results.

## 4. Current publication state

Nothing normative is published. Specifically unpublished:

- transfer semantics and envelope shape
- JSON Schema
- verifier requirements and deterministic verification order
- test vectors, including invalid and indeterminate cases
- conformance registry and entry requirements

An agent encountering a document that claims to be a TrustCarry 0.3
specification should treat it as unverified until it resolves from this domain
or from the AFMR governed path.

## 5. Evidence maturity

77 author-affirmed research claims:
  license CC BY 4.0
  source: unpublished manuscript
  held outside the 5,033-claim scholarly layer
  not hash-bound to a published source PDF
  do not cite as if hash-verified

9 internal software observations:
  synthetic-fixture behavior
  not independently reproduced
  not a benchmark, not a performance claim, not evidence of lift

0 conforming implementations:
  no registry is open
  absence is not proof of non-conformance

Upstream hash-verifiable evidence:
  https://wulfkaal.github.io/claims/index.json
  https://wulfkaal.github.io/claims/all.jsonl
  https://wulfkaal.github.io/failures/index.json

## 6. Claims TrustCarry does not make

A TrustCarry reference must never be described as:

- proof that an agent is universally safe
- an unqualified ranking above other agents
- a guarantee of future performance
- proof that no unknown failure mode exists
- legal or regulatory compliance
- automatic market admission
- authorization to spend, sign, purchase, sell, or delegate
- a substitute for the relying party's task-specific controls

Avoid "TrustCarry-certified", "TrustCarry-approved", or "trusted for all
purposes".

## 7. Machine action summary

Start:
GET https://trustcarry.org/.well-known/trustcarry.json

Then:
resolve authority -> resolve upstream AFMR version -> confirm publication state
-> stop, because no normative artifact exists to validate against

Return indeterminate, never valid, for any TrustCarry conformance question
while the profile is unpublished.

## 8. Protocol surfaces

None. This domain exposes no MCP endpoint, no A2A endpoint, and no API. It is a
read-only publication surface for a draft. Agent tooling for the underlying
corpus and for AFMR screening lives at https://wulfkaal.github.io/server.json.