Trust Infrastructure

The Sources of Traditional Trust#

In traditional organizations, trust mostly comes from five sources:

• title;
• brand;
• relationships;
• tenure;
• shared work history.

These sources share a common feature: they are all attached to a stable organizational container. A person is trusted, more often than not, not because they have been verified, but because of the position they hold, the company they belong to, and the time both sides have accumulated together. Here, trust is a structural byproduct.

In dynamic networks of OPCs and Agents, all five sources are weakened at once. Collaboration is temporary, boundaries are fluid, participants may never share a room, and the party executing the work may not even be human. There is no time for shared work history to accumulate, titles are no longer stable, and brands may not exist at all.

As a result, trust needs to become more verifiable.

Trust Is Not Just a Score#

Trust is: the verifiable probability that a given Actor will fulfill a given type of commitment, in a given Context.

This definition contains three necessary qualifiers; drop any one of them and it degrades into a score.

First, Context. Trust is not a global property. The same Actor's reliability can differ completely across different markets, different scales, and different risk levels. A trust score detached from Context is a meaningless average.

Second, a given type of commitment. Trust is type-specific. Delivering on time, judging accurately, keeping confidences, and absorbing losses are four different kinds of commitment that must be verified separately — they cannot be collapsed into a single number.

Third, verifiable probability. Trust is not an impression; it is an estimate that can be traced back to evidence. It should be able to answer "what is this based on," not just "what is the score."

Scoring systems fall short precisely because they flatten all three qualifiers: they compress multiple Contexts into one scenario, multiple types of commitment into one dimension, and evidence into one number. A score is a summary of trust, not the infrastructure of trust.

What Trust Infrastructure Might Include#

A future Trust Infrastructure might include:

• identity authenticity;
• capability records;
• task-completion evidence;
• decision and revision history;
• client reviews;
• contribution records;
• commitment fulfillment rate;
• risk events;
• Agent provenance and version;
• human approval records.

Of these ten items, two are specific to AI-native environments. Agent provenance and version means that when execution is carried out by an Agent, the question of "who did this" must be traceable down to the model's provenance and version — otherwise attribution is impossible and the work cannot be reproduced. Human approval records answer a different question: where in the chain a human intervened, what they approved, and what they are therefore accountable for. Without this record, an organization in which every action is carried out by an Agent would have no one who genuinely owns the outcome.

The remaining items are not a flat list either — they are types of evidence organized around different objects of verification.

Five Categories of Verifiable Objects#

Grouping the items above by their object of verification yields five categories:

Identity     → Identity authenticity, Agent provenance and version
Capability   → Capability records, domain and market applicability conditions
Commitment   → Commitment fulfillment rate, response reliability, human approval records
Contribution → Contribution records, decision and revision history
Outcome      → Task-completion evidence, client reviews, risk events

Identity: verifies "who this is." Participants are verified real people or entities; Agents are execution units tagged with provenance and version. The identity layer is the precondition for the other four — without confirming the subject, no other record can be attributed to anyone.

Capability: verifies "what can be done." Not abstract skill tags, but "who can do what, in which market, under what conditions." The value of a capability graph lies in its conditional qualifiers — a person's capability in one market cannot be assumed to transfer to another.

Commitment: verifies "what was said." The commitment fulfillment rate matters more than outcomes themselves because it measures the stable relationship between expectation and reality. An Actor who consistently delivers on smaller commitments is more dependable than one who occasionally delivers excellent results but whose expectations are uncontrollable.

Contribution: verifies "what was actually done." In multi-party collaboration, contribution may come from proposing the Goal, introducing relationships, committing capital, professional judgment, execution, or bearing risk. Contribution records require these distinctions to be logged explicitly, rather than retroactively re-narrated at the time outcomes are divided up.

Outcome: verifies "what happened." This includes completion evidence and external reviews, as well as risk events. A system that records only successes and never risk events produces not trust but propaganda.

Together, these five categories form the verifiable surface of trust: identity accounts for the subject, capability for potential, commitment for expectation, contribution for process, and outcome for fact. No single category on its own is sufficient to support trust.

Why OPCs Must Build Their Own Trust#

Large companies borrow trust from scale, offices, brands, and headcount. An OPC must build trust a different way.

Possible trust signals include:

• verified identity;
• clear domain focus;
• public thinking;
• case studies;
• delivered Evidence;
• transparent methodology;
• a robust partner network;
• professional contracts;
• response reliability;
• data security;
• client referrals;
• visible Responsibility.

These twelve items map onto the five categories above. Verified identity corresponds to Identity; clear domain focus, public thinking, and transparent methodology correspond to Capability; professional contracts, response reliability, and data security correspond to Commitment; visible Responsibility corresponds to Contribution; and case studies, delivered Evidence, client referrals, and the partner network correspond to Outcome.

The difference lies in where the burden of proof sits. Trust in a large company is granted by default and must be disproven; trust in an OPC is absent by default and must be established. This means every one of an OPC's signals must be actively produced — thinking done in public, methods left behind, citable delivery evidence accumulated over time.

Trust is very likely the single most important bottleneck to OPC adoption — not a capability bottleneck, not a tooling bottleneck, and not a pricing bottleneck. An OPC may possess every capability needed to complete a task and still fail to win it, simply because the other party cannot verify that capability.

Two Ways Trust Fails#

Trust fails in two forms that point in opposite directions but converge on the same gap.

Trust opacity: the client has no way of knowing who produced the result, what data was used, or which model was called. The deliverable itself carries none of this information, and AI-generated language of high surface quality further conceals facts of low underlying quality. This is a problem specific to AI-native delivery — in the past, quality could be inferred from "who did it"; that inferential chain is now broken.

Trust deficit: the client does not believe an extremely small organization can deliver. This has nothing to do with actual capability — it is a prior judgment carried by scale itself.

The shared gap behind both is verifiability. Trust opacity means delivery exists but cannot be traced; trust deficit means capability exists but cannot be proven. Scoring systems can do nothing about either: they cannot reconstruct the generative chain behind a delivery, nor can they substitute for evidence a small organization has not yet accumulated. The practical purpose of Trust Infrastructure is to fill both gaps with verifiable records.

From Individual Trust to Network Trust#

Even a strong individual OPC remains constrained by distribution, credibility, legal capacity, local relationships, capital, specialized human expertise, and customer access. An alliance structure can supply shared infrastructure without forcing every member back into a traditional company form.

Four of these layers directly constitute Trust Infrastructure:

Identity layer: verified people and entities.

Capability graph: who can do what, in which market, under what conditions.

Trust graph: track record, referrals, commitments, and outcomes.

Contribution ledger: records who contributed the Goal, relationships, capital, expertise, execution, and risk.

The order of these four layers is not arbitrary. Identity is the precondition for capability, capability is an input dimension of the trust graph, and the contribution ledger is the evidentiary source that lets the trust graph update. Without a contribution ledger, the trust graph can only record outcomes — it cannot distinguish who made the outcome happen.

Relationship to Reputation Portability#

Trust Infrastructure and the question of "whether reputation can be ported" are two sides of the same question.

Traditional reputation is hard to port precisely because it is stored inside a container — in a company's internal evaluations, a platform's rating system, the private memory of a shared work history. Leave the container, and the reputation resets to zero. This is exactly why people tend to stay inside organizations: not because the organization is more efficient, but because the cost of leaving includes having one's reputation wiped out.

If trust is constituted by five categories of verifiable objects, and those objects attach to identity rather than to a container, then reputation is in principle portable. A person's capability records, commitment fulfillment rate, contribution history, and outcome evidence can persist across specific working relationships. This portable form can be called a trust passport — the key is not a score, but a set of evidence a person carries with them.

Corresponding product directions also include contribution graphs, evidence-and-decision ledgers, and dynamic collaboration contracts. These remain objects of research, not finished products.

But this is only a possibility in principle. Portable reputation requires cross-platform verification standards, mechanisms to prevent manipulation, and a way of handling time decay — evidence of delivery from five years ago should not be weighted the same as evidence from last month. None of these questions has a mature answer yet.

Questions Still Unanswered#

1. Can trust in the AI era be computed?
2. How does reputation port across platforms?
3. How is an Agent's contribution priced?
4. What economic rights should the person who proposes the Goal receive?
5. How should returns be divided among relationships, judgment, capital, and execution?
6. How will business models change once AI capability approaches free?
7. Will AI platforms turn around and compete for high-value Goals themselves?
8. Will future capital invest in companies, individuals, Goals, or Agent Networks?