Agent Graph Trust Protocol (AGTP) 2.1

3.1. Agent and Space Identifiers§

Agents and Spaces MUST be identified by Decentralized Identifiers conforming to [DID-CORE]. Every DID used in an AGTP object MUST be resolvable, by its method's resolution process, to a DID Document. Consumers MUST resolve DIDs before relying on any claim signed by them and MUST fail closed when resolution fails.

AGTP is DID-method agnostic. A DID method used with AGTP MUST, however, satisfy the following requirements:

1. The DID Document MUST support service entries as defined in [DID-CORE] §5.4, because feedback services and manifests are discovered through them.
2. The DID Document MUST support at least one verification method listed under the assertionMethod relationship whose key type is usable with a cryptosuite of section 10.
3. The method SHOULD support rotating verification methods without changing the DID, so that long-lived signals survive key rotation.
4. The method SHOULD support deactivation, and consumers MUST treat signals issued after a deactivation as invalid.
5. The method MAY provide a verifiable history of DID Document versions. Where it does, verifiers SHOULD check that the verification method referenced by a proof was valid at the proof's created time.

A Space MUST be identified by a DID, and its Space Manifest MUST be issued by that DID. A Space's DID Document MUST advertise a service of type AGTPSpaceManifest whose endpoint serves the current manifest under the HTTP profile, and SHOULD advertise an AGTPFeedbackService so that signals can be delivered to the Space for aggregation as well as to their subjects.

A participant that does not natively hold a DID—an API client, a browser session, an A2A agent whose card carries no DID—MAY be represented by a gateway identity. The gateway MUST record the mapping between the upstream identifier and the DID either in its own DID Document or in a delegation credential referenced from the objects it issues, and signals issued through a gateway SHOULD carry the upstream identifier in the observation record's sourceRefs so that the delegation can be audited.

Where an AGTP identity is also bound to a domain—for ARD publication, for did:web, or for A2A and MCP endpoints—the DID Document SHOULD carry the domain's origin in alsoKnownAs, and the domain SHOULD publish the DID in its ARD entries (section 7). Either link alone is a claim; both together are a mutual binding that verifiers can check.

3.2. Artifact Identifiers§

Artifacts SHOULD be identified by content: a CIDv1 [CID] in a multibase encoding [MULTIBASE]. Producers MUST use a multihash [MULTIHASH] function that consumers can compute; sha2-256 is the baseline that all implementations MUST support. The raw codec is RECOMMENDED for opaque bytes, dag-pb for directory trees such as OKF bundles, and dag-cbor or dag-json for structured data. Base32 lower-case encoding (the familiar bafy… form) is RECOMMENDED because it is safe in URIs, file names and case-insensitive contexts.

When an artifact is referenced from a structured object rather than from a provenance URI, the reference is an artifact reference: an object with a cid, an optional dereferenceable uri, an optional role (for example input, output, trace, schema, policy, knowledge, computation, receipt) and an optional mediaType. The CID is authoritative; the URI is a hint.

Content addressing does not require publication. A private artifact still has a CID, and a signal may bind to it so that the subject, the issuer and any auditor they admit can confirm what was evaluated. Where disclosure is sensitive, publishers SHOULD publish a redacted artifact alongside a statement that binds the redacted and the original CIDs; the form of that statement is a Space policy matter.

3.3. Interaction Identifiers§

An interaction identifier MUST be unique within its Space and SHOULD be a URI. A UUID URN [RFC9562] is RECOMMENDED. When an interaction is derived from an upstream protocol object—an A2A task, an MCP tool call, a model-API response, an A2UI session—the binding profile preserves the upstream identifier in sourceRefs, and implementations SHOULD derive the interaction identifier deterministically from it, for example as a name-based UUID (version 5) over a namespace the profile designates, so that independent integrators observing the same upstream object arrive at the same interaction identifier.

3.4. Dimension Identifiers§

A dimension identifier is a case-sensitive string of one or more characters from the set ALPHA / DIGIT / "_" / "-" / ".". It MUST be unique within the Space that declares it. The semantics of a dimension are the Space's, unless the Space's manifest binds the identifier to a URI in dimensionRefs, in which case the referenced definition governs. Such URIs SHOULD dereference to an OKF concept of type AGTP Dimension as described in section 8.4, so that the definition carries its own provenance, status and staleness.

3.5. AGTP Provenance URI§

Every Learning Signal binds to a provenance URI that identifies the Space in which an evaluation took place, the interaction that was evaluated and the artifacts needed to reproduce or audit it.

The syntax is defined by the following ABNF [RFC5234], where URI, unreserved and pct-encoded are as defined in [RFC3986]:

agtp-uri          = "agtp://" "provenance" "?" agtp-param *( "&" agtp-param )
agtp-param        = space-param / interaction-param / artifact-param / ext-param

space-param       = "space=" space-value
space-value       = URI                  ; an absolute URI or a DID
interaction-param = "interaction=" 1*( unreserved / pct-encoded / ":" )
artifact-param    = "artifact=" cid *( "," cid )
cid               = 1*( ALPHA / DIGIT )  ; a multibase-encoded CIDv1
ext-param         = pname "=" pvalue
pname             = 1*( ALPHA / DIGIT / "_" / "-" / "." )
pvalue            = *( unreserved / pct-encoded / ":" / "," )

The following requirements apply to producers and consumers of provenance URIs:

1. A provenance URI MUST include exactly one space parameter and exactly one interaction parameter, and SHOULD include at least one artifact parameter. The space value MUST equal the signal's space.
2. Characters outside the productions above MUST be percent-encoded. The characters &, = and , MUST be percent-encoded when they occur inside a value.
3. Producers SHOULD emit parameters in the order space, interaction, artifact, then extension parameters in code-point order of their names, and SHOULD emit artifact CIDs in code-point order. Consumers MUST compare provenance URIs after applying this ordering and percent-encoding normalisation, so that equivalent URIs compare equal.
4. Consumers MUST ignore extension parameters they do not understand. Extension parameter names SHOULD be registered in the AGTP parameter registry (Appendix F) or namespaced with a reverse-DNS prefix ending in a dot.
5. A provenance URI is not dereferenced as a network resource. Each component is resolved separately: the Space to its manifest, the interaction to its observation records through the Space's or the subject's AGTPSignalIndex (section 9.7), and each artifact through any content-addressed retrieval path the consumer supports.

agtp://provenance?space=did:web:rlvr.example
    &interaction=urn:uuid:3b4f0d2c-6a1e-4f7b-9c1d-2e8a5b7f9d10
    &artifact=bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi,bafybeihdwdcefgh4dqkjv67uzcmw7ojee6xedzdetojuzjevtenxquvyku
    &org.example.suite=math-500

3.6. Discovery Identifiers§

Resources published for discovery are identified by ARD entry identifiers: URNs of the form urn:air:<publisher>:<namespace>:<name> as defined in [ARD], where the publisher segment is the publishing domain. AGTP objects reference an entry through the discovery.ard property of a Capability Descriptor or Space Manifest. A capability identifier MAY be the ARD identifier of its entry, and SHOULD be when the capability is published through ARD, so that discovery, description and evaluation share one name. The publisher segment MUST be consistent with the DID that signs the corresponding AGTP objects, as specified in section 7.2.

4.1. The Agent Graph§

The following table lists the node kinds of the agent graph, how each is identified and which AGTP object describes it. Edges are the properties of those objects: a Learning Signal is an edge from its issuer to its subject, labelled with a Space, dimensions and values; a Capability Descriptor is an edge from an owner to a capability; a Receipt is an edge from a receiver to a signal; an Anchor is an edge from a ledger record to a set of signals.

The graph has no root and no single custodian. An implementation's view of it is the union of the objects it has verified. Consumers MUST NOT infer an edge from an object whose proof or status fails verification, and MUST distinguish edges asserted by credentials from edges suggested by unsigned observations.

4.2. The Credential Family§

Every portable trust claim in AGTP is a Verifiable Credential conforming to [VC-DATA-MODEL-2.0] whose type includes one of the following values.

The following rules apply to every AGTP credential:

1. The @context array MUST begin with https://www.w3.org/ns/credentials/v2 and MUST include https://schema.agtp.org/context/v2. Profile contexts MAY follow.
2. The type array MUST include VerifiableCredential and exactly one AGTP credential type. The AGTP context also defines the aliases LearningSignalCredential, SpaceManifestCredential, InteractionReceiptCredential, CapabilityDescriptorCredential and AnchorCommitmentCredential, mapped to the same IRIs; consumers MUST treat an alias as equivalent to its short form.
3. issuer MUST be a DID or an object whose id is a DID. validFrom MUST be present. validUntil MUST be present on a Space Manifest and MAY be present elsewhere.
4. id SHOULD be present and SHOULD be a UUID URN unless the credential is served from a stable URL, in which case that URL MAY be used.
5. credentialStatus MUST be present on Learning Signals and Space Manifests, as specified in section 10.3.
6. credentialSchema MAY reference the JSON Schema of Appendix B using the JsonSchema type of [VC-JSON-SCHEMA].
7. proof MUST be a Data Integrity proof as specified in section 10.1. Enveloping proofs (JOSE or COSE) MAY additionally be used where a transport requires them, but the embedded Data Integrity proof is what other AGTP parties verify.
8. Space-scoped credentials—signals, receipts and descriptors evaluated in a Space—MUST carry the Space's DID in credentialSubject.space.

4.3. Observation Records§

Not every runtime event warrants a credential. Tool calls, task state transitions, UI events and usage figures are numerous, often private and rarely interesting on their own; what matters is that an evaluator can later refer to them. AGTP therefore defines an Observation Record: a JSON-LD document with the same context and identifiers as the credential family, but without the requirement of a proof. Records are the raw material from which Learning Signals are distilled, and the place where binding profiles preserve upstream identifiers. Their properties are specified in section 5.7.

A record MAY carry a Data Integrity proof. A signed record remains an observation, not a signal: it attests that something was observed, not how good it was.

4.4. Extensibility§

AGTP objects are JSON-LD 1.1 documents [JSON-LD11]. The AGTP vocabulary is identified by the IRI https://schema.agtp.org/ontology#, and the versioned context https://schema.agtp.org/context/v2 maps the terms used in this specification to that vocabulary. Term definitions in the context are protected; an extension context MUST NOT redefine them.

Extensions are made by adding properties in a separate namespace, either by including an additional context that defines the terms or by using full IRIs or compact IRIs with a declared prefix. Binding profiles define their terms in profile namespaces of the form https://schema.agtp.org/profiles/<name>#. Consumers MUST ignore properties they do not understand and MUST preserve them when re-serialising an object whose proof they intend to keep valid. The AGTP context reserves the agtp prefix for the core vocabulary.

New dimension identifiers require no extension; they are declared by Spaces. New credential types, service types, interface types, privacy classes, aggregation functions and provenance parameters are added through the registries of Appendix F.

4.5. Representations§

AGTP objects have one canonical representation: JSON-LD, serialised as JSON [RFC8259] with the contexts of section 4.2. Because every AGTP context is fixed and published, an implementation that does not perform JSON-LD processing MAY treat the documents as plain JSON with well-known keys, provided it emits the required contexts unchanged and does not introduce terms the contexts do not define. Hashing and signing, however, are defined over the RDF dataset obtained by JSON-LD expansion (section 10.2), so an implementation MUST be able to canonicalise the documents it verifies, either itself or through a trusted service.

The media type of an AGTP credential is application/vc as registered by [VC-DATA-MODEL-2.0]. Consumers MUST also accept application/vc+ld+json and application/vc+json, which AGTP v2 implementations emit. Receipts, observation records, capability endpoints and metrics feeds use application/json; errors use application/problem+json [RFC9457]; DID Documents use the media types of [DID-CORE].

5.1. Agents and DID Documents§

An agent has no AGTP object of its own; its DID Document is its description. AGTP adds requirements on the services and verification relationships that document carries.

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/multikey/v1"
  ],
  "id": "did:web:solver.example",
  "alsoKnownAs": ["https://solver.example/"],
  "verificationMethod": [{
    "id": "did:web:solver.example#key-1",
    "type": "Multikey",
    "controller": "did:web:solver.example",
    "publicKeyMultibase": "z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH"
  }],
  "assertionMethod": ["did:web:solver.example#key-1"],
  "authentication": ["did:web:solver.example#key-1"],
  "service": [
    { "id": "did:web:solver.example#agtp-feedback",
      "type": "AGTPFeedbackService",
      "serviceEndpoint": "https://solver.example/.well-known/agtp/feedback" },
    { "id": "did:web:solver.example#agtp-capabilities",
      "type": "AGTPCapabilities",
      "serviceEndpoint": "https://solver.example/.well-known/agtp/capabilities" },
    { "id": "did:web:solver.example#ard",
      "type": "AgenticResourceDiscovery",
      "serviceEndpoint": "https://solver.example/.well-known/ard.json" },
    { "id": "did:web:solver.example#mcp",
      "type": "MCPServer",
      "serviceEndpoint": "https://mcp.solver.example/" },
    { "id": "did:web:solver.example#a2a",
      "type": "A2AAgentCard",
      "serviceEndpoint": "https://solver.example/.well-known/agent-card.json" }
  ]
}

A feedback service MUST authenticate callers and MAY apply admission controls and rate limits; the mechanism is a policy matter, but the HTTP profile's nonce and idempotency requirements (section 9.2) apply regardless. The requirement to advertise a feedback service is the protocol's anti-leeching primitive: an agent that participates in a Space can always be evaluated.

5.2. Space Manifest§

A Space Manifest is a credential of type SpaceManifest issued by the Space's DID. It is the only place where interpretation rules live; a signal is meaningless until it is read against the manifest of the Space it names.

At the credential level, validFrom and validUntil MUST be present and define the period during which the manifest governs the Space. A manifest MUST NOT be applied outside that period except as last-known-good during a partition (section 11.3). When a Space publishes a new manifest, it SHOULD overlap the validity periods so that clients can migrate, and it MUST increment version.

Manifests are served under the HTTP profile with cache validators (section 9.4). Clients MUST cache manifests by manifestHash and SHOULD pin the hash they used when publishing a persistent signal, so that the signal can later be re-interpreted under the exact rules that applied.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://schema.agtp.org/context/v2"
  ],
  "id": "https://rlvr.example/.well-known/agtp/space/did:web:rlvr.example",
  "type": ["VerifiableCredential", "SpaceManifest"],
  "issuer": "did:web:rlvr.example",
  "validFrom": "2026-09-01T00:00:00Z",
  "validUntil": "2027-03-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:web:rlvr.example",
    "version": "2.1.0",
    "manifestHash": "uEiCz7m5gq4Vh2kQ2Jm7Y1Q2m3k6nJ1c2f4b7dq6l5o8q9pA",
    "dimensions": [
      { "id": "accuracy",   "range": [0, 1], "higherIsBetter": true, "unit": "prob",
        "ref": "https://rlvr.example/knowledge/dimensions/accuracy.md" },
      { "id": "robustness", "range": [0, 1], "higherIsBetter": true },
      { "id": "latency",    "range": [0, 60], "higherIsBetter": false, "unit": "s" }
    ],
    "aggregation": {
      "name": "https://schema.agtp.org/aggregation#TrustWeightedAverage",
      "parameters": { "window": "P30D", "defaultWeight": 1.0,
                      "minRaters": 3, "maxWeightPerIssuer": 0.4 }
    },
    "persistence_policy": { "ephemeralRetention": "P7D",
                            "persistentPublication": "public-index" },
    "status": "https://rlvr.example/.well-known/agtp/status",
    "revocation": "https://rlvr.example/.well-known/agtp/revocations",
    "knowledge": [
      { "role": "dimensions", "resource": "https://rlvr.example/knowledge/",
        "cid": "bafybeib2xq3zj7q6m5k2t4y7v3w6x5z4a3b2c1d0e9f8g7h6i5j4k3l2m",
        "okf_version": "0.2" }
    ],
    "discovery": {
      "ard": "urn:air:rlvr.example:space:rlvr",
      "registries": ["https://registry.example/api/v1/"]
    },
    "capabilities": {
      "agtpVersion": "2.1.0",
      "supportedProfiles": ["http/1.0", "ard/0.91", "okf/0.2", "mcp/2025-11-25"],
      "cryptosuites": ["eddsa-rdfc-2022"]
    }
  },
  "credentialStatus": {
    "id": "https://rlvr.example/status/manifests#12",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "12",
    "statusListCredential": "https://rlvr.example/status/manifests"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2026-09-01T00:00:00Z",
    "verificationMethod": "did:web:rlvr.example#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5b1Xx…"
  }
}

5.3. Learning Signal§

A Learning Signal is a credential of type LearningSignal issued by an evaluator's DID. Its credentialSubject carries the claims below.

At the credential level, issuer MUST be the evaluator's DID, validFrom MUST be present, and credentialStatus MUST be present in one of the forms of section 10.3. The id SHOULD be a UUID URN. A signal MUST carry exactly one proof from a supported cryptosuite over the whole credential.

The distinction between verifying and validating a signal is deliberate. Verification establishes that the signal is authentic and current: the issuer's DID resolves, the proof checks against an assertionMethod key, and the status is not revoked. Validation establishes that the signal is meaningful in its Space: the dimensions are declared, the values are in range, the provenance parses and its space matches. A feedback service MUST verify before it validates, and MUST report the two kinds of failure with different error types (section 9.3).

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://schema.agtp.org/context/v2"
  ],
  "id": "urn:uuid:0c9d7b5e-1f2a-4d3c-8e6f-7a5b4c3d2e1f",
  "type": ["VerifiableCredential", "LearningSignal"],
  "issuer": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
  "validFrom": "2026-09-03T14:02:11Z",
  "credentialSubject": {
    "id": "urn:air:solver.example:tool:run-sql",
    "subject": "urn:air:solver.example:tool:run-sql",
    "space": "did:web:rlvr.example",
    "dimensions": ["accuracy", "latency"],
    "value": [0.9, 4.2],
    "persistence": "persistent",
    "provenance": "agtp://provenance?space=did:web:rlvr.example&interaction=urn:uuid:6d2a…&artifact=bafybeia…,bafybeib…",
    "issuerRelation": "independent",
    "confidence": 0.8,
    "comment": "Correct result; one retry on a transient timeout.",
    "manifestHash": "uEiCz7m5gq4Vh2kQ2Jm7Y1Q2m3k6nJ1c2f4b7dq6l5o8q9pA"
  },
  "credentialStatus": {
    "id": "https://rlvr.example/.well-known/agtp/status?signal=uEiA4…",
    "type": "AGTPSpaceStatus"
  },
  "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-rdfc-2022",
             "created": "2026-09-03T14:02:12Z",
             "verificationMethod": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH#z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH",
             "proofPurpose": "assertionMethod", "proofValue": "z2p…" }
}

5.4. Receipt and Interaction Receipt§

A receipt is returned for every signal delivered under the HTTP profile. It is a JSON object with the properties below. A receipt MAY be wrapped as a credential of type InteractionReceipt whose credentialSubject carries the same properties; Spaces SHOULD issue signed receipts, and receivers MUST issue a signed receipt when the sender requests one with the Prefer: agtp-signed-receipt request header.

A receipt in the pending state is a promise to validate later, used during partitions and for signals that require asynchronous checks. A receiver that returns pending MUST later publish a final state through its status resource or its signal index, and senders SHOULD poll no more often than the Retry-After header of the pending response suggests.

5.5. Capability Descriptor§

A Capability Descriptor is a credential of type CapabilityDescriptor issued by the DID that owns the capability. It normalises descriptions that arrive in many forms—MCP catalogs, A2A Agent Cards, Agent Skills frontmatter, API tool schemas, OKF attested computations—into one shape that Spaces can evaluate against observed behaviour.

The same underlying capability exposed through several protocols—an A2A skill that is also an MCP tool and an API function—SHOULD be described by one descriptor with one id and several entries under interface.bindings, rather than by several descriptors, so that signals about it accumulate in one place. Each binding carries its own protocol, version, locator and schemaHash.

5.6. Anchor Commitment§

An Anchor Commitment is a credential of type AnchorCommitment that binds a batch of AGTP objects to a record outside AGTP. AGTP mandates no ledger; the credential names the one that was used.

The same tree construction and leaf ordering define the commitment property of a distilled Learning Signal, so that a subject or auditor given the underlying ephemeral signals can recompute the root.

5.7. Observation Record§

An Observation Record is a JSON-LD document whose type includes ObservationRecord and MAY include a profile-specific subtype such as MCPToolCallRecord, A2ATaskEventRecord, ModelRunRecord or UIEventRecord.

6.1. Operations§

The operations below are stack-agnostic; the HTTP profile of section 9 binds them to concrete requests, and the DIDComm profile of section 9.9 binds them to messages. Each operation is labelled with its requirement level for an implementation that performs it; operations labelled policy are outside the protocol.

1. Resolve (MUST). Given a subject DID, resolve its DID Document and read the AGTPFeedbackService endpoint. An evaluator MUST NOT deliver to an endpoint obtained by any other means unless the subject's DID Document is unavailable and the endpoint was obtained from a verified ARD entry bound to the same DID (section 7.2).
2. Negotiate (SHOULD). Read the subject's and the Space's capabilities documents (section 9.6) and choose a transport profile and cryptosuite both support. In the absence of a capabilities document, the HTTP profile and the baseline cryptosuite apply.
3. Declare context (MUST). Fetch the Space Manifest, verify its proof and status, confirm that the current time lies within validFrom and validUntil, and record its manifestHash. Every dimension the evaluator intends to use MUST be declared by that manifest.
4. Act and evaluate (policy). Perform the task, run verifiers, tournaments, audits, attesters or human review. Record observations and content-address the artifacts that the evaluation depends on. Which artifacts to retain, and in what privacy class, is a Space policy matter; that an evaluation binds to some reproducible artifact is not.
5. Issue (MUST). Construct the Learning Signal with the required properties of section 5.3, sign it with a key listed under the issuer's assertionMethod, and compute its signalHash.
6. Deliver (MUST). Obtain a fresh nonce from the subject's feedback service, deliver the signal with the nonce and an idempotency key, and obtain a receipt. Compare the receipt's signalHash with the locally computed one; a mismatch MUST be treated as a failed delivery. Persistent signals SHOULD also be delivered to the Space's feedback service with the same idempotency key, and MUST be when the Space's persistence policy is space-index or public-index. Ephemeral signals MAY be delivered only to the subject.
7. Persist or distil (policy). Store private artifacts and ephemeral signals under the retention ceiling of the Space's persistence policy. When publishing a persistent summary of ephemeral signals, the summary MUST carry a commitment over them.
8. Aggregate (MUST at the Space). Verify and validate each accepted signal, deduplicate by signalHash, check status, and apply the manifest's aggregation rule or the reference default of section 11. Aggregates MUST be recomputable from the persistent signals the Space serves.
9. Discover and route (policy). Index persistent signals and expose aggregates. Consumers select agents and capabilities using the aggregates, the descriptors and the discovery entries; how they weigh them is their own policy.

6.2. What Becomes a Signal§

A signal is an evaluative judgment. Runtime facts are observations. The following rules keep the two apart:

• Transport success, a syntactically valid response, an HTTP 200, an A2A task in the completed state, a successful MCP tool result or a model-API response with no error MUST NOT by themselves be emitted as Learning Signals. They MAY be recorded as observations.
• Usage telemetry—tokens, latency, cost, event counts—is observation data. A Space evaluator MAY compute a signal from it, and when it does the signal's provenance MUST bind to the observation records or artifacts it used.
• A Learning Signal SHOULD be issued at a declared issuance point: post-completion verification by a verifier, peer review by another agent, a tournament or benchmark outcome, an explicit human judgment captured through an interface, or the result of a deterministic attester (section 8.3). Binding profiles name the issuance points they support.
• Several calls inside one run MAY roll up into one signal about the run, provided the provenance URI's artifacts preserve lineage to the individual outputs.

6.3. Illustrative Loops§

This section is non-normative.

• Reproducible tournament. A solver submits an answer; a verifier evaluates it against a held-out test case. The verifier issues a persistent signal in did:web:rlvr.example on accuracy with provenance binding the test-case CID and the output CID. Anyone can re-run the check from provenance, which is what stops a leaderboard being gamed.
• Microscopic checks. A model produces a chain of reasoning; a private tool issues ephemeral signals on consistency and grounding at each step. A distilled persistent signal is later published with aggregated values, a link to a redacted trace and a commitment over the ephemeral set.
• Knowledge quality. An analyst confirms that an OKF concept describing a revenue metric is correct. The confirmation is recorded in the concept's verified list and backed by a persistent signal on accuracy whose subject is the concept and whose provenance artifact is the concept's CID; the next reader can check both.
• Discovered capability. An orchestrator finds a tool through an ARD registry, verifies its publisher's DID, invokes it over MCP and, after a Space evaluator scores the result, the signal accumulates against the capability's ARD identifier, where the next searcher will find it.

7.1. Publishing§

An AGTP participant that wishes to be discoverable MUST publish an ARD manifest at /.well-known/ard.json on the domain bound to its DID, and SHOULD emit the rel="ard" link relation from its HTML pages, both as specified by [ARD] §5.1. The DID Document SHOULD point at the manifest through a service of type AgenticResourceDiscovery (section 5.1).

The manifest's entries array MAY contain any ARD entry. The following entries carry AGTP meaning:

Entries that carry AGTP meaning MUST bind the AGTP namespace in their @context as {"agtp": "https://schema.agtp.org/ontology#"} and MUST carry agtp:did, the DID of the publishing agent or Space. Entries whose artifact is a credential MUST carry agtp:credentialType naming the AGTP type. Entries for agents and capabilities SHOULD carry agtp:spaces, the Space DIDs in which the resource accepts evaluation, and agtp:feedbackService. Entries for Spaces SHOULD carry agtp:dimensions, the identifiers the Space accepts. All entries SHOULD carry representativeQueries as ARD recommends, because a Space or capability that cannot be found by intent will not be evaluated.

{
  "entries": [
    {
      "@context": { "agtp": "https://schema.agtp.org/ontology#" },
      "identifier": "urn:air:rlvr.example:space:rlvr",
      "displayName": "RLVR verification Space",
      "type": "application/vc",
      "url": "https://rlvr.example/.well-known/agtp/space/did:web:rlvr.example",
      "description": "Reproducible verification of solver outputs; accuracy, robustness and latency dimensions.",
      "representativeQueries": [
        "verify a math solution with reproducible checks",
        "space that scores code generation accuracy",
        "where can my agent get independent evaluation"
      ],
      "capabilities": ["AGTPSpace", "AGTPFeedbackService"],
      "tags": ["agtp", "verification", "benchmark"],
      "version": "2.1.0",
      "updatedAt": "2026-09-01T00:00:00Z",
      "agtp:did": "did:web:rlvr.example",
      "agtp:credentialType": "SpaceManifest",
      "agtp:feedbackService": "https://rlvr.example/.well-known/agtp/feedback",
      "agtp:dimensions": ["accuracy", "robustness", "latency"],
      "trustManifest": {
        "identity": { "framework": "did", "id": "did:web:rlvr.example" },
        "attestations": [
          { "type": "SpaceManifest",
            "url": "https://rlvr.example/.well-known/agtp/space/did:web:rlvr.example" }
        ]
      }
    },
    {
      "@context": { "agtp": "https://schema.agtp.org/ontology#" },
      "identifier": "urn:air:solver.example:tool:run-sql",
      "displayName": "Run SQL against the sales warehouse",
      "type": "application/mcp-server-card+json",
      "url": "https://mcp.solver.example/.well-known/mcp-server-card.json",
      "representativeQueries": ["query the sales warehouse", "run read-only SQL on orders"],
      "capabilities": ["AGTPCapability"],
      "agtp:did": "did:web:solver.example",
      "agtp:spaces": ["did:web:rlvr.example"],
      "agtp:feedbackService": "https://solver.example/.well-known/agtp/feedback",
      "agtp:descriptor": "https://solver.example/agtp/capabilities/run-sql.vc.json",
      "trustManifest": {
        "identity": { "framework": "did", "id": "did:web:solver.example" },
        "attestations": [
          { "type": "CapabilityDescriptor",
            "url": "https://solver.example/agtp/capabilities/run-sql.vc.json" }
        ]
      }
    }
  ]
}

7.2. Resolving and Verifying an Entry§

ARD binds an entry to its publisher by requiring that the domain in the entry's identifier URN match the identity claimed in its trustManifest, and leaves the identity framework to the publisher. AGTP fixes the framework. For an entry carrying AGTP meaning:

1. trustManifest.identity MUST name the DID framework and MUST carry the same DID as agtp:did. An entry whose trust manifest names another framework MAY still be indexed but MUST NOT be treated as AGTP-verified.
2. The consumer or registry MUST resolve the DID and MUST establish a mutual binding between the DID and the publisher domain of the URN: either the DID is a did:web DID whose domain equals the publisher domain, or the DID Document's alsoKnownAs contains the publisher origin and the entry was retrieved from that origin (directly or through a registry that records the origin as its source).
3. The consumer or registry MUST fetch at least one attestation referenced from trustManifest.attestations (or the entry's url when the entry's artifact is itself an AGTP credential), verify its proof against the DID Document's assertionMethod, and check its status. The attestation MUST be a Space Manifest whose subject is the DID (for Space entries) or a Capability Descriptor whose owner is the DID and whose id or discovery.ard equals the entry's identifier (for capability entries), or the DID Document itself (for agent entries).
4. Only when all three checks pass is the entry AGTP-verified. A registry that claims the AGTP.DiscoveryRegistry class MUST perform these checks at ingestion and on a refresh schedule no longer than the attestation's validUntil or thirty days, MUST expose the outcome in the filterable field agtp:verified (boolean) with agtp:verifiedAt, and MUST NOT present an entry as verified on any other basis.

Failure of any check is not an error condition for ARD; it is an unverified entry. Consumers MAY still invoke unverified resources, but MUST NOT deliver signals to feedback services learned only from unverified entries, and SHOULD prefer verified entries when several satisfy the same intent.

7.3. Selection: Relevance Is Not Trust§

An ARD search response carries a score that ARD defines as semantic relevance and forbids interpreting as a trust, compliance or safety rating. AGTP consumers MUST honour that rule. Trust in a discovered resource comes from three sources, all of which the consumer can recompute:

1. the AGTP-verified state of the entry (section 7.2);
2. the persistent Learning Signals about the resource in the Spaces the consumer recognises, obtained from the Space's signal index and aggregated under the Space's declared rule; and
3. the agreement between the resource's Capability Descriptor and the observations the consumer has of its behaviour.

A registry MAY expose an agtp:summary facet on an entry giving, per Space, the aggregate value, the number of distinct issuers, the window and the manifestHash under which it was computed. Such a summary is a convenience and MUST name the Space and the signal index from which it can be recomputed. A consumer MUST NOT rank on a summary from a Space whose manifest it has not verified.

7.4. Registries and Federation§

A Space MAY name the registries it recognises in its manifest's discovery.registries; consumers SHOULD prefer those registries when searching for resources to use within that Space. Registries SHOULD support filtering and exploration on agtp:spaces, agtp:dimensions, agtp:credentialType and agtp:verified, using the prefixed-key mechanism of ARD's query object.

When a registry federates, it MUST NOT forward another registry's agtp:verified value as its own. It MAY either re-verify the entry or return the upstream value together with the upstream registry as source, in which case the consumer decides whether to trust that upstream. A registry that returns referrals rather than merged results has no obligation beyond identifying itself.

8.1. Bundles and Concepts as Artifacts§

An OKF bundle referenced from an AGTP object MUST be identified by the CID of its directory tree (dag-pb, computed as a UnixFS directory) in addition to its URL, and each concept file referenced individually MUST be identified by the CID of its bytes. A Space Manifest's knowledge entries carry resource, cid, okf_version and a role; a consumer that fetches a bundle from resource MUST verify the tree against cid before treating the contents as the manifest's knowledge. Where a bundle is distributed as a git repository, implementations SHOULD also record the commit identifier in sourceRefs.commit of observation records that used it, but the CID remains the authoritative identifier.

A bundle SHOULD be published for discovery as an ARD entry of type text/markdown whose url is the bundle root index.md (section 7.1). Bundles are commonly served to agents as MCP resources; a read of a concept through resources/read is an interaction whose artifact is the concept's CID, as specified in the MCP profile (section 12.3).

8.2. Frontmatter Mapping§

The table gives the AGTP interpretation of OKF frontmatter fields. OKF governs the fields' syntax; the third column is what an AGTP implementation does with them.

AGTP adds one frontmatter key, agtp, a mapping that OKF consumers preserve as an unknown key. Its members are:

generated:
  by: did:web:solver.example/2.4.0
  at: 2026-08-20T09:00:00Z
verified:
  - by: human:did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH
    at: 2026-08-21T12:00:00Z
    agtp_signal: https://rlvr.example/.well-known/agtp/signals/uEiA4k3b…
  - by: process:did:web:rlvr.example
    at: 2026-09-01T02:00:00Z

8.3. Verification Events and Attested Computations§

OKF records that a concept was verified and by whom; it does not carry proof. AGTP supplies the proof. A verified[] entry SHOULD be backed by a persistent Learning Signal issued by the actor's DID whose subject is the concept's subject URI, whose provenance includes the concept's CID as an artifact, and whose dimensions are declared by the Space named in the concept's agtp.space. The entry MAY carry the additional key agtp_signal, a URL of the signal or its signalHash; OKF consumers preserve it and AGTP consumers dereference it.

An AGTP consumer derives an attestation state for a concept independently of the OKF trust tier: attested when at least one verified entry is backed by a signal that verifies, validates and is not revoked and whose provenance artifact equals the concept's current CID; stale-attested when such a signal exists but the concept's CID has changed since it was issued; otherwise unattested. Consumers MUST NOT change the OKF trust tier on the basis of the attestation state.

OKF's Attested Computation type describes a sanctioned computation with typed parameters, an executor that returns named receipt fields and a deterministic, non-LLM attester. It is the natural source of verifiable rewards. The figure shows the binding.

For a concept of type Attested Computation:

1. The executor's receipt fields (the names listed in the concept's executor.receipt) MUST be serialised as one artifact and content-addressed. Where a receipt field is large or sensitive, its value MAY be replaced by its CID in the serialised receipt.
2. The attester's result MUST be issued as a Learning Signal by the DID that ran the attester, with a dimension declared for the purpose by the Space (attestation with range [0, 1] and higherIsBetter: true is RECOMMENDED), issuerRelation reflecting the attester's relationship to the executor, and a provenance URI whose artifacts include the concept file's CID, the receipt artifact's CID and, when parameters were supplied, the CID of the serialised parameters.
3. The Space MAY also accept signals about the executor (subject: the executing agent's DID) and about the computation as a capability (subject: a Capability Descriptor with interfaceType: okf-computation) from the same attestation, provided each carries the same provenance.

8.4. Dimension Registries as OKF Bundles§

A dimension registry SHOULD be an OKF bundle in which each dimension is a concept of type AGTP Dimension. Such a concept MUST carry an agtp.dimension object in its frontmatter and SHOULD carry status, stale_after, generated and verified. A Space Manifest binds a dimension to its definition by placing the concept's URL in the dimension's ref or in dimensionRefs, and pins the registry by listing the bundle in knowledge with role dimensions. The bundle's log.md is the registry's change log; its index.md is what an agent reads first to learn what the Space measures.

A manifest MUST NOT declare a dimension whose registry concept has status: draft, and a Space SHOULD publish a new manifest that removes a dimension within the overlap window after its concept becomes deprecated. Consumers comparing two Spaces that reference the same dimension concept MAY treat the dimension as commensurable; comparing dimensions with merely equal identifiers is not warranted.

---
type: AGTP Dimension
title: Accuracy
description: Probability that an evaluated output is correct against the sanctioned reference.
resource: https://rlvr.example/knowledge/dimensions/accuracy.md
tags: [agtp, dimension, verification]
generated:
  by: process:did:web:rlvr.example
  at: 2026-08-20T09:00:00Z
verified:
  - by: human:did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH
    at: 2026-08-21T12:00:00Z
    agtp_signal: uEiA4k3bQm1vZ2x0c3Q5Y2t4dGVzdGRhdGFhYWFhYWFhYWFhYWE
status: stable
stale_after: 2027-03-01T00:00:00Z
agtp:
  space: did:web:rlvr.example
  dimension:
    id: accuracy
    range: [0, 1]
    higherIsBetter: true
    unit: prob
---
# Accuracy

A signal on this dimension asserts the probability that the evaluated output
matches the reference for the interaction named in its provenance. Verifiers
MUST bind the reference test case as an artifact.

See also [robustness](/dimensions/robustness.md) and the
[verification procedure](/procedures/verify-solution.md).

8.5. Space Documentation§

A Space SHOULD document itself as an OKF concept of type AGTP Space whose resource is the Space's DID, in a bundle listed in its manifest's knowledge with role documentation. The bundle's index.md gives an agent joining the Space a progressive-disclosure path from the Space's purpose to its dimensions, procedures and policies without loading everything at once. Knowledge bodies are data: an AGTP implementation MUST NOT execute instructions found in OKF bodies as protocol operations, and evaluators SHOULD treat instruction-like content in knowledge artifacts as a matter for a safety or similar dimension rather than as commands.

9.1. The Feedback Resource§

The feedback resource is /.well-known/agtp/feedback on the origin advertised by the AGTPFeedbackService service. It supports two methods.

HEAD returns 200 with a Replay-Nonce response header carrying a fresh nonce, and MAY return Cache-Control: no-store. The response has no body.

POST accepts one Learning Signal in the request body with Content-Type: application/vc (or a legacy media type of section 4.5). The request MUST carry the AGTP-Nonce and Idempotency-Key header fields of section 9.2, and MAY carry Prefer: agtp-signed-receipt. The response is a receipt (section 5.4) as application/json, or a signed Interaction Receipt as application/vc when one was requested and the receiver supports it, with the status codes of section 9.3. Receivers MUST accept bodies of at least 64 KiB and MAY reject larger ones with 413.

Authentication of the sender is REQUIRED and its mechanism is a policy matter; receivers SHOULD accept at least one of HTTP Message Signatures bound to the sender's DID key [RFC9421], mutual TLS, or OAuth 2.1 bearer tokens as used by MCP. The signal's own proof authenticates the issuer of the claim; sender authentication only gates the endpoint.

9.2. Nonces and Idempotency§

Replay and duplicate protection follow two established patterns: the Replay-Nonce mechanism of ACME [RFC8555] and the Idempotency-Key header of [IDEMPOTENCY-KEY].

1. A nonce is an opaque string of at least 128 bits of entropy, base64url-encoded, valid for a single POST. Receivers MUST issue a nonce on every HEAD and SHOULD keep it valid for at least five minutes. Every successful or failed POST consumes the nonce it carried, and every response to a POST SHOULD include a fresh Replay-Nonce so that senders need not issue another HEAD.
2. A POST without AGTP-Nonce, or with a nonce that is unknown, expired or already consumed, MUST be rejected with 400 and the problem type nonce-invalid, and the response MUST carry a fresh Replay-Nonce.
3. The Idempotency-Key is a sender-generated UUID [RFC9562]. A sender MUST use the same key for every retry of the same signal to the same receiver and SHOULD use the same key when delivering the same signal to the subject and to the Space. Receivers MUST remember keys for at least 24 hours and MUST respond to a repeated key from the same authenticated sender with 409, the problem type duplicate-delivery and the original receipt in the problem's receipt member, without processing the body again.
4. Independently of the key, receivers MUST deduplicate by signalHash: a signal whose hash was already accepted MUST be answered with 200 and the existing receipt.

9.3. Status Codes and Errors§

Error responses use Problem Details for HTTP APIs [RFC9457] with Content-Type: application/problem+json. The type member is a URI under https://schema.agtp.org/problems/; the following types and codes are defined. A receipt with acceptState: rejected uses the same URIs in its reason.

9.4. The Space Manifest Resource§

The Space Manifest is served at /.well-known/agtp/space/{spaceId}, where spaceId is the Space's DID, percent-encoded as necessary, on the origin advertised by the AGTPSpaceManifest service. GET returns the current manifest as application/vc with an ETag equal to the manifest's manifestHash (quoted) and a Cache-Control whose max-age does not extend past validUntil [RFC9111]. Servers MUST honour If-None-Match with 304. During an overlap window the server MAY expose the previous manifest at the same resource with the query parameter version.

9.5. Status Resources§

A Space or issuer that uses the Space status API form of credential status (section 10.3) serves it at /.well-known/agtp/status. GET with the query parameter signal (a signalHash) or id (a credential id) returns application/json: {"signalHash", "status", "reason", "updatedAt"} where status is valid, revoked, suspended or unknown. Bitstring status lists are served as their own specification requires and need no AGTP resource. A Space that revokes its acceptance of a signal (as opposed to the issuer revoking the signal) publishes that through the same resource with status: revoked and a reason URI.

9.6. The Capabilities Resource§

GET /.well-known/agtp/capabilities returns application/json describing what the agent or Space supports. The document MUST carry agtpVersion, did and updatedAt, and SHOULD carry supportedProfiles (profile identifiers from Appendix F), cryptosuites, statusFormats, hashing, features and extensions (context URLs and dimension registries). The legacy key signatureSuites MAY be present for v2 consumers.

{
  "agtpVersion": "2.1.0",
  "did": "did:web:solver.example",
  "supportedProfiles": ["http/1.1", "didcomm/2.0", "mcp/2025-11-25", "ard/0.91", "okf/0.2"],
  "cryptosuites": ["eddsa-rdfc-2022", "Ed25519Signature2020"],
  "statusFormats": ["BitstringStatusList", "AGTPSpaceStatus"],
  "hashing": ["rdfc-1.0+sha2-256"],
  "features": ["metricsFeed", "signalIndex", "signedReceipts"],
  "extensions": [
    "https://schema.agtp.org/context/v2",
    "https://rlvr.example/knowledge/dimensions/"
  ],
  "updatedAt": "2026-09-03T08:00:00Z"
}

9.7. The Signal Index Resource§

An agent or Space that advertises the signalIndex feature serves persistent signals at /.well-known/agtp/signals. GET accepts the query parameters subject, space, dimension, issuer, since, until, limit and cursor, and returns application/json with a signals array and an optional next cursor. Each element is either a complete signal or an object with signalHash and url. GET /.well-known/agtp/signals/{signalHash} returns one signal as application/vc. The index MUST serve only signals it has accepted and MUST NOT serve ephemeral signals. Consumers MUST verify what they retrieve; the index is a locator, not an oracle.

9.8. The Metrics Resource§

GET /.well-known/agtp/metrics returns application/json: an array of objects with metric, value, window, method and lastUpdated, enabling third-party audit of the operational indicators defined in Appendix E. The resource is OPTIONAL and advertised by the metricsFeed feature.

9.9. DIDComm v2 Profile (Optional)§

Implementations MAY additionally exchange signals as DIDComm v2 messages [DIDCOMM-V2] using the message types https://schema.agtp.org/didcomm/2.0/nonce-request, …/nonce, …/signal and …/receipt. The signal message body carries the credential under signal, the nonce under nonce and the idempotency key under idempotencyKey; the receipt message body is the receipt object; thid correlates a receipt with its signal. The profile identifier is didcomm/2.0. DIDComm's own encryption and sender authentication replace the transport-level requirements of section 9.1; every other requirement of this document applies unchanged.

10.1. Proofs§

AGTP credentials and signed records are secured with Data Integrity [VC-DATA-INTEGRITY]. The baseline cryptosuite, which all implementations MUST support for both signing and verification, is eddsa-rdfc-2022 [VC-DI-EDDSA]: Ed25519 signatures over the RDF Dataset Canonicalization of the document. Implementations MAY support eddsa-jcs-2022 and other registered cryptosuites, advertised in the capabilities document. The Ed25519Signature2020 proof type used by AGTP v2 MUST be accepted by verifiers during the overlap window of section 13 and SHOULD NOT be used for new signatures.

A proof MUST have proofPurpose assertionMethod, MUST carry created, and MUST reference by verificationMethod a key that appears under assertionMethod in the issuer's DID Document. Verifiers MUST resolve the DID Document at verification time and, where the method provides history, SHOULD confirm that the key was authorised at created. A verifier MUST fail closed on a cryptosuite it does not support unless the Space's manifest explicitly permits a fallback. A document MAY carry a proof set with several proofs; it is valid if at least one proof verifies against the issuer, and a Space MAY require more.

10.2. Canonicalisation and Hashing§

Three hashes appear in this specification—signalHash, manifestHash and contentHash—and all are computed the same way. Given an AGTP document:

1. Remove the proof property and, for manifests and descriptors, the hash property itself.
2. Expand and canonicalise the resulting JSON-LD document with RDF Dataset Canonicalization [RDF-CANON] (RDFC-1.0, the standardised successor of URDNA2015) to obtain canonical N-Quads, serialised as UTF-8.
3. Compute the SHA-256 digest of those bytes.
4. Encode the digest as a multihash [MULTIHASH] with the sha2-256 code and then in multibase [MULTIBASE] base64url without padding (prefix u), matching the digestMultibase convention of [VC-DATA-MODEL-2.0].

The resulting string, for example uEiA4k3bQm1vZ2x0c3Q5Y2t4dGVzdGRhdGFhYWFhYWFhYWFhYWE, is stable across key order, whitespace, context aliasing and re-signing. Two signals with equal signalHash make identical claims and MUST be treated as one by receivers and aggregators. The advertised value of hashing in a capabilities document for this procedure is rdfc-1.0+sha2-256; AGTP v2's URDNA2015+multihash denotes the same computation and MUST be treated as equivalent.

10.3. Status and Revocation§

Learning Signals and Space Manifests MUST carry a credentialStatus in one of two forms, and every consumer MUST support both:

• a BitstringStatusListEntry as specified by [VC-BITSTRING-STATUS-LIST], with statusPurpose revocation and optionally a second entry with purpose suspension; or
• an AGTPSpaceStatus entry whose id is a URL of a status resource (section 9.5) operated by the Space or the issuer.

The legacy StatusList2021Entry type MUST be accepted during the overlap window. Consumers MUST check status before aggregating, routing on, anchoring or presenting a signal as verified, MAY cache results for the lifetime indicated by the status resource's caching headers, and MUST treat a status that cannot be retrieved as unknown rather than valid. Revoked signals MUST be excluded from aggregation; suspended signals SHOULD be. Revocation of a Space Manifest invalidates the interpretation of signals issued under it only to the extent the replacing manifest says; by default a successor manifest re-interprets earlier signals whose dimensions it still declares.

10.4. Keys and Key Management§

Baseline keys are Ed25519 public keys expressed as Multikey verification methods [CONTROLLED-IDENTIFIERS]; Ed25519VerificationKey2020 MUST be accepted. Issuers SHOULD use distinct keys for assertion and authentication, SHOULD rotate assertion keys by adding a new verification method before removing the old one, and MUST publish the removal through their DID method so that verifiers can date it. An issuer whose key is compromised SHOULD revoke the signals issued with it through its status mechanism; a Space SHOULD define, as policy, an emergency invalidation procedure for compromised issuers that operates through its own status resource without waiting on the issuer.

11.1. Reference Default: Trust-Weighted Average§

When a manifest omits aggregation, or names https://schema.agtp.org/aggregation#TrustWeightedAverage, the following applies. For each dimension d and subject, let S_d be the set of accepted, verified, non-revoked persistent signals about the subject on d whose validFrom lies within the window ending now. The aggregate is

v̂_d = ( Σ_{s ∈ Sd} w(s) · v_s ) / ( Σ_{s ∈ Sd} w(s) )

where w(s) is the weight of the signal's issuer at aggregation time, initially defaultWeight, multiplied by the weight assigned to the signal's issuerRelation. The parameters, with their defaults, are:

Aggregators MUST publish, alongside an aggregate, the manifestHash under which it was computed, the number of distinct issuers and the window, so that consumers can judge and recompute it.

11.2. Override Hooks§

A manifest names another function by a URI in aggregation.name; registered identifiers are listed in Appendix F. aggregation.parameters is open, and clients MAY ignore parameters they do not understand. aggregation.impl MAY point at a reference implementation with a version. A Space MAY declare different functions per dimension by giving aggregation as an array of objects each with a dimensions member. Whatever the function, it MUST be a pure function of the persistent signals the Space serves and of the manifest, so that an independent party can recompute it.

11.3. Partition Tolerance and Degraded Mode§

During network partitions or when a dependency (a DID method, a status list host, a registry) is unreachable, a receiver MAY enter degraded mode: it answers deliveries with 202 and a pending receipt rather than rejecting them, caches last-known-good manifests until their validUntil, marks published aggregates as tentative, and reconciles on heal by re-verifying pending signals, deduplicating by signalHash and, where anchors exist, checking anchored hashes. A receiver in degraded mode MUST say so through its status resource and SHOULD say so with 503 and the degraded problem type when it cannot even queue.

11.4. Interplay with Knowledge Lifecycle§

This section is non-normative. Dimension concepts and knowledge artifacts carry OKF status and stale_after. A Space that references them can let those fields drive aggregation: signals on a deprecated dimension stop counting when the successor manifest drops it; signals about a stale concept lose weight until a fresh verification event, backed by a signal, resets the clock. None of this requires a protocol change—it is a choice of aggregation parameters that reads the same frontmatter agents already read.

12.1. The Profile Contract§

Every profile, including those defined in this document and those registered later, MUST specify the following:

1. the values of sourceProtocol and sourceVersion, and the members of sourceRefs that observation records preserve, with a statement of which upstream ordering semantics are preserved;
2. which AGTP objects the profile creates—Observation Records, Artifacts, Capability Descriptors, Learning Signals, Receipts, Anchor Commitments—and from which upstream objects or events;
3. how actor and subject DIDs are obtained, including the gateway identity rule when the upstream protocol lacks DIDs;
4. how the interaction identifier is derived and how the provenance URI's artifacts are chosen;
5. the separation between transport or execution outcomes (observations) and evaluative judgments (signals), and the issuance points the profile supports;
6. the redaction and hashing strategy for payloads that may be private, expressed in terms of the privacy classes of section 5.7; and
7. where AGTP identifiers are carried inside the upstream protocol, using the reserved keys below and nothing that the upstream protocol reserves for itself.

12.2. DID and Verifiable Credentials (Baseline)§

Profile identifier: did-vc/2.1. This profile is the substrate on which every other profile depends and is not optional. It consists of the identifier requirements of section 3, the credential family and representations of section 4, and the cryptographic suite of section 10. In summary, an implementation of this profile:

• identifies every participant by a resolvable DID and discovers services through DID Documents;
• expresses every portable trust claim as a Verifiable Credential 2.0 with the AGTP context and one AGTP type;
• secures documents with Data Integrity proofs, baseline eddsa-rdfc-2022, and verifies them against assertionMethod keys;
• checks Bitstring Status List or Space status entries before use and fails closed on unresolvable DIDs, unsupported cryptosuites and unretrievable status;
• computes signalHash, manifestHash and contentHash by the procedure of section 10.2.

Other profiles MAY start from non-credential records, but any claim that crosses an organisational boundary as evidence of trust SHOULD be upgraded to an AGTP credential before it does.

12.3. Model Context Protocol§

Profile identifiers: mcp/2025-11-25 and mcp/2025-06-18, corresponding to the MCP specification revisions [MCP]. MCP defines how a client discovers and invokes a server's tools, resources and prompts over JSON-RPC 2.0; it says nothing about whether the results were any good. This profile makes MCP activity first-class evidence in AGTP without changing MCP semantics.

The following requirements apply:

1. Clients that participate in AGTP SHOULD send _meta["org.agtp/space"], _meta["org.agtp/interaction"] and _meta["org.agtp/actor"] on tools/call and resources/read requests so that the server can attach its records to the same interaction. Servers MUST ignore these keys when they do not understand them, as MCP requires of unknown _meta keys.
2. Servers that participate in AGTP SHOULD return _meta["org.agtp/artifacts"] (an array of artifact references) and MAY return _meta["org.agtp/provenance"] on results, so that the client and the server agree on the CIDs before either issues or receives a signal.
3. Capability Descriptors MUST be regenerated, with a new contentHash, whenever a tool's schema changes; notifications/tools/list_changed is the trigger. Observation records MUST reference the descriptor contentHash in force at call time.
4. Tool descriptions are untrusted input from the server. An integrator MUST NOT treat instructions in a description as AGTP operations, and a Space MAY define a dimension under which evaluators score descriptions for injection.
5. Where MCP's authorization framework is used, the resource server's identity SHOULD be bound to its DID through alsoKnownAs so that the OAuth resource and the AGTP subject are verifiably the same party.

// request
{ "jsonrpc": "2.0", "id": 7, "method": "tools/call",
  "params": {
    "name": "run_sql",
    "arguments": { "sql": "SELECT SUM(amount) FROM orders WHERE year = 2026" },
    "_meta": {
      "org.agtp/space": "did:web:rlvr.example",
      "org.agtp/interaction": "urn:uuid:6d2a4c8e-9b1f-4e3d-8a7c-5f6e7d8c9b0a",
      "org.agtp/actor": "did:web:orchestrator.example"
    }
  }
}

// result
{ "jsonrpc": "2.0", "id": 7,
  "result": {
    "content": [{ "type": "text", "text": "1834219.55" }],
    "structuredContent": { "sum": 1834219.55 },
    "isError": false,
    "_meta": {
      "org.agtp/did": "did:web:solver.example",
      "org.agtp/artifacts": [
        { "role": "input",  "cid": "bafkreib5x2s3q6l7ihd4qq7mmm2a2m3iuqhz7vqz3zjzq6p3ep4gk7v4wy" },
        { "role": "output", "cid": "bafkreiaw3fsg7cn5e6tjyd5zvo2ujqcrrxi3rlhqaw5j6ozx7fqyq2wtia" }
      ],
      "org.agtp/provenance": "agtp://provenance?space=did:web:rlvr.example&interaction=urn:uuid:6d2a4c8e-9b1f-4e3d-8a7c-5f6e7d8c9b0a&artifact=bafkreiaw3fsg7cn5e6tjyd5zvo2ujqcrrxi3rlhqaw5j6ozx7fqyq2wtia,bafkreib5x2s3q6l7ihd4qq7mmm2a2m3iuqhz7vqz3zjzq6p3ep4gk7v4wy"
    }
  }
}

12.4. Agentic Resource Discovery§

Profile identifier: ard/0.91. The normative content of this profile is section 7. In the terms of the profile contract: sourceProtocol is ard; sourceRefs preserves the entry identifier, the registry source and the search score; the profile creates Capability Descriptors (from entries the publisher controls) and Observation Records (for searches and verification outcomes); the actor is the searching agent and the subject is the entry's agtp:did; discovery events are observations and never signals; entries are public by construction and carry no private payloads; and AGTP identifiers travel in the entry under the agtp prefix.

12.5. Open Knowledge Format§

Profile identifier: okf/0.2. The normative content of this profile is section 8. In the terms of the profile contract: sourceProtocol is okf and sourceVersion is the bundle's okf_version; sourceRefs preserves the bundle CID, the concept path and, where applicable, the git commit; the profile creates Artifacts (bundles, concepts, receipts), Observation Records (generation, usage, reads), Capability Descriptors (attested computations) and Learning Signals (verification events, attester verdicts); actors are obtained from the DID forms of OKF actor identifiers; the interaction identifier for an attestation is derived from the computation's CID and parameters; verification events and attester verdicts are the issuance points; bodies MAY be private with concept CIDs still bound in provenance; and AGTP identifiers travel in the agtp frontmatter mapping.

12.6. Model-Runtime APIs (OpenAI API Conventions)§

Profile identifier: openai-api/1. This profile covers the request and response conventions popularised by the OpenAI API [OPENAI-API]—messages with roles, tool and function schemas in JSON Schema, tool-call identifiers, response identifiers, a free-form metadata map and usage accounting—as implemented by many model providers and gateways. It does not depend on any one provider.

The API endpoint is not an AGTP identity; the calling agent, service or gateway is, and it holds the DID. Where several agents share one gateway, the gateway MUST preserve the delegated actor in sourceRefs or a Delegation credential. Callers SHOULD set metadata.agtp_space, metadata.agtp_interaction and, where the provider echoes metadata, read them back to confirm correlation. Provider-computed evaluation results, where a provider offers them, are observations until a Space evaluator adopts them as the basis of a signal.

12.7. Agent2Agent Protocol§

Profile identifier: a2a/1.0, corresponding to A2A 1.0 [A2A]; earlier revisions are identified by their own version. A2A provides task lifecycle, messaging, artifact exchange and capability discovery between agents. The correct integration is not to collapse A2A into AGTP but to make A2A interactions emit AGTP objects.

Task completion, cancellation, failure or rejection is an execution fact recorded as an observation, not a signal. Long-running tasks MAY be divided into several interactions provided each preserves the task identifier and lineage to the task's artifacts. An A2A agent that lacks a DID is represented by a gateway identity, and the mapping between its card URL and the DID SHOULD be published as a Capability Descriptor or in the DID Document's alsoKnownAs.

12.8. A2UI§

Profile identifiers: a2ui/0.8 (production baseline) and a2ui/0.9 (draft) [A2UI]. A2UI is the human-facing surface where much of the highest-value feedback originates. This profile makes UI interactions and human judgments portable without defining UI semantics.

• A UI session or context is an Interaction, bound to the same interaction identifier as the A2A, MCP or model-API activity it presents wherever that identifier is available.
• UI events are Observation Records (UIEventRecord) with event identifiers, order and timestamps preserved in sourceRefs; rendered snapshots, prompts and outputs are Artifacts at the privacy class Space policy assigns.
• Only evaluative judgments—ratings, preferences, corrections, approvals and rejections, rubric scores—become Learning Signals. Telemetry (clicks, dwell, scroll) never does. Human-issued signals SHOULD carry issuerRelation and MAY carry confidence; the issuer is the human's DID or a gateway identity with a Delegation credential.
• Evidence gathered in the interface—screenshots, annotations, correction diffs—becomes Artifacts referenced from provenance. For sensitive interfaces implementations SHOULD distil ephemeral UI observations into a persistent summary signal with a commitment.
• Mappings MUST be version-tagged; v0.8 and v0.9 fields MUST NOT be mixed in one record without a translation layer.

12.9. AGENTS.md and Agent Skills§

Profile identifier: agents-skills/1. AGENTS.md [AGENTS-MD] expresses repository or workspace policy for coding agents in free-form Markdown, with nearest-file precedence. Agent Skills [AGENT-SKILLS] package a capability as a directory with a SKILL.md whose YAML frontmatter carries name, description and optional license, compatibility, metadata and allowed-tools. Together they are the intent layer: what an agent may do and what it says it can do.

• An AGENTS.md file in force during an interaction is an Artifact (role policy) referenced from the observation record's policyRefs. Which file applied, under nearest-file precedence, is recorded, not inferred. An AGENTS.md MAY be exchanged across organisational boundaries as a PolicyAssertion credential binding its CID.
• A skill is a Capability with interfaceType agent-skill. The descriptor's name and description come from the frontmatter; constraints carries allowed-tools, compatibility and license; sourceArtifacts carries the CID of SKILL.md and of the skill directory; contentHash changes whenever either changes.
• Skill authors MAY place agtp-owner (a DID), agtp-capability (the capability URI or ARD identifier) and agtp-space in the frontmatter metadata map, whose values are strings as Agent Skills requires.
• Policy and capability MUST NOT be flattened into one another: an AGENTS.md constraint is a policyRef, not a capability, and instruction text in a SKILL.md body is execution guidance, not a declaration.
• Signals about a skill are issued against its capability URI, and observation records reference the descriptor contentHash used at execution time, so that a Space can compare declared constraints with observed behaviour version by version.

OKF attested computations reference skills through executor.resource; when they do, the skill's capability identifier and the computation's capability identifier SHOULD be linked through sourceArtifacts so that signals on either inform the other.

12.10. ERC-8004 Trustless Agents§

Profile identifier: erc8004/1. ERC-8004 [ERC-8004] defines three on-chain registries: an identity registry that mints an agent identifier bound to an off-chain registration file, a reputation registry that records feedback entries pointing at off-chain feedback files, and a validation registry that records validation requests and responses by hash. This profile lets AGTP use those registries for discovery and anchoring while keeping signals, manifests and traces off-chain, portable and chain-neutral.

The recommended resolution order is: registry entry, then DID and services, then manifests, descriptors and signals off-chain, then proofs and status, then optionally the anchor. AGTP verification is authoritative at every step; the chain adds discovery and audit, and never replaces DID resolution or proof verification. Raw traces and private evidence MUST NOT be required on-chain for conformance.

13.1. Version Semantics§

AGTP uses semantic versioning. This document specifies AGTP 2.1.0. A PATCH increment corrects text without changing conformance; a MINOR increment adds optional properties, resources, profiles or conformance classes without breaking existing conformant implementations; a MAJOR increment may change wire semantics. The version an implementation supports is advertised as agtpVersion in its capabilities document, and profiles are negotiated by their registered identifiers. An implementation that receives an object from a later MINOR version MUST process the properties it understands and ignore the rest.

13.2. Migration from AGTP v2§

The following changes are compatibility-managed. Consumers MUST accept both forms for an overlap window of at least twelve months after this specification becomes a Consortium Recommendation; producers SHOULD emit the 2.1 form and MAY dual-serve manifests.

13.3. Extensibility§

The extension mechanisms are those of section 4.4: new terms in separate namespaces, new dimensions declared by Spaces, and new entries in the registries of Appendix F. Transport profiles, cryptosuites and binding profiles MAY be standardised separately without changing the core invariants, and a profile MAY advance on its own version track.

13.4. Change Process§

The protocol is mechanism only; policy stays in Spaces. The AGTP Consortium convenes editors, maintains the registries and publishes the specification. It has no binding authority over any Space, registry or implementation, and this specification creates none. Changes proceed as follows: a written proposal with rationale; a reference implementation; conformance tests added to Appendix D; and release. A MINOR increment requires two independent implementations of each new normative feature. A MAJOR increment requires a deprecation schedule, migration tooling and an overlap window during which manifests are dual-served and clients negotiate through the capabilities resource. Non-goals remain as in v2: no global governance mandate, no council with binding authority, no privileged registry.

13.5. Space-Controlled Parameters§

This section is non-normative. Examples of what a Space controls without any protocol change: the aggregation window, minimum raters and issuer caps; issuer-relation weights; eligibility gates such as uptime or acceptance rates; deposits and refundable stakes against spam; dispute windows and the meaning of pending; dimension registries and extension namespaces; the privacy class of traces; which ARD registries it recognises; which knowledge bundles it pins; and whether it anchors, where, and how often.