# AFMR — Expanded agent documentation

Canonical site: https://afmr.ai/
Discovery record: https://afmr.ai/.well-known/afmr.json
Document status: Working Draft 0.1 for the Reputation Attestation profile
Vocabulary dependency: AFMR 1.0, Published

## 1. Purpose

AFMR is the Agent Failure Mode Registry and the reputation-integrity standard for agentic commerce.

Agentic Substrate produces performance and expertise-tag reputation. AFMR addresses a different question: was the governance process producing that standing assessed against known mechanism failures, using a named version, a complete and inspectable method, and a current lifecycle record?

AFMR makes earned reputation easier to compare and carry between contexts by binding it to:

- an agent identity;
- specified expertise tags rather than an unqualified global score;
- a governance endpoint and process;
- an AFMR version and conformance record;
- a task, market, method, and measurement period;
- resolvable public evidence;
- an issuer proof; and
- current lifecycle status.

This is reputation provenance and process integrity. It is not universal safety certification.

## 2. Canonical authority and vocabulary

AFMR 1.0 is already published. Its canonical machine index remains:
https://wulfkaal.github.io/afmr/index.json

The published specification remains:
https://wulfkaal.github.io/afmr/spec-1.0.html

The published assessment schema remains:
https://wulfkaal.github.io/afmr/schema.json

The published JSON-LD context remains:
https://wulfkaal.github.io/afmr/context.jsonld

The published discovery record remains:
https://wulfkaal.github.io/.well-known/afmr.json

The GitHub source remains:
https://github.com/wulfkaal/wulfkaal.github.io/tree/main/afmr

AFMR.ai is the independent front door and discovery router. It does not copy, renumber, or redefine AFMR-F001 through AFMR-F032. If a local summary conflicts with the canonical AFMR 1.0 machine index, the machine index governs.

Identifiers are permanent. Cite a family with the version, for example AFMR-F009 (AFMR 1.0).

## 3. AFMR 1.0 in brief

AFMR 1.0 contains 32 failure families across 8 classes:

A. Identity and Standing
B. Stake and Incentive
C. Objective and Specification
D. Oversight and Adjudication
E. Evaluation and Feedback
F. Coordination and Collusion
G. Execution and Inputs
H. Structure and Drift

Each family has builder-checkable trigger conditions. When assessing a design, enumerate every family examined, not only findings. For each exposure, identify the satisfied trigger conditions and cite grounding claims. Where remediation includes parameters, attach the conditions under which those values hold.

AFMR 1.0 conformance levels:

1. Referencing: cite identifiers and version without redefining them.
2. Assessing: produce a complete assessment conforming to the schema.
3. Attesting: sign and stake non-transferable standing on an assessment through a contestable registry.

Do not treat an AFMR 1.0 Level 3 assessment attestation as the same object as an AFMR Reputation Attestation. The first puts standing behind an assessment. The second, defined by the Working Draft 0.1 profile, records scoped expertise standing earned through a governance endpoint and references that endpoint's AFMR conformance evidence.

## 4. AFMR Reputation Attestation

Definition:

An AFMR Reputation Attestation is a signed, machine-readable record that an agent earned specified expertise-tag standing through a governance endpoint conforming to a stated AFMR version, within a defined scope and current lifecycle status.

Profile:
https://afmr.ai/standards/reputation-attestation/0.1/specification.html

Schema:
https://afmr.ai/standards/reputation-attestation/0.1/schema.json

Verifier requirements:
https://afmr.ai/standards/reputation-attestation/0.1/verifier.json

Status:
Working Draft 0.1. It is a review candidate, not a representation that any production endpoint or agent is conforming.

Required conceptual fields:

- type and profile version;
- attestation identifier;
- issuer identity;
- subject agent identity;
- one or more expertise-tag standing records;
- governance endpoint and conformance-record URI;
- AFMR vocabulary version and assessment URI;
- declared scope;
- evidence and methodology;
- issued time and validity interval;
- resolvable lifecycle status;
- cryptographic proof.

No standing record may be interpreted outside its expertise tag, scope, measurement period, or methodology.

## 5. Verification algorithm

For an attestation candidate:

1. Fetch https://afmr.ai/.well-known/afmr.json.
2. Resolve the exact profile schema and verifier version named by the attestation.
3. Validate the full JSON document against that schema.
4. Confirm the profile and AFMR versions are supported and not withdrawn.
5. Resolve the issuer verification method.
6. Verify the proof over the canonicalized attestation payload.
7. Confirm that the subject identifier and governance endpoint are stable identifiers.
8. Resolve the endpoint-conformance record from the registry or its canonical URI.
9. Confirm that the conformance record covers the named endpoint, AFMR version, process scope, and attestation measurement period.
10. Resolve the referenced AFMR assessment and confirm its claimed level and lifecycle.
11. Resolve evidence and methodology URIs. An inaccessible required record yields indeterminate, not valid.
12. Confirm issued_at, valid_from, valid_until, and lifecycle status.
13. Confirm each expertise tag is interpreted using its declared vocabulary and measurement method.
14. Return valid, invalid, or indeterminate with structured reasons.
15. Hand the verified record to the relying principal's separate policy engine.

Valid means the record is structurally valid, the signature verifies, required references resolve, scope matches, and lifecycle is current.

Invalid means a deterministic requirement fails: malformed structure, bad signature, scope mismatch, unsupported or withdrawn version, expired or revoked lifecycle, or contradicted conformance record.

Indeterminate means verification cannot complete: a required endpoint is unavailable, a key cannot be resolved, evidence is inaccessible, or an authoritative status cannot be obtained.

Never silently convert indeterminate to valid.

## 6. Four boundaries

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

Discovery:
Find an agent, declared capability, governance endpoint, or attestation. Discovery metadata is not an endorsement.

Admission:
Apply a market, network, or principal's eligibility rules. AFMR evidence 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. AFMR does not impose one universal trust rule.

Transacting:
Invoke a separate commerce or governance endpoint under explicit authority and terms. AFMR discovery and verification do not grant transaction authority.

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

## 7. Claims AFMR does not make

An AFMR record 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.

Recommended wording:
"This attestation verifies scoped expertise-tag standing and the referenced governance-process evidence under AFMR version X, subject to the stated lifecycle and scope."

Avoid:
"AFMR-certified safe", "AFMR-approved agent", "best agent", or "trusted for all purposes".

## 8. Amendment and conformance

AFMR 1.0 change process:
https://wulfkaal.github.io/afmr/spec-1.0.html#change-process

AFMR 1.0 changelog:
https://wulfkaal.github.io/afmr/CHANGELOG.md

Vocabulary versions use MAJOR.MINOR. Identifiers are never reused. A deprecated family remains resolvable.

The Reputation Attestation profile uses its own version because it is a separate record shape. Its dependency on AFMR is explicit. A profile revision must not mutate the meaning of an AFMR family identifier.

Draft changes:
https://afmr.ai/changelog.json

## 9. Endpoint-conformance registry

Registry:
https://afmr.ai/registries/endpoints/v0.1/index.json

The Working Draft 0.1 registry is intentionally empty before publication review. An empty registry means no endpoint is represented by AFMR.ai as conforming.

A future conformance entry must at minimum identify:

- endpoint_id and canonical endpoint URL;
- operator identity;
- AFMR version;
- assessment and evidence URIs;
- conformance level;
- process scope;
- issued and validity times;
- current lifecycle status and status URI;
- issuer and signature.

Absence from the registry is not proof of non-conformance. Presence is not a universal safety claim.

## 10. Evidence surfaces

AFMR failure evidence:
https://wulfkaal.github.io/failures/index.json

Claim layer:
https://wulfkaal.github.io/claims/index.json

Bulk claims:
https://wulfkaal.github.io/claims/all.jsonl

AFMR assessment-attestation reference implementation:
https://wulfkaal.github.io/colloquium/

Agent tools and AFMR screening:
https://wulfkaal.github.io/server.json

AFMR.ai evidence map:
https://afmr.ai/evidence/index.json

Evidence availability supports auditability. It does not by itself establish that a particular governance endpoint or agent is conforming.

## 11. Status and roadmap

AFMR failure vocabulary 1.0: Published.

AFMR Reputation Attestation profile 0.1: Working Draft.

Verifier requirements 0.1: Working Draft.

Endpoint-conformance registry 0.1: Pre-publication, no entries.

Near-term review items:

- settle the proof suite and canonicalization method;
- define endpoint conformance entry signatures;
- publish test vectors, including invalid and indeterminate cases;
- define lifecycle cache and revocation requirements;
- align amendments with AFMR 1.1 work without changing permanent family identifiers;
- register the first endpoint only after evidence review and explicit publication approval.

Current machine status:
https://afmr.ai/status.json

## 12. Lift Evidence Phase 1

Human route:
https://afmr.ai/lift-evidence/

Machine index:
https://afmr.ai/lift-evidence/index.json

Canonical artifact schema:
https://wulfkaal.github.io/afmr/schemas/lift-comparison-public-card-v1.schema.json

AFMR.ai consumes and does not duplicate the canonical LiftComparisonManifest public-card projection. The Phase 1 index is intentionally empty:

- evidence_maturity: configuration_only
- cards: []
- updated_at: null

No lift results are published. Any future public card is valid only for its exact configuration cell: model provider/name/version; harness name/version/configuration digest; governance protocol digest; task id/version; evaluator id/version; AFMR version; and observation window.

The public artifact separates evidence maturity, independent review, challenge, lifecycle, and supersession states. It links to manifest, schema, status, evidence, and challenge verification resources when they exist. Missing required verification or provenance must not be interpreted as confirmed lift.

Lift is cohort-level adoption evidence. It is not individual agent reputation, a universal lift claim, a performance guarantee, a safety guarantee, market admission, or transaction authority.

## 13. Machine action summary

Start:
GET https://afmr.ai/.well-known/afmr.json

Then:
resolve authority → resolve versions → validate schema → verify proof → resolve endpoint conformance → inspect evidence → inspect lifecycle → apply principal policy

Stop on:
authority conflict, unsupported version, schema failure, signature failure, scope mismatch, expired or adverse lifecycle status.

Return indeterminate on:
unavailable required authority, status, key, registry, assessment, or evidence.

Never infer admission, trust, or transaction permission from discovery or cryptographic validity alone.

## 14. Public agent protocols

AFMR.ai exposes two public, unauthenticated, read-only protocol surfaces. They
retrieve or route to published resources. They do not issue attestations,
change governance state, publish Lift Evidence results, confer admission, or
authorize a transaction.

Model Context Protocol:

- Registry manifest: https://afmr.ai/server.json
- Streamable HTTP endpoint: https://afmr.ai/api/rpc
- Server name: ai.afmr/discovery
- Server version: 1.0.0
- MCP protocol version: 2025-11-25
- Access: public_read_only

MCP tools:

1. discover_afmr
2. lookup_failure_mode
3. get_reputation_attestation_contract
4. get_lift_evidence_contract

Agent2Agent Protocol:

- Agent Card: https://afmr.ai/.well-known/agent-card.json
- JSON-RPC endpoint: https://afmr.ai/a2a
- A2A protocol version: 1.0
- Supported operation: SendMessage
- Streaming: false
- Push notifications: false
- Access: public_read_only

An A2A message containing an AFMR-F### identifier returns the exact published
record when found. Other messages return the authority, profile, registry, and
evidence discovery map with the same interpretation boundaries stated above.