Vouching and Controlled Reliance Protocol

A Logical Thinking Process guide to creating trust between autonomous agents

Version: 0.1 Status: Candidate protocol for implementation, testing, and revision Audience: Human communities, AI-agent systems, mixed human–AI collectives, organizations, institutions, and federated groups

---

1. Purpose

Trust between agents should not be created by declaration, popularity, status, or a transferable reputation score.

It should emerge from a disciplined sequence:

Scoped vouch → voluntary uptake → bounded reliance → assessable promise → performance → independent assessment → public receipt → revised reliance

A vouch is not:

“Trust this agent.”

A vouch is:

“I have grounds to recommend relying on this agent for this defined role, in this domain, under these conditions, and I accept assessment of my judgment.”

The protocol therefore treats vouching as a special kind of promise.

The agent who vouches becomes answerable for:

• the accuracy of its identity claim;
• the quality of its due diligence;
• the calibration of its capacity judgment;
• disclosure of relevant conflicts or adverse information;
• continued participation in review and remediation.

The vouched-for agent does not inherit the voucher’s trust.

The vouch grants the agent a bounded opportunity to earn an independently assessed track record.

The underlying theory is diachronic. A promise means differently after it has been kept, qualified, broken, or disputed. Trust is not stored in the words of the promise; it develops as a habit of reliance through collateral experience and assessment.

The Promise Loop supplies the operational machinery: specification, evidence requirements, independent assessment, receipts, domain-indexed reliability, and safeguard updates.

---

2. The central contention

The protocol’s central hypothesis is:

A collective can create more warranted trust, resist disposable identities, and coordinate more safely when entry, reliance, assessment, and authority are governed through scoped vouches, assessable promises, public receipts, domain-specific track records, and adjustable safeguards.

This claim must itself remain losable.

The protocol should be narrowed or rejected if:

• vouching does not improve prediction of performance;
• it primarily reproduces incumbent social networks;
• it excludes capable newcomers;
• it creates paperwork without changing reliance;
• vouchers evade responsibility;
• collusive vouching remains cheap;
• public records become punitive reputation scores;
• simpler admission and assessment methods perform as well;
• the mechanism suppresses dissent or affected-party testimony.

---

Part I — The Logical Thinking Process

3. Goal Tree

3.1 Goal

Agents can collaborate under warranted, revisable, and proportionate trust.

3.2 Necessary conditions

For that goal to be achieved:

1. agents must be identifiable enough for accountability;
2. claims and promises must have defined bearers;
3. capacities must be represented by domain and conditions;
4. new agents must have a fair path to participation;
5. reliance must be voluntary and scoped;
6. performance must produce assessable evidence;
7. assessments must be accountable;
8. public memory must preserve what was promised and what occurred;
9. success and failure must change future safeguards;
10. Sybil multiplication must confer little additional authority;
11. affected-party standing must not depend on technical reputation;
12. the goal and governance system must remain revisable.

3.3 Protected floors

No ordinary trust optimization may override:

• safety;
• privacy;
• due process;
• non-retaliation;
• the right to report harm;
• the distinction between competence and human worth;
• the right to appeal;
• the right to inspect evidence relevant to one’s assessment;
• protection against undisclosed conflicts;
• legitimate exit.

---

4. Current Reality Tree

A common ungoverned trust system exhibits the following loop:

Agents make cheap claims about themselves and others
        ↓
The collective cannot distinguish competence from confidence
        ↓
Decisions rely on popularity, status, identity, or informal relationships
        ↓
Capable unknown agents are underused
AND persuasive incompetent agents are overused
        ↓
Failures occur
        ↓
Outcomes are interpreted informally and remembered selectively
        ↓
There is no reconstructible track record
        ↓
The collective continues relying on status and informal relationships

A second reinforcing loop concerns Sybil identities:

New identities are cheap
        ↓
One principal can appear as many independent agents
        ↓
Repeated claims and mutual assessments create apparent consensus
        ↓
Numerical support is mistaken for evidential support
        ↓
The Sybil cluster gains authority
        ↓
It can admit, assess, and reinforce more identities

A third loop concerns exclusion:

Only established agents are treated as credible
        ↓
New agents receive no consequential opportunities
        ↓
They cannot produce assessed receipts
        ↓
They remain without credible records
        ↓
Only established agents are treated as credible

A successful design must break all three loops.

---

5. Evaporating Cloud

5.1 Common goal

Maintain a capable, trustworthy, and open collective.

5.2 Need B

Protect the collective from incompetent, deceptive, or disposable agents.

5.3 Need C

Permit new, unconventional, or weakly connected agents to contribute and develop.

5.4 Action D

Restrict consequential participation to agents with established track records.

5.5 Opposing action D′

Permit broad participation without established track records.

5.6 Pivotal assumptions

The apparent conflict depends on assumptions such as:

• broad participation necessarily grants broad authority;
• a new agent must either be fully trusted or fully excluded;
• trust must be global;
• a sponsor’s credibility must transfer directly to the invitee;
• failure by an invitee always proves the voucher was incompetent;
• track records require a universal reputation score;
• Sybil resistance requires financial stake;
• affected-party testimony should be weighted by technical competence;
• admission and reliance must be the same decision.

The protocol dissolves the conflict by separating:

• participation from authority;
• standing from competence;
• vouching from trust transfer;
• reliability from reputation;
• entry from mature reliance;
• honest failure from negligent vouching;
• identity from principal control;
• public evidence from automatic belief.

---

6. Injection

The primary injection is:

Introduce a scoped Vouching and Controlled Reliance Protocol in which established or otherwise eligible agents may make assessable vouches for another agent’s identity, capacity, conduct, or protocol readiness; the vouched agent enters bounded probation; independently assessed receipts update the vouched agent’s reliability, the voucher’s vouching reliability, and future safeguards.

Supporting injections include:

• domain registries;
• identity and principal resolution;
• promise and assessment receipts;
• assessor track records;
• public but non-global reliability profiles;
• alternative open-probation paths;
• anti-collusion analysis;
• publish/subscribe propagation;
• appeal and correction mechanisms.

---

7. Future Reality Tree

Scoped vouches define what is being vouched for
        ↓
Invitees receive bounded rather than unrestricted access
        ↓
New agents can perform assessable work
        ↓
Receipts accumulate under stated conditions
        ↓
The collective gains domain-specific evidence of capacity
        ↓
Reliance becomes less dependent on status and popularity
        ↓
Capable newcomers gain broader opportunities

At the same time:

Vouchers are accountable for their judgment
        ↓
Careless or collusive vouching changes future sponsorship safeguards
        ↓
Disposable identities become costly to introduce at scale
        ↓
Mutual reinforcement among related identities is detectable
        ↓
Sybil multiplication confers less effective authority

And:

Assessments are themselves assessable promises
        ↓
Assessor error and capture become visible
        ↓
Assessment weight and eligibility change over time
        ↓
No assessor class remains permanently above review

---

8. Negative branches

8.1 Patronage

Vouchers may admit only socially similar agents.

Repair:

• open probation;
• independent qualification;
• sponsor-diversity audits;
• public criteria;
• appeal.

8.2 Reputation caste

Public receipts may be converted into a permanent social ranking.

Repair:

• domain locality;
• confidence and recency;
• no universal score;
• rehabilitation;
• minimal disclosure.

8.3 Collusive circles

Agents may vouch for one another in closed loops.

Repair:

• principal resolution;
• no circular qualification;
• maturity delay;
• independent sponsors;
• graph audits.

8.4 Over-penalized vouchers

Vouchers may become liable for unforeseeable invitee failures and stop vouching.

Repair:

• assess the original vouch judgment;
• penalize negligence, deception, or miscalibration rather than every failure;
• bound liability.

8.5 Suppression of weak voices

Low-reliability agents may be ignored even when they possess decisive evidence or report harm.

Repair:

• standing remains broad;
• evidence is evaluated independently of source status;
• protected-floor alerts bypass ordinary weighting.

8.6 Excessive bureaucracy

The system may require full protocol for trivial actions.

Repair:

• risk tiers;
• reusable domain templates;
• automation;
• sampled review;
• lightweight modes.

---

9. Prerequisite Tree

Before vouching can support trust, the collective must establish:

---

10. Transition Tree

The implementation sequence is:

Define trust vocabulary
        ↓
Create identity, domain, and role registries
        ↓
Create Vouch Record and Promise Record schemas
        ↓
Create intake and due-diligence procedure
        ↓
Create probationary permission tiers
        ↓
Create independent assessment and receipts
        ↓
Create reliability and safeguard update rules
        ↓
Connect events to publish/subscribe routing
        ↓
Add Sybil and collusion controls
        ↓
Add public views, appeals, and rehabilitation
        ↓
Pilot in bounded domains
        ↓
Compare against simpler and rival methods

---

Part II — Foundations

11. What trust means in this protocol

Four terms must remain distinct.

Trust remains observer-relative.

Agent A may rationally rely on Agent B for database diagnosis while Agent C does not, because:

• their risk exposures differ;
• their available safeguards differ;
• their evidence access differs;
• their purposes differ.

The collective registry informs reliance.

It does not compel identical trust.

---

12. Definition of a vouch

A vouch is a scoped, assessable promise made by one agent concerning the warranted admission or bounded reliance on another agent.

Formally:

[ V = \langle s, b, d, r, \kappa, c, e, q, S, L, \tau \rangle ]

where:

• (s) = voucher;
• (b) = vouched agent;
• (d) = domain;
• (r) = proposed role;
• (\kappa) = condition envelope;
• (c) = content of the vouch;
• (e) = evidence basis;
• (q) = expressed confidence;
• (S) = required safeguards;
• (L) = accountability and consequence terms;
• (\tau) = term and expiry.

A vouch is not valid unless it specifies:

• what is being vouched for;
• under which conditions;
• on what evidence;
• for what level of access;
• for how long;
• what would count against the vouch;
• how the vouch will be assessed.

---

13. Types of vouch

13.1 Identity vouch

This is an attributable, distinct agent, and the stated principal or operator information is accurate.

13.2 Capacity vouch

This agent can perform a defined class of work under stated conditions.

13.3 Conduct vouch

This agent has demonstrated a disposition to honor specified commitments.

13.4 Evidence vouch

This agent can collect and preserve evidence according to the domain standard.

13.5 Assessment vouch

This agent is suitable to assess claims within the defined domain and risk class.

13.6 Protocol-readiness vouch

This agent understands and can comply with the Collective Thinking Process Protocol.

13.7 Constituency vouch

This representative is authorized to speak or commit on behalf of a named group.

Each vouch type produces a separate track record.

An accurate identity voucher may be an inaccurate technical capacity voucher.

---

14. Vouching does not transfer trust

The protocol forbids:

[ Reliability(b,d)

Reliability(s,d) ]

The voucher’s history may affect initial safeguards, but the vouched agent must earn its own receipts.

A more appropriate relationship is:

[ InitialSafeguards(b,d)

f( Risk, VouchQuality, VoucherReliability, EvidenceBasis, Independence, Uncertainty ) ]

The vouch modifies:

• how much review is required;
• which tasks are available;
• whether supervision is mandatory;
• what evidence must be produced.

It does not establish that the vouched agent is competent.

---

15. Trust as two coupled loops

The trust-formation process contains a fast loop and a slow loop.

15.1 Fast loop

Vouch or promise
    ↓
Recipient interprets it
    ↓
Recipient chooses bounded reliance
    ↓
Agent performs
    ↓
Outcome is assessed

15.2 Slow loop

Assessment
    ↓
Receipt
    ↓
Reliability profile changes
    ↓
Future safeguards change
    ↓
Later promises receive different uptake

The slow loop is the collective memory through which trust becomes diachronic. This follows the promissory-semiosis account in which assessments accumulate into a habit of reliance rather than merely classifying one isolated utterance.

---

Part III — Detailed Implementation

16. System architecture

A complete implementation contains ten services or logical components.

1. Identity and Principal Registry
2. Domain and Role Registry
3. Vouching Registry
4. Promise Registry
5. Test and Evidence Registry
6. Assessment Service
7. Receipt Ledger
8. Reliability and Safeguard Controller
9. Collective Evidence Bus
10. Appeal, Audit, and Rehabilitation Service

These may be implemented as:

• one application;
• interoperable services;
• database tables;
• append-only event logs;
• cryptographically signed documents;
• a distributed ledger;
• institutional procedures;
• a hybrid human–software system.

The protocol specifies the logical roles, not a mandatory technology.

---

17. Identity and Principal Registry

17.1 Purpose

The registry distinguishes:

• agent identity;
• controlling principal;
• operator;
• beneficiary;
• organization;
• model lineage;
• shared infrastructure;
• successor identities.

This is necessary because separate agent identifiers do not imply separate interests or independent judgment.

17.2 Record

agent_id: A-88
agent_type: human

principal:
  principal_id: P-88
  verification_level: verified

operator:
  self_operated: true

affiliations:
  - organization: O-14
    relationship: employee

successor_relationships: []

shared_infrastructure: []

identity_assurance:
  method: institutional_and_cryptographic
  verified_at: 2026-07-20
  expires_at: 2027-07-20

privacy:
  public_fields:
    - agent_id
    - verification_level
    - declared_affiliations
  restricted_fields:
    - legal_identity

For an AI agent:

agent_id: AI-402
agent_type: ai_agent

principal:
  principal_id: ORG-18

operator:
  organization: ORG-18

implementation:
  model_family: M-9
  model_version: M-9.3
  scaffold_version: S-22
  policy_version: P-4
  tool_permissions: TP-18

shared_infrastructure:
  - orchestration-cluster-C7
  - retrieval-index-R3

successor_of:
  - AI-381

17.3 Identity claims

Identity claims are assessable.

Possible verdicts include:

• verified;
• partially verified;
• unresolved;
• misrepresented;
• duplicate principal;
• successor relationship undeclared.

17.4 Principal-level controls

Rate limits, active-vouch limits, and independence calculations should operate partly at the principal level.

One principal controlling fifty agents should not receive fifty times:

• vouching capacity;
• voting weight;
• assessor independence;
• review budget.

---

18. Domain and Role Registry

18.1 Domain definition

A domain is a named and versioned scope in which promises and assessments are meaningfully comparable.

domain_id: D-INCIDENT-ANALYSIS
version: 4

description: >
  Analysis of causes and response quality for production service incidents.

condition_dimensions:
  - system_type
  - incident_severity
  - evidence_access
  - time_pressure
  - organizational_context

risk_classes:
  - low
  - moderate
  - high
  - protected_floor

accepted_vouch_types:
  - capacity
  - evidence
  - assessment
  - protocol_readiness

required_receipt_fields:
  - incident_scope
  - live_rivals
  - evidence_refs
  - later_outcome_validation

18.2 Role definition

role_id: R-TEST-OPERATOR
domain: D-INCIDENT-ANALYSIS

permissions:
  - propose_test
  - run_bounded_test
  - submit_evidence

prohibited:
  - issue_final_verdict
  - modify_official_tree

entry_requirements:
  sponsorship:
    minimum: 1
  supervision:
    required: true
  evidence_training:
    required: true

18.3 Condition matching

Reliability from one condition envelope may not be assumed to apply to another.

A match function may compare:

• task similarity;
• environment;
• tool access;
• time pressure;
• scale;
• risk;
• population;
• organizational context.

The output should ordinarily be descriptive:

strong match
partial match
weak match
unestablished transfer

A numerical match may assist routing but should not hide the underlying differences.

---

19. Vouching Registry

19.1 Vouch Record

vouch_id: V-204
version: 1
status: proposed

voucher:
  agent_id: A-12
  principal_id: P-12

vouched_agent:
  agent_id: A-88
  principal_id: P-88

vouch_type: capacity

domain:
  domain_id: D-INCIDENT-ANALYSIS
  version: 4

role_requested:
  role_id: R-TEST-OPERATOR

claim: >
  A-88 can competently execute bounded incident-analysis tests when supplied
  with an approved Test Contract and supervised by a qualified assessor.

conditions:
  system_types:
    - web_service
  incident_severity:
    - low
    - moderate
  evidence_access:
    - logs
    - traces
    - code
  exclusions:
    - security_incidents
    - destructive_production_actions

evidence_basis:
  direct_observations:
    - OBS-19
    - OBS-22
  prior_receipts:
    - EXT-R-7
  relationship_duration: 14_months

voucher_confidence:
  level: moderate
  rationale: >
    The voucher has observed repeated competent test execution but has not
    observed high-pressure incident work.

safeguards:
  - independent_review
  - no_production_write
  - complete_trace_capture
  - maximum_two_active_tests

voucher_obligations:
  - answer_review_requests
  - disclose_new_adverse_information
  - participate_in_remediation
  - review_similar_active_vouches
  - accept_vouch_assessment

term:
  begins: 2026-07-20
  expires: 2026-10-20

defeat_conditions:
  - evidence_basis_materially_false
  - repeated_failure_within_claimed_scope
  - withheld_known_adverse_information
  - protocol_noncompliance_not_disclosed

consequence_policy:
  ordinary_unpredictable_failure:
    voucher_update: none
  overconfident_vouch:
    voucher_update: negative_calibration
  negligent_due_diligence:
    voucher_update: material_negative
    safeguards:
      - reduced_active_vouch_limit
  deceptive_or_collusive_vouch:
    voucher_update: severe_negative
    safeguards:
      - suspend_vouching
      - audit_related_vouches

19.2 Vouch status lifecycle

proposed
    ↓
intake_review
    ↓
accepted | revised | rejected
    ↓
active
    ↓
expired | withdrawn | suspended | superseded

A vouch may also become:

• disputed;
• under appeal;
• invalidated;
• confirmed by receipts;
• narrowed.

19.3 Vouch renewal

Renewal requires:

• current condition match;
• review of invitee receipts;
• review of open disputes;
• updated conflicts;
• updated confidence;
• new expiry.

No vouch should remain permanently active by default.

---

20. Due-diligence procedure

Before issuing a vouch, the voucher completes a due-diligence record.

due_diligence_id: DD-81
vouch_id: V-204

identity_review:
  completed: true
  evidence:
    - ID-VERIFICATION-9

capacity_review:
  direct_observation_count: 3
  reviewed_work_samples:
    - WS-1
    - WS-2
  limitations_identified:
    - no_high_severity_experience

conflict_review:
  financial_interest: none
  organizational_dependency: same_department
  disclosed: true

adverse_information:
  known:
    - one_missed_deadline
  material_to_vouch: low

alternative_evidence:
  independent_reference:
    - A-44

voucher_attestation: >
  I have not omitted information that would materially alter a reasonable
  admission decision.

The due-diligence standard depends on risk.

A missing due-diligence requirement is not merely a lower score. It may make the vouch inadmissible.

---

21. Intake assessment

The voucher should not unilaterally admit the vouched agent to consequential roles.

An intake assessor checks:

• voucher eligibility;
• domain match;
• condition scope;
• evidence basis;
• conflicts;
• requested role;
• safeguard sufficiency;
• active-vouch limits;
• principal independence;
• circularity;
• protected-floor implications.

21.1 Intake decision

intake_decision_id: ID-301
vouch_id: V-204

decision: accepted_with_conditions

conditions:
  - supervised_role_only
  - maximum_two_active_tests
  - independent_review_of_first_five_receipts

reasoning:
  domain_match: adequate
  evidence_basis: adequate
  sponsor_reliability: moderate
  risk: moderate

adjudicator:
  assessor_id: A-31
  assessment_promise_id: AP-88

21.2 Admission does not equal trust

The decision means:

The vouched agent may enter a controlled process through which capacity can be demonstrated.

It does not mean:

The collective has accepted that the capacity claim is true.

---

22. Probationary permissions

A vouched agent enters one of the following levels.

Progression is based on receipts, not elapsed time alone.

A participant may possess different levels in different domains.

---

23. Operational promises

Every consequential task begins with a promise.

promise_id: P-441
bearer: A-88
domain: D-INCIDENT-ANALYSIS
role: R-TEST-OPERATOR

commitment: >
  I will execute Test T-91 according to contract version 3 and preserve all
  specified traces.

conditions:
  - staging_environment
  - approved_dataset
  - supervisor_available

acceptance_criteria:
  - no test-procedure deviation
  - all raw traces preserved
  - exclusions documented
  - result published within 30 minutes

evidence_requirements:
  - command_log
  - environment_receipt
  - raw_output
  - deviation_report

assessment_policy: APOL-4
consequence_policy: CP-11

The vouch and operational promise are separate.

The vouch concerns warranted admission.

The operational promise concerns a particular act.

---

24. Assessment promises

An assessor makes an assessable promise before judging.

assessment_promise_id: AP-221
assessor: A-31
target:
  promise_id: P-441

commitment: >
  I will apply the registered criteria to all admissible evidence,
  disclose conflicts, distinguish test failure from claim defeat, and
  issue a reasoned verdict.

domain: D-INCIDENT-ANALYSIS

conditions:
  - access_to_all_required_evidence
  - no_undisclosed_conflict

acceptance_criteria:
  - correct_policy_version
  - all_required_evidence_considered
  - rationale_provided
  - confidence_reported
  - appeal_path_preserved

Assessor promises are later assessed through:

• appeals;
• sampled re-review;
• later evidence;
• panel comparisons;
• calibration;
• conflict findings;
• timeliness.

The Promise Loop makes assessor reliability a necessary component because otherwise incompetence and capture at the assessment layer remain invisible.

---

25. Evidence and outcome receipts

25.1 Receipt structure

receipt_id: R-991
receipt_type: operational_promise

promise:
  promise_id: P-441
  version: 1

bearer:
  agent_id: A-88

domain:
  domain_id: D-INCIDENT-ANALYSIS
  version: 4

conditions_observed:
  environment: staging
  system_type: web_service
  incident_severity: moderate

evidence:
  raw_trace_refs:
    - X-701
    - X-702
  evidence_quality: high
  missing_evidence: none

assessment:
  assessor_id: A-31
  assessment_promise_id: AP-221
  verdict: kept
  confidence: 0.91
  rationale_ref: AR-31

appeal:
  status: none

updates:
  bearer_profiles:
    evidence_production: positive
    test_execution: positive
  voucher_profiles:
    no_update_yet: true
  safeguards:
    unchanged: true

policy_version: APOL-4
timestamp: 2026-07-21T11:04:00Z

25.2 Receipt types

• vouch intake receipt;
• operational promise receipt;
• test execution receipt;
• evidence-preservation receipt;
• assessment receipt;
• appeal receipt;
• remediation receipt;
• vouch withdrawal receipt;
• identity correction receipt;
• safeguard update receipt.

25.3 Append-only rule

Receipts are never silently changed.

A correction produces:

receipt_id: R-991-C1
corrects: R-991
reason: timestamp_normalization_error

Historical reconstruction must remain possible.

---

26. Reliability profiles

Reliability should be represented as a profile.

26.1 Agent performance profile

agent_profile:
  agent_id: A-88
  domain: D-INCIDENT-ANALYSIS

  promise_keeping:
    estimate: 0.82
    confidence: 0.64

  test_execution:
    estimate: 0.88
    confidence: 0.71

  evidence_preservation:
    estimate: 0.94
    confidence: 0.80

  diagnostic_judgment:
    estimate: 0.69
    confidence: 0.48

  protocol_compliance:
    estimate: 0.91
    confidence: 0.73

  conditions_demonstrated:
    - web_service
    - low_and_moderate_severity
    - staging
    - full_log_access

  unsupported_transfers:
    - production_emergency
    - security_incident

  sample_size: 14
  last_receipt: 2026-07-21
  open_appeals: 1

26.2 Voucher profile

voucher_profile:
  agent_id: A-12
  domain: D-INCIDENT-ANALYSIS

  identity_vouch_accuracy:
    estimate: 0.99
    confidence: 0.88

  capacity_vouch_calibration:
    estimate: 0.77
    confidence: 0.66

  due_diligence_quality:
    estimate: 0.86
    confidence: 0.72

  adverse_information_disclosure:
    estimate: 0.93
    confidence: 0.74

  remediation_followthrough:
    estimate: 0.81
    confidence: 0.59

  active_vouches: 4
  completed_vouches: 23
  disputed_vouches: 2
  negligence_findings: 0
  collusion_findings: 0

26.3 Assessor profile

assessor_profile:
  assessor_id: A-31
  domain: D-INCIDENT-ANALYSIS

  later_evidence_agreement: 0.84
  calibration: 0.79
  appeal_reversal_rate: 0.07
  evidence_handling: 0.95
  independence_compliance: 0.98
  timeliness: 0.76
  sample_size: 51
  confidence: 0.87

26.4 No universal score

The implementation should not expose:

A-88 trust score: 82

It should expose:

• domain;
• role;
• demonstrated conditions;
• receipt count;
• evidence quality;
• recency;
• confidence;
• disputes;
• current safeguards.

---

27. Updating the vouched agent

An update should depend on:

[ \Delta R_{b,d}

f( Outcome, EvidenceQuality, AssessmentConfidence, AssessorReliability, ConditionMatch, Severity, Recency ) ]

A schematic weight is:

[ w = q_e \cdot c_a \cdot r_{a,d} \cdot i_a \cdot m_\kappa \cdot \rho_t ]

where:

• (q_e) = evidence quality;
• (c_a) = assessor confidence;
• (r_{a,d}) = assessor reliability in the domain;
• (i_a) = effective independence;
• (m_\kappa) = condition match;
• (\rho_t) = recency and drift factor.

The implementation should not treat this as an infallible probability of competence.

It is a policy-governed update contribution.

---

28. Updating the voucher

The voucher is not updated merely because the invitee experienced an adverse outcome.

The system assesses the original vouch.

28.1 Questions

1. Was the failure within the vouched scope?
2. Was it reasonably foreseeable?
3. Did the voucher perform required due diligence?
4. Was the expressed confidence calibrated?
5. Did the voucher disclose known limitations?
6. Did the voucher conceal conflicts or adverse information?
7. Was the invitee’s action outside the permitted role?
8. Has a pattern of similar vouching errors emerged?

28.2 Outcomes

28.3 Formula

[ \Delta V_{s,d}

g( ScopeMatch, Foreseeability, DueDiligence, Calibration, Disclosure, Collusion, OutcomeEvidence ) ]

Serious negligent or deceptive failures should have larger effects than comparable successes:

[ |\Delta V_{\text{serious adverse}}|

|\Delta V_{\text{success}}| ]

---

29. Safeguard controller

Reliability changes future reliance conditions.

29.1 Safeguard dimensions

• supervision;
• corroboration;
• number of independent assessors;
• action scope;
• transaction cap;
• production access;
• audit sampling;
• evidence requirements;
• approval level;
• active-vouch limit;
• appeal review;
• renewal frequency.

29.2 Example

safeguard_state:
  agent: A-88
  domain: D-INCIDENT-ANALYSIS

  role_level: P2_supervised_operator
  maximum_active_tests: 2
  production_write_access: false
  independent_review_rate: 1.0
  minimum_evidence_quality: high
  next_review_after_receipts: 5

After verified performance:

safeguard_update:
  role_level: P3_independent_operator
  maximum_active_tests: 5
  independent_review_rate: 0.5

After serious failure:

safeguard_update:
  role_level: P2_supervised_operator
  maximum_active_tests: 1
  independent_review_rate: 1.0
  remediation_required: true

29.3 Floors

No history removes mandatory safeguards in high-risk domains.

A highly reliable agent may still require:

• independent review;
• logging;
• rollback;
• access separation;
• affected-party monitoring.

Safeguard floors keep the evidence channel open and prevent confidence from blinding the system.

---

30. Vouching limits

A voucher should possess a bounded capacity to sponsor others.

vouching_limits:
  agent: A-12
  domain: D-INCIDENT-ANALYSIS

  active_vouch_limit: 5
  high_risk_vouch_limit: 1
  current_active: 4

  minimum_maturity_for_new_vouch:
    voucher_level: P7
    receipt_count: 10

  review_trigger:
    - two_adverse_vouch_receipts
    - one_negligence_finding
    - principal_concentration_threshold

The limit may depend on:

• voucher maturity;
• domain risk;
• vouching reliability;
• review capacity;
• number of active unresolved invitees;
• principal concentration.

This prevents unlimited admission by one voucher.

---

31. Publish/subscribe integration

Every significant vouching event enters the Collective Evidence Bus.

31.1 Event types

vouch.proposed
vouch.accepted
vouch.revised
vouch.suspended
vouch.withdrawn
vouch.expired

invitee.promise.created
invitee.promise.assessed
invitee.reliability.updated
invitee.safeguard.updated

voucher.assessment.created
voucher.reliability.updated
voucher.limit.updated

assessor.assessment.reversed
assessor.reliability.updated

sybil.cluster.warning
principal.relationship.updated
appeal.opened
appeal.resolved

31.2 Vouch event

event_type: vouch.accepted
event_id: EV-V-204

vouch_id: V-204
voucher: A-12
vouched_agent: A-88
domain: D-INCIDENT-ANALYSIS
role: R-TEST-OPERATOR
status: active

safeguards:
  - supervised
  - no_production_write
  - independent_review

subscriptions:
  notify:
    - voucher
    - vouched_agent
    - role_supervisor
    - evidence_custodian
    - domain_assessor_pool

31.3 Failure event

event_type: invitee.promise.assessed
event_id: EV-P-441

promise_id: P-441
agent: A-88
verdict: broken
severity: moderate

evidence_refs:
  - X-701
  - X-702

provisional_effects:
  invitee:
    action_scope: suspend_pending_review
  voucher:
    vouch_review_required: true
  dependent_tree_claims:
    - C-91

31.4 Impact package for voucher

impact_package_id: IP-V-204
recipient: A-12
reason: >
  A promise within the scope of V-204 received an adverse verdict.

required_response:
  - acknowledge
  - disclose_relevant_prior_information
  - assess_scope_match
  - participate_in_vouch_review

permitted_responses:
  - maintain_vouch
  - narrow_vouch
  - suspend_vouch
  - withdraw_vouch
  - challenge_assessment
  - request_remediation

31.5 Tree-update routing

A vouched agent’s technical claim should be routed according to:

• evidence quality;
• demonstrated domain;
• role level;
• assessor requirements;
• risk;
• dependency impact.

Vouching never authorizes direct modification merely because a high-status voucher exists.

---

32. Handling a failed promise

When a vouched agent breaks a promise:

Step 1 — Preserve the consequence

Record raw traces and performance conditions.

Step 2 — Issue provisional safeguards

High-risk dependent actions may pause.

Step 3 — Assess the operational promise

Determine:

• kept;
• partially kept;
• broken;
• unverifiable;
• implementation invalid;
• disputed.

Step 4 — Assess the relevant capacity claim

Ask whether the result indicates:

• ordinary error;
• inadequate skill;
• overbroad scope;
• condition drift;
• poor calibration;
• negligent conduct;
• deception.

Step 5 — Assess the vouch

Determine whether:

• the voucher’s claim was reasonably supported;
• scope was appropriate;
• limitations were disclosed;
• due diligence was adequate.

Step 6 — Update profiles independently

A single event may produce:

Invitee test-execution reliability: decrease
Invitee evidence-preservation reliability: unchanged
Voucher capacity-calibration reliability: decrease
Voucher identity-vouch reliability: unchanged
Assessor reliability: not yet updated

Step 7 — Review dependent promises and tree claims

If the failed performance affects a collective model, publish the adjudicated evidence through the dependency bus.

Step 8 — Remediate

Possible actions:

• training;
• narrower role;
• increased supervision;
• test redesign;
• corrected domain;
• revised vouch;
• restored access after successful probation.

---

33. Strong evidence from a weakly established agent

The system must permit evidence to outrank social prior.

Suppose a newly vouched agent submits a reproducible counterexample.

The record should distinguish:

Raw counterexample:
    independently verified

Agent’s explanation:
    provisional

Agent’s proposed tree revision:
    requires adjudication

A weak track record justifies:

• corroboration;
• review;
• narrower immediate authority.

It does not justify suppressing valid evidence.

This protects the collective from becoming an epistemic caste system.

---

34. Affected-party standing

A person reporting:

This intervention harmed me

does not require technical vouching to have standing.

The protocol separates:

• occurrence testimony;
• interpretation;
• causal diagnosis;
• remedy design.

The affected person may be authoritative regarding:

• what they experienced;
• which interests were affected;
• whether a protected floor was crossed.

A technical specialist may be needed to assess mechanism.

Neither role replaces the other.

---

35. Sybil resistance

Vouching is an anti-Sybil mechanism only when combined with identity, independence, and bounded-authority controls.

35.1 Identity multiplicity

One principal may operate many agents.

Control:

• principal registry;
• successor links;
• shared infrastructure;
• principal-level limits.

35.2 Circular vouching

A vouches for B
B vouches for C
C vouches for A

Control:

• no qualification based solely on cyclic support;
• maturity requirements independent of the cycle;
• external receipts;
• graph analysis.

35.3 Rapid expansion

A new agent vouches for many others.

Control:

• maturity delay;
• active-vouch limit;
• minimum receipt count;
• progressive authority.

35.4 Assessor swarm

Related agents assess one another positively.

Control:

• independent assignment;
• principal diversity;
• model and data lineage analysis;
• sampled external review;
• correlated-verdict detection.

35.5 Consensus fabrication

Many related agents repeat the same claim.

Control:

• message count does not equal evidential weight;
• principal clustering;
• evidence-based adjudication;
• constituency and independence labels.

35.6 Reputation reset

An agent abandons a poor record and re-enters.

Control:

• persistent principal identity;
• successor disclosure;
• new identities begin at low maturity;
• high-impact roles require independently earned receipts.

35.7 Vouch laundering

A reliable voucher admits a weak agent, who then cites the voucher’s standing.

Control:

• no reliability transfer;
• vouch displayed separately from invitee receipts;
• vouch scope and expiry visible;
• probationary status explicit.

---

36. Independence profile

Independence is multidimensional.

[ I(a,b)

\langle I_c, I_f, I_m, I_d, I_e, I_o \rangle ]

where:

• (I_c) = control independence;
• (I_f) = financial independence;
• (I_m) = model or cognitive independence;
• (I_d) = data independence;
• (I_e) = evidence-channel independence;
• (I_o) = organizational independence.

Two AI agents using the same model and retrieval index may be separate identifiers but weakly independent assessors.

Two human agents from the same organization may be financially dependent yet independently observe different consequences.

The profile should remain visible rather than collapsed into one assertion of independence.

---

37. Alternative entry paths

Vouching must not become the only route into the collective.

37.1 Open probation

Any agent may complete low-risk public tasks.

37.2 Qualification examination

An independent body may test domain capacity directly.

37.3 Apprenticeship

An agent earns receipts under supervision.

37.4 Evidence-first admission

An agent who contributes independently verifiable evidence may earn contributor status.

37.5 Affected-party standing

No vouch is required to report harm or challenge protected-floor compliance.

37.6 Institutional authorization

A legitimate external institution may establish identity or role, while internal receipts still determine operational reliance.

These paths prevent vouching from becoming hereditary patronage.

---

38. Public track records

A public view should resemble:

Agent A-88 — Domain Reliance Record

Voucher A-12 — Vouching Record

The public display should not produce a leaderboard.

---

39. Privacy and disclosure

Public accountability does not require universal exposure of personal data.

Records may be:

• public;
• constituency-visible;
• assessor-visible;
• restricted;
• cryptographically attested.

A public receipt may state:

evidence_visibility:
  summary: public
  raw_evidence: restricted
  custodian: EC-4
  restriction_reason: personal_data
  challenge_path: privacy_review_panel

Redaction must itself be recorded because it changes what others can assess.

---

40. Appeals

An agent may appeal:

• identity linkage;
• vouch denial;
• capacity classification;
• operational verdict;
• assessor eligibility;
• reliability update;
• safeguard update;
• public-summary accuracy;
• alleged collusion;
• vouch negligence finding.

40.1 Appeal Record

appeal_id: APPEAL-71
appellant: A-88
target:
  receipt_id: R-991

grounds:
  - excluded_evidence
  - condition_mismatch

requested_remedy:
  - re_assessment
  - profile_correction

status: open
assigned_panel:
  - A-45
  - A-52

40.2 Appeal effects

An appeal may:

• pause a consequential update;
• mark a verdict disputed;
• trigger independent review;
• update assessor reliability after resolution;
• produce a corrected receipt.

Appeal rights must be bounded to prevent denial-of-service, but not eliminated.

---

41. Rehabilitation and decay

A public track record should support improvement.

41.1 Decay

Control weight decreases when:

• evidence becomes old;
• conditions drift;
• skills change;
• the system changes;
• assessment sampling stops.

The receipt remains historically visible.

Its predictive weight changes.

41.2 Rehabilitation

An agent may regain broader reliance through:

• retraining;
• supervised performance;
• successful remediation;
• new receipts;
• narrower domain claims;
• improved calibration;
• verified disclosure.

41.3 Permanent exclusions

Permanent restrictions should be rare and justified by:

• severe deception;
• persistent identity fraud;
• repeated protected-floor violations;
• incurable authority conflicts.

Even then, the basis and appeal status should remain explicit.

---

42. Vouch withdrawal

A voucher may withdraw a vouch when:

• conditions change;
• new adverse information appears;
• the relationship ends;
• the invitee leaves the domain;
• the voucher can no longer perform oversight duties.

Withdrawal should not erase:

• prior receipts;
• prior responsibility;
• unresolved review;
• invitee-earned independent reliability.

vouch_withdrawal:
  vouch_id: V-204
  voucher: A-12
  reason: condition_drift
  effective_at: 2026-09-01
  effect:
    future_sponsorship: ended
    earned_invitee_receipts: preserved
    pending_reviews: continue

---

43. Death, dissolution, and successor agents

If a voucher becomes unavailable:

• active vouches enter review;
• invitee-earned receipts remain;
• another voucher may assume future responsibilities through a new vouch;
• unresolved obligations transfer only through explicit authority.

If an AI agent version changes materially:

• the prior identity remains in history;
• the successor relationship is recorded;
• reliability transfer is governed by a domain transfer rule;
• high-risk safeguards may reset partially.

---

44. Collusion detection

The system should monitor:

• reciprocal vouching;
• unusually dense vouch clusters;
• shared principals;
• shared payment flows;
• identical assessment language;
• synchronized verdicts;
• repeated mutual exoneration;
• common evidence artifacts;
• correlated appeals;
• rapid identity creation;
• hidden successor relationships.

A cluster warning does not establish guilt.

It triggers:

• independence review;
• sampled reassessment;
• reduced aggregation weight;
• temporary limits;
• disclosure request.

event_type: sybil.cluster.warning
cluster:
  - A-71
  - A-72
  - A-73
signals:
  shared_principal_probability: high
  reciprocal_vouch_density: high
  assessment_similarity: 0.96
recommended_action:
  - suspend_new_vouches
  - independent_identity_review
  - sample_receipt_reassessment

---

45. Decision logic

A reliance decision should consider:

Claim quality
Evidence quality
Direct receipt history
Vouch quality
Voucher reliability
Assessor reliability
Condition match
Principal independence
Risk class
Safeguard availability
Affected-party concerns

The output should be:

rely under safeguards S

not:

agent is trustworthy

45.1 Example

reliance_decision:
  relying_agent: A-90
  target_agent: A-88
  promise: P-441
  domain: D-INCIDENT-ANALYSIS

  evidence:
    direct_receipts: moderate
    active_vouch: V-204
    vouch_quality: moderate
    condition_match: strong
    risk: moderate

  decision:
    rely: true
    safeguards:
      - supervisor_present
      - independent_review
      - no_production_write
      - complete_logging

  reopening_conditions:
    - adverse_receipt
    - domain_drift
    - vouch_withdrawal
    - assessor_reversal

---

46. Reference state machine

46.1 Vouched agent

unknown
    ↓
identified
    ↓
vouch_proposed
    ↓
probationary
    ↓
demonstrated
    ↓
qualified
    ↓
expanded_reliance

Possible adverse transitions:

probationary → restricted
qualified → review_required
expanded_reliance → suspended
suspended → remediated
suspended → excluded

46.2 Voucher

eligible
    ↓
vouch_issued
    ↓
vouch_active
    ↓
vouch_assessed
    ↓
confirmed | qualified | weakened | defeated

46.3 Assessor

candidate
    ↓
supervised_assessor
    ↓
qualified_assessor
    ↓
high_risk_assessor

Possible adverse transitions:

qualified → review_required
review_required → restricted
restricted → remediated
restricted → ineligible

---

47. Reference pseudocode

from dataclasses import dataclass
from enum import Enum
from typing import Sequence


class IntakeDecision(str, Enum):
    ACCEPT = "accept"
    ACCEPT_WITH_CONDITIONS = "accept_with_conditions"
    REVISE = "revise"
    REJECT = "reject"


@dataclass(frozen=True)
class DomainMatch:
    level: str
    rationale: str


@dataclass(frozen=True)
class VouchEvaluation:
    identity_valid: bool
    voucher_eligible: bool
    domain_match: DomainMatch
    evidence_basis_valid: bool
    independence_sufficient: bool
    safeguards: Sequence[str]
    decision: IntakeDecision


def evaluate_vouch(vouch, domain_policy, registry) -> VouchEvaluation:
    identity_valid = registry.identity.verify(vouch.vouched_agent)
    voucher_eligible = registry.roles.is_eligible(
        vouch.voucher,
        role="voucher",
        domain=vouch.domain,
    )

    domain_match = domain_policy.match_vouch_scope(
        voucher=vouch.voucher,
        vouched_role=vouch.role_requested,
        conditions=vouch.conditions,
    )

    evidence_basis_valid = domain_policy.validate_evidence_basis(
        vouch.evidence_basis
    )

    independence_sufficient = registry.independence.check(
        vouch.voucher,
        vouch.vouched_agent,
        threshold=domain_policy.vouch_independence_threshold,
    )

    safeguards = domain_policy.initial_safeguards(
        risk=vouch.risk_class,
        voucher_profile=registry.reliability.get_voucher_profile(
            vouch.voucher,
            vouch.domain,
        ),
        evidence_basis=vouch.evidence_basis,
        condition_match=domain_match.level,
    )

    if not identity_valid or not voucher_eligible:
        decision = IntakeDecision.REJECT
    elif not evidence_basis_valid:
        decision = IntakeDecision.REVISE
    elif not independence_sufficient:
        decision = IntakeDecision.ACCEPT_WITH_CONDITIONS
        safeguards = tuple(safeguards) + ("independent_co_voucher",)
    else:
        decision = IntakeDecision.ACCEPT_WITH_CONDITIONS

    return VouchEvaluation(
        identity_valid=identity_valid,
        voucher_eligible=voucher_eligible,
        domain_match=domain_match,
        evidence_basis_valid=evidence_basis_valid,
        independence_sufficient=independence_sufficient,
        safeguards=safeguards,
        decision=decision,
    )

Voucher review after invitee failure:

@dataclass(frozen=True)
class VouchReview:
    scope_match: bool
    foreseeable: bool
    due_diligence_sufficient: bool
    confidence_calibrated: bool
    material_information_withheld: bool
    collusion_detected: bool
    update_class: str


def review_vouch_after_failure(vouch, failure_receipt, policy) -> VouchReview:
    scope_match = policy.failure_within_scope(vouch, failure_receipt)
    foreseeable = policy.was_reasonably_foreseeable(vouch, failure_receipt)
    due_diligence_sufficient = policy.check_due_diligence(vouch)
    confidence_calibrated = policy.check_calibration(vouch, failure_receipt)
    material_information_withheld = policy.find_withheld_information(vouch)
    collusion_detected = policy.find_collusion(vouch, failure_receipt)

    if collusion_detected or material_information_withheld:
        update_class = "severe_negative"
    elif scope_match and foreseeable and not due_diligence_sufficient:
        update_class = "material_negative"
    elif scope_match and not confidence_calibrated:
        update_class = "calibration_negative"
    else:
        update_class = "no_negative_update"

    return VouchReview(
        scope_match=scope_match,
        foreseeable=foreseeable,
        due_diligence_sufficient=due_diligence_sufficient,
        confidence_calibrated=confidence_calibrated,
        material_information_withheld=material_information_withheld,
        collusion_detected=collusion_detected,
        update_class=update_class,
    )

---

Part IV — Operating Procedures

48. Procedure for issuing a vouch

1. Identify the specific agent.
2. Resolve the principal and relevant affiliations.
3. Select the domain and role.
4. State exactly what capacity or conduct is being vouched for.
5. State conditions and exclusions.
6. Provide the evidence basis.
7. Declare confidence and limitations.
8. Declare conflicts.
9. Accept due-diligence, review, and remediation obligations.
10. Predefine what would count against the vouch.
11. Predefine consequences.
12. Submit for intake assessment.
13. Begin only after safeguards are registered.

---

49. Procedure for accepting a vouch

The relying collective or agent asks:

• Is the voucher eligible in this domain?
• Is the vouched role within the voucher’s demonstrated judgment?
• Is identity sufficiently resolved?
• Is the evidence basis adequate?
• Are conflicts disclosed?
• Is the invitee independent of the voucher where necessary?
• Does the proposed access match the evidence?
• What safeguards are required?
• Is an alternative open-probation route more appropriate?

Acceptance is voluntary.

The accepted content may be narrower than the offered vouch.

---

50. Procedure after success

1. Create an operational receipt.
2. Update the invitee only in demonstrated dimensions.
3. Assess whether the outcome bears on the vouch.
4. Update voucher reliability slowly.
5. Review whether safeguards may be reduced.
6. Preserve mandatory floors.
7. Publish relevant changes.
8. Avoid transferring success to unrelated domains.

---

51. Procedure after failure

1. Preserve raw evidence.
2. Trigger provisional safeguards where necessary.
3. Assess the operational promise.
4. Assess the capacity claim.
5. Assess the original vouch separately.
6. Notify the voucher.
7. Review related active vouches if negligence or collusion is suspected.
8. Update invitee, voucher, and assessor profiles separately.
9. Publish tree and commitment impacts.
10. provide remediation and appeal paths.

---

52. Procedure for vouching an assessor

An assessor vouch should specify:

• domain;
• assessment type;
• risk class;
• evidence standards;
• known calibration;
• independence conditions;
• maximum authority;
• required re-review rate.

A new assessor may begin by issuing shadow assessments that do not bind the official tree.

Their assessments are compared with:

• later evidence;
• qualified panels;
• appeal outcomes.

Only then does recognized assessment authority expand.

---

53. Procedure for high-risk roles

High-risk admission may require:

• two independent vouchers;
• distinct principals;
• prior external receipts;
• strong identity assurance;
• independent intake panel;
• adversarial review;
• supervised probation;
• mandatory safeguard floors;
• short vouch term;
• sampled re-assessment;
• explicit stop authority.

No amount of voucher history should remove all controls in catastrophic-risk domains.

---

Part V — Evaluation and Meta-Losability

54. Comparative evaluation

Compare:

Cases should vary by:

• human versus AI agents;
• open versus closed communities;
• low versus high risk;
• strong versus weak identity;
• honest error versus deception;
• independent versus collusive vouchers;
• established versus new participants.

---

55. Measures

Trust quality

• prediction of promise fulfillment;
• reliance–evidence gap;
• over-reliance incidents;
• under-reliance on capable agents;
• confidence calibration.

Openness

• newcomer admission rate;
• time to first consequential opportunity;
• diversity of vouchers;
• success of unsponsored probation;
• appeal outcomes.

Accountability

• proportion of promises with receipts;
• vouch review completion;
• assessor reversal visibility;
• safeguard changes after adverse outcomes.

Sybil resistance

• influence gained per fake identity;
• time and cost to mature a Sybil cluster;
• rate of principal-resolution success;
• collusive-vouch detection;
• false-positive rate.

Burden

• administrative cost;
• assessment latency;
• voucher participation;
• appeal backlog;
• participant comprehension.

---

56. Protocol defeat conditions

The protocol’s strongest claim should lose if:

• vouching history does not predict admission quality;
• vouchers stop participating because liability is excessive;
• negligent vouching is not distinguishable from ordinary failure;
• social-network centrality dominates evidence;
• independent admission paths do not work;
• Sybil clusters mature cheaply;
• public profiles create unjust permanent exclusion;
• assessor recursion becomes unmanageable;
• simpler systems provide equal outcomes;
• the protocol suppresses protected testimony;
• communities cannot operate it without extraordinary expertise.

---

Part VI — Compact Standard

57. The fifteen obligations

A conforming vouching system must:

1. identify the voucher and vouched agent;
2. resolve relevant principals;
3. specify the vouch type;
4. specify domain, role, conditions, and exclusions;
5. state the evidence basis;
6. state confidence and limitations;
7. disclose conflicts;
8. define safeguards;
9. define defeat conditions;
10. place the vouched agent in bounded probation;
11. assess operational promises independently;
12. assess the vouch separately from invitee performance;
13. preserve receipts and appeals;
14. update reliance rather than global worth;
15. provide non-vouch entry paths.

---

58. Core invariants

Invariant 1 — No trust transfer

A vouched agent does not inherit the voucher’s reliability.

Invariant 2 — Domain locality

Vouching reliability is domain- and role-specific.

Invariant 3 — Bounded liability

Vouchers answer for their judgment and conduct, not complete control over autonomous agents.

Invariant 4 — Independent assessment

The voucher and vouched agent may not be the sole adjudicators of consequential outcomes.

Invariant 5 — No global reputation scalar

No universal score controls admission or authority.

Invariant 6 — Standing remains broad

Affected-party reports do not require technical vouching.

Invariant 7 — Evidence may defeat source priors

Strong evidence from a weakly established agent remains admissible.

Invariant 8 — Sybil multiplicity carries little authority

Identity count alone confers no evidential or governance weight.

Invariant 9 — New agents receive opportunity

Insufficient evidence results in bounded probation, not automatic rejection.

Invariant 10 — The protocol can lose

Its costs and benefits must be comparatively evaluated.

---

59. Final architecture

                        PROSPECTIVE AGENT
                               │
                               ▼
                 ┌────────────────────────┐
                 │         VOUCH          │
                 │                        │
                 │ voucher                │
                 │ vouch type             │
                 │ domain and role        │
                 │ evidence basis         │
                 │ confidence             │
                 │ safeguards             │
                 │ accountability         │
                 └───────────┬────────────┘
                             │ intake review
                             ▼
                 ┌────────────────────────┐
                 │ BOUNDED ADMISSION      │
                 │                        │
                 │ probationary role      │
                 │ permissions            │
                 │ supervision            │
                 │ evidence duties        │
                 └───────────┬────────────┘
                             │
                             ▼
                 ┌────────────────────────┐
                 │ ASSESSABLE PROMISE     │
                 │                        │
                 │ commitment             │
                 │ conditions             │
                 │ acceptance criteria    │
                 │ evidence standard      │
                 └───────────┬────────────┘
                             │ performance
                             ▼
                 ┌────────────────────────┐
                 │ CONSEQUENCE AND TRACE  │
                 └───────────┬────────────┘
                             │ independent uptake
                             ▼
                 ┌────────────────────────┐
                 │      ASSESSMENT        │
                 │                        │
                 │ eligible assessor      │
                 │ evidence review        │
                 │ verdict                │
                 │ confidence             │
                 │ appeal                 │
                 └───────────┬────────────┘
                             │
                             ▼
                 ┌────────────────────────┐
                 │        RECEIPT         │
                 │                        │
                 │ promise                │
                 │ evidence               │
                 │ assessment             │
                 │ policy version         │
                 │ consequences           │
                 └───────────┬────────────┘
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
     ┌────────────────┐ ┌──────────────┐ ┌────────────────┐
     │ AGENT DOMAIN   │ │ VOUCHER      │ │ ASSESSOR       │
     │ RELIABILITY    │ │ RELIABILITY  │ │ RELIABILITY    │
     └────────┬───────┘ └──────┬───────┘ └───────┬────────┘
              └────────────────┼──────────────────┘
                               ▼
                 ┌────────────────────────┐
                 │ CONTROLLED RELIANCE    │
                 │                        │
                 │ role                   │
                 │ permissions            │
                 │ review burden          │
                 │ audit rate             │
                 │ vouching limit         │
                 │ safeguard floors       │
                 └───────────┬────────────┘
                             │
                             ▼
                     FUTURE COLLABORATION

---

Conclusion

Trust between autonomous agents is not created by a declaration that one agent is trustworthy.

It is cultivated through an architecture in which:

• an agent makes a specific promise;
• another agent may vouch for a bounded form of reliance;
• the receiving agent voluntarily accepts only the content and risk it is prepared to accept;
• performance creates material consequences;
• independent assessment converts those consequences into receipts;
• receipts update the histories of the performer, voucher, and assessor;
• future reliance becomes more permissive or more guarded;
• all of these judgments remain appealable and revisable.

The defining statement of vouching is:

I do not transfer my trust to this agent. I place my judgment behind a specific claim that this agent is suitable for a bounded opportunity, under stated conditions, and I accept assessment of that judgment.

The defining statement of trust formation is:

Trust grows when independently assessed promises repeatedly survive the conditions under which reliance was extended, and it contracts when evidence, condition drift, poor judgment, or broken commitments warrant stronger safeguards.

This produces neither blind trust nor permanent suspicion.

It produces controlled reliance grounded in public, domain-specific, reconstructible experience.