Ardyn Trust Profile

The Question

A single AEA tells you what one principal did at one moment. But institutions making consequential decisions about autonomous systems need to answer a different question: given everything this principal has done — across hours, days, or months — should we trust it now?

The Ardyn Trust Profile answers: what is the durable, evidence-backed trust posture of this principal, derived from a longitudinal record of verifiable actions, not a snapshot?

The Concept

An ATP (Ardyn Trust Profile) is a machine-readable aggregation of verified evidence that describes a principal's trust posture over time. ATPs are not limited to AI agents — they apply to any principal type: humans, machines, services, organizations, and suppliers. It is not a reputation score, not a single number, and not a subjective rating. It is structured evidence — a computed view over many AEAs, decisions, and outcomes that an organization can apply its own policy to.

An ATP answers questions like:

• How many actions has this principal executed, and what fraction passed verification?
• Has this principal ever been escalated or blocked by governance?
• What hardware platforms has this principal's workload been attested on?
• Has this principal's authority been revoked or modified?
• Is this principal's behavior consistent with its historical pattern?

The ATP is policy-consumable — a governance engine can read it and render a decision — but it is not a decision itself. Two different organizations may look at the same ATP and reach different conclusions because they apply different risk policies.

Why Existing Approaches Are Insufficient

Agent reputation scores. Several platforms offer numeric scores for AI agents. These scores are opaque — the methodology is proprietary, the evidence is invisible, and the score cannot be re-derived. A score of 87 tells you nothing about what the agent actually did.

Point-in-time compliance checks. An auditor checks a configuration once per quarter. The agent may have been compliant at 10:00 AM and misbehaving by 10:15 AM. Point-in-time checks cannot answer longitudinal questions.

Manual review. A human reads logs and forms a subjective opinion. This does not scale to hundreds of agents executing thousands of actions. It also cannot be automated into a pre-execution authorization path.

The ATP replaces all three with a computational primitive: aggregate the verifiable evidence, render it in machine-readable form, and let organizational policy decide what it means.

The Mechanism

An ATP is constructed through a pipeline:

1. Collection. AEAs flow into the system through attestation, governance, and operations paths. Each AEA is independently verifiable — its signature and content digest can be checked without trusting the collector.

2. Aggregation. The ATP engine groups AEAs by principal identity and computes statistical aggregates: action counts, pass rates, escalation frequency, hardware attestation tiers, and governance decisions received.

3. Structuring. The aggregates are assembled into a structured profile with fields like:

4. Consumption. A governance engine (Axiom) reads the ATP and evaluates it against organizational policy. The same ATP fed into a high-risk financial policy may produce ESCALATE while a low-risk development policy produces ALLOW.

┌──────────────────────────────────────────────────────┐
│                Ardyn Trust Profile                    │
├──────────────────────────────────────────────────────┤
│  principal_id:        principal-7a3b                 │
│  principal_type:      Agent                          │
│  actions_total:       14,203                         │
│  actions_verified:    14,198                         │
│  verification_pass_rate: 99.96%                      │
│  escalation_count:    2                              │
│  block_count:         0                              │
│  hardware_tiers:      { hardware_attested: 98%,       │
│                         transport_attested: 2% }      │
│  authority_grants:    [pay_invoice, read_ledger]      │
│  last_escalation:     2026-07-14T09:22:00Z            │
│  evidence_chain_root: sha256:f8e7d6...                │
└──────────────────────────────────────────────────────┘

A Concrete Example

An insurance firm has 40 autonomous agents processing claims. Each agent produces AEAs for every action — reading policy documents, assessing damage photos, calculating payouts, issuing payments.

Operational question: agent claims-12 has processed 3,400 claims this quarter with a 99.8% verification rate, but was escalated twice in the last 30 days for payment amounts exceeding $50,000.

The firm's underwriting policy reads:

• If verification_pass_rate < 99% → BLOCK
• If escalation_count >= 3 in trailing 30 days → BLOCK
• If escalation_count >= 1 AND verification_pass_rate < 99.5% → ESCALATE

Agent claims-12 has 99.8% pass rate and 2 escalations. Policy evaluates: no block conditions met, no escalate condition met. Result: ALLOW.

The same ATP, different policy. A different firm with a more conservative policy that says "any escalation in trailing 30 days → ESCALATE" would see the same ATP and reach a different conclusion. The trust profile is the same. The policy is what differs.

What the Layer Does Not Do

The ATP layer does not:

• Render a trust decision. An ATP is input to a decision, not a decision itself. It provides structured evidence for a governance engine to evaluate.
• Assign a reputation score. There is no "trust score" in an ATP. It contains factual aggregates — counts, rates, tiers — not a composite number.
• Make moral or ethical judgments. An ATP records what happened and how often. It does not classify behavior as good or bad.
• Predict future behavior. An ATP is backward-looking — it describes what the agent has done, not what it will do.
• Replace human judgment. ATP provides the evidence base for human decision-makers. It does not remove the need for human oversight in high-stakes contexts.

How It Relates to Other Layers

Upstream (sources of trust evidence):

• AEA — Every individual action produces an AEA. ATPs are aggregations of AEAs.
• Forge — Authority grants, delegations, and quorum decisions recorded in governance AEAs feed into the ATP's authority state.
• Axiom — Governance decisions (ALLOW, BLOCK, ESCALATE) are recorded in the ATP to build the agent's governance history.

Downstream (consumers of trust profiles):

• Axiom — Reads ATPs during policy evaluation to determine whether an agent's historical behavior merits the requested action.
• AAECP — Uses ATPs in the pre-execution authorization path to gate autonomous execution.
• ACTA — Consumes ATPs as structured input for organizational cognition and operational memory.

Lateral: Verification — The verification engine validates individual AEAs. ATP only aggregates verified AEAs. Unverifiable artifacts are excluded or flagged.

Verification

A relying party can verify an ATP without trusting the aggregator:

1. Evidence traceability. Every count and rate in the ATP is backed by an enumerated set of AEA IDs. The verifier can request the underlying AEAs and verify each one independently — signature, content digest, chain position.

2. Aggregate correctness. The verifier can recompute the ATP from the raw AEAs: count actions, verify pass rates, confirm hardware tiers, and cross-check the evidence chain root. If the ATP's claims do not match the raw evidence, the ATP is invalid.

3. Chain root integrity. The ATP's evidence_chain_root is a Merkle root computed over all of the principal's AEAs. A verifier can confirm that every AEA included in the ATP is represented in that root — and that no AEA has been omitted or inserted.

The verification principle is the same as for individual AEAs: trust the bytes, not the server.

Implementation Status

The Trust Profile Engine is defined in the canonical architecture as an internal capability of Ardyn Core. The aggregation primitives — principal-level pass rates, verification statistics, governance history queries — are partially operational through existing endpoints. The ATP as a formal, machine-readable, policy-consumable data structure is defined but not yet deployed as a standalone profile artifact. Implementation is expected to follow the completion of the AEA envelope migration (FORGE-11).

Continue Learning

Each layer builds on the one before it. Follow the architecture: