@openvtc/trust-tasks 0.8.2 → 0.10.0

package/src/vrc/relationships/issue/0.1/payload.ts

@@ -51,16 +51,140 @@ export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/vrc/relationships/
 /** Stable alias for this specification's success-response payload shape. */
 export type Response = VRCRelationshipsIssueResponsePayload;
 
+/**
+ * This specification's payload schema, as a value.
+ *
+ * SPEC.md §7.2 item 2 is performed against this. It is shipped as data
+ * rather than only as a `.json` file because TypeScript types are erased
+ * at runtime: without a schema a consumer has nothing to validate, and
+ * every REQUIRED payload member is optional in practice. Cross-file
+ * `$ref`s are already inlined, so it needs no resolver.
+ */
+export const PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://trusttasks.org/spec/vrc/relationships/issue/0.1",
+  "title": "VRC Relationships Issue — payload",
+  "description": "Delivers one party's signed Verifiable Relationship Credential to the other within an accepted relationship exchange. Performed once in each direction; the response is a delivery receipt naming what was stored, and does not echo the credential back.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "vrc"
+  ],
+  "properties": {
+    "vrc": {
+      "type": "object",
+      "description": "A signed W3C Verifiable Relationship Credential (opaque here). Its issuer MUST be the issuing party's relationship DID and its credential subject MUST name the receiving party's relationship DID — the values the accepted proposal exchanged."
+    },
+    "vrcDigestMultibase": {
+      "$ref": "#/$defs/DigestMultibase",
+      "description": "Digest over the RFC 8785 canonicalization of the credential, so the delivery can be tied to later references to it without re-hashing. A producer SHOULD set it; the receipt's own digest is what makes the round trip checkable, so a producer that omits it can still verify the delivery against the credential it holds."
+    },
+    "ext": {
+      "$ref": "#/$defs/Ext"
+    }
+  },
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "VRC Relationships Issue — response payload",
+      "description": "The delivery receipt: the receiving party accepted and stored the credential, and names which one. A refusal is a trust-task-error, never a receipt reporting failure.\n\nThe receipt names the stored artifact rather than merely asserting that something arrived, following the delivery idiom of vtc/members/vmc and vtc/join-requests/accept. It has to: both directions of this exchange share one threadId, and a #response carries no inResponseTo, so the digest is what tells a party which of its two deliveries a receipt answers.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "vrcDigestMultibase"
+      ],
+      "properties": {
+        "vrcDigestMultibase": {
+          "$ref": "#/$defs/DigestMultibase",
+          "description": "Digest over the RFC 8785 canonicalization of the credential AS STORED, computed by the receiving party rather than copied from the request. Computing it is the point: a copied value attests nothing, while a recomputed one makes a mismatch between what was sent and what was stored detectable in-band, and identifies which delivery this receipt answers."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    },
+    "DigestMultibase": {
+      "title": "DigestMultibase",
+      "description": "A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.\n\nMultihash carries the hash algorithm in-band, so the value is self-describing and the wire format survives an algorithm change without a schema revision; multibase does the same for the base encoding, so a verifier never infers base58 from base64url by context. A bare hex string or a `sha-256:`-style prefix hard-codes one algorithm into the wire contract and is non-conforming here.\n\nThis definition constrains the *encoding only*. What the digest is computed over is stated by each referencing field, because it differs legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS) canonicalization, while a digest over an opaque artifact is taken over its bytes. A field whose input is a JSON document and which does not name a canonicalization is not reproducible.\n\nRestricted to the two multibase headers W3C Controlled Identifiers 1.0 §2.4 normatively requires — `z` (base58btc) and `u` (base64url-no-pad). CID permits others but states that \"interoperability is not guaranteed between implementations using such values\", and a registry whose purpose is interoperability should not mint digests a conforming verifier may be unable to read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I and l, and an earlier permissive pattern let three published examples carry digests that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with `did:key` and `did:webvh`.",
+      "type": "string",
+      "minLength": 16,
+      "pattern": "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$",
+      "examples": [
+        "zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"
+      ]
+    }
+  }
+} as const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "VRC Relationships Issue — response payload",
+      "description": "The delivery receipt: the receiving party accepted and stored the credential, and names which one. A refusal is a trust-task-error, never a receipt reporting failure.\n\nThe receipt names the stored artifact rather than merely asserting that something arrived, following the delivery idiom of vtc/members/vmc and vtc/join-requests/accept. It has to: both directions of this exchange share one threadId, and a #response carries no inResponseTo, so the digest is what tells a party which of its two deliveries a receipt answers.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "vrcDigestMultibase"
+      ],
+      "properties": {
+        "vrcDigestMultibase": {
+          "$ref": "#/$defs/DigestMultibase",
+          "description": "Digest over the RFC 8785 canonicalization of the credential AS STORED, computed by the receiving party rather than copied from the request. Computing it is the point: a copied value attests nothing, while a recomputed one makes a mismatch between what was sent and what was stored detectable in-band, and identifies which delivery this receipt answers."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    },
+    "DigestMultibase": {
+      "title": "DigestMultibase",
+      "description": "A cryptographic digest as a multibase-encoded multihash — the encoding the W3C Verifiable Credentials Data Model 2.0 defines for `digestMultibase`, and the one `did:webvh` uses for its SCID and entry hashes.\n\nMultihash carries the hash algorithm in-band, so the value is self-describing and the wire format survives an algorithm change without a schema revision; multibase does the same for the base encoding, so a verifier never infers base58 from base64url by context. A bare hex string or a `sha-256:`-style prefix hard-codes one algorithm into the wire contract and is non-conforming here.\n\nThis definition constrains the *encoding only*. What the digest is computed over is stated by each referencing field, because it differs legitimately: a digest over a JSON document is taken over its RFC 8785 (JCS) canonicalization, while a digest over an opaque artifact is taken over its bytes. A field whose input is a JSON document and which does not name a canonicalization is not reproducible.\n\nRestricted to the two multibase headers W3C Controlled Identifiers 1.0 §2.4 normatively requires — `z` (base58btc) and `u` (base64url-no-pad). CID permits others but states that \"interoperability is not guaranteed between implementations using such values\", and a registry whose purpose is interoperability should not mint digests a conforming verifier may be unable to read. The alphabets are enforced rather than assumed: base58btc excludes 0, O, I and l, and an earlier permissive pattern let three published examples carry digests that were not valid base58 at all. base58btc is RECOMMENDED, for consistency with `did:key` and `did:webvh`.",
+      "type": "string",
+      "minLength": 16,
+      "pattern": "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$",
+      "examples": [
+        "zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"
+      ]
+    }
+  }
+} as const;
+
 /**
  * SPEC.md §7.2 policy for the request variant, from this specification's
  * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
- * per-specification and cannot be derived from the document alone.
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
  */
 export const SPEC = {
   typeUri: TYPE_URI,
   isBearer: false,
   isProofRequired: true,
   isRecipientRequired: true,
+  payloadSchema: PAYLOAD_SCHEMA,
 } as const;
 
 /**
@@ -73,4 +197,5 @@ export const RESPONSE_SPEC = {
   isBearer: false,
   isProofRequired: false,
   isRecipientRequired: true,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
 } as const;

package/src/vrc/relationships/propose/0.1/payload.ts

@@ -58,16 +58,146 @@ export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/vrc/relationships/
 /** Stable alias for this specification's success-response payload shape. */
 export type Response = VRCRelationshipsProposeResponsePayload;
 
+/**
+ * This specification's payload schema, as a value.
+ *
+ * SPEC.md §7.2 item 2 is performed against this. It is shipped as data
+ * rather than only as a `.json` file because TypeScript types are erased
+ * at runtime: without a schema a consumer has nothing to validate, and
+ * every REQUIRED payload member is optional in practice. Cross-file
+ * `$ref`s are already inlined, so it needs no resolver.
+ */
+export const PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://trusttasks.org/spec/vrc/relationships/propose/0.1",
+  "title": "VRC Relationships Propose — payload",
+  "description": "One person proposes a peer-to-peer relationship to another, naming the pairwise DID they will use for it. The counterparty accepts or declines; a decline is a trust-task-error carrying `vrc/relationships/propose:declined`.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "relationshipDid"
+  ],
+  "properties": {
+    "relationshipDid": {
+      "type": "string",
+      "pattern": "^did:",
+      "description": "The pairwise DID the proposing party will use for this relationship. Minted for this relationship — a producer MUST NOT carry a long-term identifier here, which would make every later presentation of the resulting credentials linkable."
+    },
+    "witnessed": {
+      "type": "boolean",
+      "description": "Whether the proposing party asks that the exchange be witnessed. A request, not a fact: it is answered by the same member on the response, and which witness and on what terms is settled under the witness/* specifications, as a separate exchange nested via parentThreadId. Absent means unwitnessed."
+    },
+    "reason": {
+      "type": "string",
+      "minLength": 1,
+      "description": "Why the proposing party is asking, in their own words. A hint reaching a human; the counterparty is under no obligation to honour it and MUST NOT treat its absence as a defect."
+    },
+    "ext": {
+      "$ref": "#/$defs/Ext"
+    }
+  },
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "VRC Relationships Propose — response payload",
+      "description": "The counterparty's acceptance, and its answer on witnessing. A decline is a trust-task-error, never a response with accept: false.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "accept",
+        "relationshipDid"
+      ],
+      "properties": {
+        "accept": {
+          "const": true,
+          "description": "Always true: a decline travels as a trust-task-error so that refusals share one path and one set of routing rules (SPEC.md §8.1). Present so the acceptance is explicit rather than inferred from the response's existence."
+        },
+        "relationshipDid": {
+          "type": "string",
+          "pattern": "^did:",
+          "description": "The pairwise DID the counterparty will use for this relationship, under the same non-linkability obligation as the request's."
+        },
+        "witnessed": {
+          "type": "boolean",
+          "description": "The counterparty's answer to the request's `witnessed`: true where it agrees the exchange will be witnessed. Absent or false accepts an UNWITNESSED exchange, whatever the request asked for — a counterparty unwilling to proceed unwitnessed declines instead, since this specification defines no renegotiation."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "VRC Relationships Propose — response payload",
+      "description": "The counterparty's acceptance, and its answer on witnessing. A decline is a trust-task-error, never a response with accept: false.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "accept",
+        "relationshipDid"
+      ],
+      "properties": {
+        "accept": {
+          "const": true,
+          "description": "Always true: a decline travels as a trust-task-error so that refusals share one path and one set of routing rules (SPEC.md §8.1). Present so the acceptance is explicit rather than inferred from the response's existence."
+        },
+        "relationshipDid": {
+          "type": "string",
+          "pattern": "^did:",
+          "description": "The pairwise DID the counterparty will use for this relationship, under the same non-linkability obligation as the request's."
+        },
+        "witnessed": {
+          "type": "boolean",
+          "description": "The counterparty's answer to the request's `witnessed`: true where it agrees the exchange will be witnessed. Absent or false accepts an UNWITNESSED exchange, whatever the request asked for — a counterparty unwilling to proceed unwitnessed declines instead, since this specification defines no renegotiation."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
 /**
  * SPEC.md §7.2 policy for the request variant, from this specification's
  * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
- * per-specification and cannot be derived from the document alone.
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
  */
 export const SPEC = {
   typeUri: TYPE_URI,
   isBearer: false,
   isProofRequired: false,
   isRecipientRequired: true,
+  payloadSchema: PAYLOAD_SCHEMA,
 } as const;
 
 /**
@@ -80,4 +210,5 @@ export const RESPONSE_SPEC = {
   isBearer: false,
   isProofRequired: false,
   isRecipientRequired: true,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
 } as const;

package/src/vta/_shared/0.1/context.ts

@@ -0,0 +1,11 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/vta/_shared/0.1/context.schema.json
+ */
+
+/**
+ * A *context* is the VTA's unit of separation: keys, DIDs, vault entries, policies and memory all belong to exactly one, and an ACL entry's scopes are context ids. Contexts nest — `parent` names the context this one sits under, and `basePath` is the resolved path from the root — so authority granted at an ancestor reaches its descendants. `ContextRecord` is the persisted shape every task in the family returns; it is defined once here because `create`, `get`, `update`, `update-did` and `list` all hand back the same record, and an inline copy per task would fork the moment one of them gained a member.
+ */
+export interface ContextRecordSharedDefinitionForTheVtaContextsSpecFamily {
+  [k: string]: unknown | undefined;
+}

package/src/vta/_shared/0.1/webvh-records.ts

@@ -0,0 +1,11 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/vta/_shared/0.1/webvh-records.schema.json
+ */
+
+/**
+ * A `did:webvh` DID is published as an append-only log served at a URL. The VTA holds the keys and the authority to append; a *hosting server* serves the log. These definitions describe what the VTA holds about each: the DID record, the server registration, and an agent name bound to a DID. Shared because the DID record is returned by create, get and list, and the server record by list and register.
+ */
+export interface WebVHRecordsSharedDefinitionsForTheVtaWebvhSpecFamily {
+  [k: string]: unknown | undefined;
+}

package/src/vta/contexts/create/1.0/payload.ts

@@ -0,0 +1,301 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/vta/contexts/create/1.0/payload.schema.json
+ */
+
+export interface VTAContextsCreatePayload {
+  /**
+   * Id for the new context. When `parent` is present this is the leaf segment and the full id becomes `<parent>/<id>`; otherwise it is a top-level id. Must be unique within its parent — a collision is refused, never merged.
+   */
+  id: string;
+  /**
+   * Human-readable name. Operator-facing only; carries no authorization meaning.
+   */
+  name: string;
+  /**
+   * Free-form description.
+   */
+  description?: string;
+  /**
+   * Id of the context to nest under. Absent creates a top-level context. Nesting is not cosmetic: authority granted at the parent reaches this context.
+   */
+  parent?: string;
+  ext?: Ext;
+}
+/**
+ * Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.
+ */
+export interface Ext {
+  [k: string]: unknown | undefined;
+}
+/**
+ * A context as the VTA holds it.
+ */
+export interface ContextRecord {
+  /**
+   * Context id. For a nested context this is the full path (`parent/leaf`), not the leaf alone — an ACL scope naming this context must use this value verbatim.
+   */
+  id: string;
+  /**
+   * Human-readable name. Operator-facing only; carries no authorization meaning, and two contexts may share a name.
+   */
+  name: string;
+  /**
+   * DID this context acts as, when one has been assigned. Absent means the context has no identity of its own yet — not that it has been denied one.
+   */
+  did?: string;
+  /**
+   * Free-form description.
+   */
+  description?: string;
+  /**
+   * Id of the context this one nests under. Absent for a top-level context. Authority granted at a parent reaches its children, so this member is load-bearing for anyone reasoning about scope.
+   */
+  parent?: string;
+  /**
+   * Resolved path from the root context, as the VTA derives it from the parent chain. Consumers MUST treat this as derived state: it is recomputed by the maintainer and is not independently settable.
+   */
+  basePath: string;
+  /**
+   * RFC 3339.
+   */
+  createdAt: string;
+  /**
+   * RFC 3339.
+   */
+  updatedAt: string;
+  ext?: Ext;
+}
+
+/** Trust Task type URI. */
+export const TYPE_URI = "https://trusttasks.org/spec/vta/contexts/create/1.0" as const;
+
+/** Stable alias for this specification's request payload shape. */
+export type Payload = VTAContextsCreatePayload;
+
+/** Trust Task response type URI (request type URI + "#response"). */
+export const RESPONSE_TYPE_URI = "https://trusttasks.org/spec/vta/contexts/create/1.0#response" as const;
+
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = ContextRecord;
+
+/**
+ * This specification's payload schema, as a value.
+ *
+ * SPEC.md §7.2 item 2 is performed against this. It is shipped as data
+ * rather than only as a `.json` file because TypeScript types are erased
+ * at runtime: without a schema a consumer has nothing to validate, and
+ * every REQUIRED payload member is optional in practice. Cross-file
+ * `$ref`s are already inlined, so it needs no resolver.
+ */
+export const PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://trusttasks.org/spec/vta/contexts/create/1.0",
+  "title": "VTA Contexts Create — payload",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "id",
+    "name"
+  ],
+  "properties": {
+    "id": {
+      "type": "string",
+      "minLength": 1,
+      "description": "Id for the new context. When `parent` is present this is the leaf segment and the full id becomes `<parent>/<id>`; otherwise it is a top-level id. Must be unique within its parent — a collision is refused, never merged."
+    },
+    "name": {
+      "type": "string",
+      "minLength": 1,
+      "description": "Human-readable name. Operator-facing only; carries no authorization meaning."
+    },
+    "description": {
+      "type": "string",
+      "description": "Free-form description."
+    },
+    "parent": {
+      "type": "string",
+      "description": "Id of the context to nest under. Absent creates a top-level context. Nesting is not cosmetic: authority granted at the parent reaches this context."
+    },
+    "ext": {
+      "$ref": "#/$defs/Ext"
+    }
+  },
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "VTA Contexts Create — response payload",
+      "description": "Success response to vta/contexts/create: the realized context record, at the top level. Type https://trusttasks.org/spec/vta/contexts/create/1.0#response.",
+      "$ref": "#/$defs/ContextRecord"
+    },
+    "ContextRecord": {
+      "title": "ContextRecord",
+      "description": "A context as the VTA holds it.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "id",
+        "name",
+        "basePath",
+        "createdAt",
+        "updatedAt"
+      ],
+      "properties": {
+        "id": {
+          "type": "string",
+          "minLength": 1,
+          "description": "Context id. For a nested context this is the full path (`parent/leaf`), not the leaf alone — an ACL scope naming this context must use this value verbatim."
+        },
+        "name": {
+          "type": "string",
+          "minLength": 1,
+          "description": "Human-readable name. Operator-facing only; carries no authorization meaning, and two contexts may share a name."
+        },
+        "did": {
+          "type": "string",
+          "description": "DID this context acts as, when one has been assigned. Absent means the context has no identity of its own yet — not that it has been denied one."
+        },
+        "description": {
+          "type": "string",
+          "description": "Free-form description."
+        },
+        "parent": {
+          "type": "string",
+          "description": "Id of the context this one nests under. Absent for a top-level context. Authority granted at a parent reaches its children, so this member is load-bearing for anyone reasoning about scope."
+        },
+        "basePath": {
+          "type": "string",
+          "description": "Resolved path from the root context, as the VTA derives it from the parent chain. Consumers MUST treat this as derived state: it is recomputed by the maintainer and is not independently settable."
+        },
+        "createdAt": {
+          "type": "string",
+          "format": "date-time",
+          "description": "RFC 3339."
+        },
+        "updatedAt": {
+          "type": "string",
+          "format": "date-time",
+          "description": "RFC 3339."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export const RESPONSE_PAYLOAD_SCHEMA = {
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$ref": "#/$defs/Response",
+  "$defs": {
+    "Response": {
+      "$anchor": "response",
+      "title": "VTA Contexts Create — response payload",
+      "description": "Success response to vta/contexts/create: the realized context record, at the top level. Type https://trusttasks.org/spec/vta/contexts/create/1.0#response.",
+      "$ref": "#/$defs/ContextRecord"
+    },
+    "ContextRecord": {
+      "title": "ContextRecord",
+      "description": "A context as the VTA holds it.",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "id",
+        "name",
+        "basePath",
+        "createdAt",
+        "updatedAt"
+      ],
+      "properties": {
+        "id": {
+          "type": "string",
+          "minLength": 1,
+          "description": "Context id. For a nested context this is the full path (`parent/leaf`), not the leaf alone — an ACL scope naming this context must use this value verbatim."
+        },
+        "name": {
+          "type": "string",
+          "minLength": 1,
+          "description": "Human-readable name. Operator-facing only; carries no authorization meaning, and two contexts may share a name."
+        },
+        "did": {
+          "type": "string",
+          "description": "DID this context acts as, when one has been assigned. Absent means the context has no identity of its own yet — not that it has been denied one."
+        },
+        "description": {
+          "type": "string",
+          "description": "Free-form description."
+        },
+        "parent": {
+          "type": "string",
+          "description": "Id of the context this one nests under. Absent for a top-level context. Authority granted at a parent reaches its children, so this member is load-bearing for anyone reasoning about scope."
+        },
+        "basePath": {
+          "type": "string",
+          "description": "Resolved path from the root context, as the VTA derives it from the parent chain. Consumers MUST treat this as derived state: it is recomputed by the maintainer and is not independently settable."
+        },
+        "createdAt": {
+          "type": "string",
+          "format": "date-time",
+          "description": "RFC 3339."
+        },
+        "updatedAt": {
+          "type": "string",
+          "format": "date-time",
+          "description": "RFC 3339."
+        },
+        "ext": {
+          "$ref": "#/$defs/Ext"
+        }
+      }
+    },
+    "Ext": {
+      "title": "Ext",
+      "description": "Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a reverse-DNS namespace; structure under each namespace is opaque to the framework.",
+      "type": "object",
+      "minProperties": 1,
+      "additionalProperties": true,
+      "propertyNames": {
+        "pattern": "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$"
+      }
+    }
+  }
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the request variant, from this specification's
+ * front matter. Pass to `consumeInbound` — items 5b, 7 and 8 are
+ * per-specification and cannot be derived from the document alone, and
+ * item 2 needs the schema this carries.
+ */
+export const SPEC = {
+  typeUri: TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  payloadSchema: PAYLOAD_SCHEMA,
+} as const;
+
+/**
+ * SPEC.md §7.2 policy for the success-response variant. `isRecipientRequired`
+ * tracks the *issuer* party's requirement because a response swaps the
+ * parties (§7.3 item 5).
+ */
+export const RESPONSE_SPEC = {
+  typeUri: RESPONSE_TYPE_URI,
+  isBearer: false,
+  isProofRequired: true,
+  isRecipientRequired: true,
+  payloadSchema: RESPONSE_PAYLOAD_SCHEMA,
+} as const;