@openvtc/trust-tasks 0.27.0 → 0.27.2

package/dist/rooms/records/put/0.3/payload.d.ts

@@ -0,0 +1,1212 @@
+/**
+ * Generated by scripts/build-ts-bindings.mjs — DO NOT EDIT BY HAND.
+ * Source: specs/rooms/records/put/0.3/payload.schema.json
+ */
+import type { AuthorityPresentation, BlobRef, DigestMultibase, Ext, PermittedUse, RecordBasis, RecordConfidence, RecordEvidence, RecordEvidenceCredential, RecordEvidenceList, RecordEvidenceRecord, RecordValidUntil, SealedRecord } from "../../../../_shared/components.js";
+/**
+ * A member writes a record to a data room, authorized by an authority chain the room itself issued. 0.2 added `blobs`: a record can carry a file, whose ciphertext the host stores outside the record and whose description is sealed inside it. 0.3 lets an `open` room's `cleartext` carry the record's provenance — `basis`, `confidence`, `evidence`, `validFor` — and its `validUntil`, which the sealed tiers carry inside the signed `SealedRecordBody`.
+ */
+export interface RoomsRecordsPutPayload {
+    /**
+     * The room's identifier. A host verifies the presentation against credentials issued by this identifier, never against a member list of its own — which is what lets a room move hosts without reissuing a credential.
+     */
+    roomId: string;
+    /**
+     * The record's key within the room. MUST be opaque on an `attributed` or `private` room; see RecordMetadata.key.
+     */
+    key: string;
+    /**
+     * Must confer the `write` action at this room's scope.
+     */
+    presentation: AuthorityPresentation;
+    /**
+     * Optional precondition. Omit to overwrite unconditionally; `0` means create-only and fails if the key exists. On mismatch the host returns `rooms/records/put:versionConflict` CARRYING THE CURRENT VERSION AND RECORD — a bare rejection would force a re-read, and between rejection and re-read the record can change again, so the pattern has no fixed point under contention.
+     */
+    expectedVersion?: number;
+    /**
+     * REQUIRED on an `attributed` or `private` room. Mutually exclusive with `cleartext`.
+     */
+    sealed?: SealedRecord;
+    /**
+     * REQUIRED on an `open` room, where the host reads records and can therefore search them. Mutually exclusive with `sealed`. On this tier the record is not signed by its author: every member here is the writer's claim as the host stores it, provenance and expiry included.
+     */
+    cleartext?: {
+        title?: string;
+        description?: string;
+        body: string;
+        /**
+         * @maxItems 32
+         */
+        tags?: string[];
+        /**
+         * What kind of claim the record is. A writer SHOULD set it; an agent writer that does not know SHOULD write `inferred`. Provenance for display and weighting, never authority.
+         */
+        basis?: RecordBasis;
+        confidence?: RecordConfidence;
+        evidence?: RecordEvidenceList;
+        validFor?: PermittedUse;
+        /**
+         * When the writer stops standing behind the record as current. Readers hide the record once it has passed and show it only on explicit request. A host stores and serves it like any other cleartext member and MUST NOT act on it: it neither hides, refuses nor deletes an expired record.
+         */
+        validUntil?: RecordValidUntil;
+    };
+    /**
+     * The blobs this record keeps alive: today at most one, the file the record carries. Cleartext on every tier, because the host must know which blobs a record references to refuse a record naming a blob it does not hold, to count usage, and to collect a blob no record names. Every blob named MUST have been committed in THIS room (rooms/blobs/upload/commit). An array so that several files per record is a later minor version rather than a reshaped member. Omit for a record with no file; a rewrite that omits it releases whatever blob the previous version named.
+     *
+     * @minItems 1
+     * @maxItems 1
+     */
+    blobs?: [BlobRef];
+    /**
+     * Ecosystem-defined extension members per SPEC.md §4.5.1.
+     */
+    ext?: Ext;
+}
+/**
+ * Success response to rooms/records/put. Type https://trusttasks.org/spec/rooms/records/put/0.3#response.
+ */
+export interface RoomsRecordsPutResponsePayload {
+    /**
+     * The stored record's key.
+     */
+    key: string;
+    /**
+     * The version assigned, monotonic per room.
+     */
+    version: number;
+    /**
+     * The epoch the record was stored under.
+     */
+    epoch?: number;
+    ext?: Ext;
+}
+/** Shared definitions this specification references, re-exported under the names it used to declare them with. */
+export type { AuthorityPresentation, BlobRef, DigestMultibase, Ext, PermittedUse, RecordBasis, RecordConfidence, RecordEvidence, RecordEvidenceCredential, RecordEvidenceList, RecordEvidenceRecord, RecordValidUntil, SealedRecord };
+/** Trust Task type URI. */
+export declare const TYPE_URI: "https://trusttasks.org/spec/rooms/records/put/0.3";
+/** Stable alias for this specification's request payload shape. */
+export type Payload = RoomsRecordsPutPayload;
+/** Trust Task response type URI (request type URI + "#response"). */
+export declare const RESPONSE_TYPE_URI: "https://trusttasks.org/spec/rooms/records/put/0.3#response";
+/** Stable alias for this specification's success-response payload shape. */
+export type Response = RoomsRecordsPutResponsePayload;
+/**
+ * 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 declare const PAYLOAD_SCHEMA: {
+    readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+    readonly $id: "https://trusttasks.org/spec/rooms/records/put/0.3";
+    readonly title: "Rooms Records Put — payload";
+    readonly description: "A member writes a record to a data room, authorized by an authority chain the room itself issued. 0.2 added `blobs`: a record can carry a file, whose ciphertext the host stores outside the record and whose description is sealed inside it. 0.3 lets an `open` room's `cleartext` carry the record's provenance — `basis`, `confidence`, `evidence`, `validFor` — and its `validUntil`, which the sealed tiers carry inside the signed `SealedRecordBody`.";
+    readonly type: "object";
+    readonly additionalProperties: false;
+    readonly required: readonly ["roomId", "key", "presentation"];
+    readonly properties: {
+        readonly roomId: {
+            readonly type: "string";
+            readonly description: "The room's identifier. A host verifies the presentation against credentials issued by this identifier, never against a member list of its own — which is what lets a room move hosts without reissuing a credential.";
+        };
+        readonly key: {
+            readonly type: "string";
+            readonly maxLength: 512;
+            readonly description: "The record's key within the room. MUST be opaque on an `attributed` or `private` room; see RecordMetadata.key.";
+        };
+        readonly presentation: {
+            readonly $ref: "#/$defs/AuthorityPresentation";
+            readonly description: "Must confer the `write` action at this room's scope.";
+        };
+        readonly expectedVersion: {
+            readonly type: "integer";
+            readonly minimum: 0;
+            readonly description: "Optional precondition. Omit to overwrite unconditionally; `0` means create-only and fails if the key exists. On mismatch the host returns `rooms/records/put:versionConflict` CARRYING THE CURRENT VERSION AND RECORD — a bare rejection would force a re-read, and between rejection and re-read the record can change again, so the pattern has no fixed point under contention.";
+        };
+        readonly sealed: {
+            readonly $ref: "#/$defs/SealedRecord";
+            readonly description: "REQUIRED on an `attributed` or `private` room. Mutually exclusive with `cleartext`.";
+        };
+        readonly cleartext: {
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["body"];
+            readonly description: "REQUIRED on an `open` room, where the host reads records and can therefore search them. Mutually exclusive with `sealed`. On this tier the record is not signed by its author: every member here is the writer's claim as the host stores it, provenance and expiry included.";
+            readonly properties: {
+                readonly title: {
+                    readonly type: "string";
+                    readonly maxLength: 512;
+                };
+                readonly description: {
+                    readonly type: "string";
+                    readonly maxLength: 2048;
+                };
+                readonly body: {
+                    readonly type: "string";
+                    readonly maxLength: 1048576;
+                };
+                readonly tags: {
+                    readonly type: "array";
+                    readonly items: {
+                        readonly type: "string";
+                        readonly maxLength: 64;
+                    };
+                    readonly maxItems: 32;
+                };
+                readonly basis: {
+                    readonly $ref: "#/$defs/RecordBasis";
+                    readonly description: "What kind of claim the record is. A writer SHOULD set it; an agent writer that does not know SHOULD write `inferred`. Provenance for display and weighting, never authority.";
+                };
+                readonly confidence: {
+                    readonly $ref: "#/$defs/RecordConfidence";
+                };
+                readonly evidence: {
+                    readonly $ref: "#/$defs/RecordEvidenceList";
+                };
+                readonly validFor: {
+                    readonly $ref: "#/$defs/PermittedUse";
+                };
+                readonly validUntil: {
+                    readonly $ref: "#/$defs/RecordValidUntil";
+                    readonly description: "When the writer stops standing behind the record as current. Readers hide the record once it has passed and show it only on explicit request. A host stores and serves it like any other cleartext member and MUST NOT act on it: it neither hides, refuses nor deletes an expired record.";
+                };
+            };
+        };
+        readonly blobs: {
+            readonly type: "array";
+            readonly minItems: 1;
+            readonly maxItems: 1;
+            readonly uniqueItems: true;
+            readonly items: {
+                readonly $ref: "#/$defs/BlobRef";
+            };
+            readonly description: "The blobs this record keeps alive: today at most one, the file the record carries. Cleartext on every tier, because the host must know which blobs a record references to refuse a record naming a blob it does not hold, to count usage, and to collect a blob no record names. Every blob named MUST have been committed in THIS room (rooms/blobs/upload/commit). An array so that several files per record is a later minor version rather than a reshaped member. Omit for a record with no file; a rewrite that omits it releases whatever blob the previous version named.";
+        };
+        readonly ext: {
+            readonly $ref: "#/$defs/Ext";
+            readonly description: "Ecosystem-defined extension members per SPEC.md §4.5.1.";
+        };
+    };
+    readonly $defs: {
+        readonly Response: {
+            readonly $anchor: "response";
+            readonly title: "Rooms Records Put — response payload";
+            readonly description: "Success response to rooms/records/put. Type https://trusttasks.org/spec/rooms/records/put/0.3#response.";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["key", "version"];
+            readonly properties: {
+                readonly key: {
+                    readonly type: "string";
+                    readonly maxLength: 512;
+                    readonly description: "The stored record's key.";
+                };
+                readonly version: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The version assigned, monotonic per room.";
+                };
+                readonly epoch: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The epoch the record was stored under.";
+                };
+                readonly ext: {
+                    readonly $ref: "#/$defs/Ext";
+                };
+            };
+        };
+        readonly Ext: {
+            readonly title: "Ext";
+            readonly 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.";
+            readonly type: "object";
+            readonly minProperties: 1;
+            readonly additionalProperties: true;
+            readonly propertyNames: {
+                readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+            };
+        };
+        readonly BlobRef: {
+            readonly title: "BlobRef";
+            readonly description: "The name of one blob: the digest of its BlobManifest, taken over the manifest's RFC 8785 (JCS) canonicalization. sha2-256 is RECOMMENDED and MUST be implemented. Content addressing over ciphertext, never plaintext, so a BlobRef says nothing about what the file contains, and two uploads of one file have different BlobRefs (a fresh `fileId` gives a different key, and so different ciphertext). Rooms cannot be correlated by the files they share. Compared as decoded multihash bytes, never as encoded strings. A BlobRef is defined over the manifest's JSON, as this schema states it and RFC 8785 canonicalizes it, never over any binding's generated type: two bindings that model the manifest as distinct types still compute the same BlobRef from the same JSON.";
+            readonly $ref: "#/$defs/DigestMultibase";
+        };
+        readonly DigestMultibase: {
+            readonly title: "DigestMultibase";
+            readonly 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`.";
+            readonly type: "string";
+            readonly minLength: 16;
+            readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+            readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+        };
+        readonly RecordValidUntil: {
+            readonly title: "RecordValidUntil";
+            readonly type: "string";
+            readonly format: "date-time";
+            readonly description: "The instant after which the record's author no longer stands behind it as current. OPTIONAL; absent means the record does not expire. A reader hides a record whose `validUntil` has passed from default listings, search and recall, and shows it only on explicit request (`SealedRecordBody`, **Expiry**). No host enforces it.";
+        };
+        readonly PermittedUse: {
+            readonly title: "PermittedUse";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly minProperties: 1;
+            readonly description: "What the author permits the record to be used for — for example, that a learner's record is for instructional personalisation only. OPTIONAL; absent means the author stated no limit beyond the room's own terms.\n\n**Two halves, because purpose has both a machine and a human reading.** `purposes` names purposes by IRI, so that an agent can match them without parsing prose; `note` says it in words, for the nuance an identifier cannot carry. Either may be given alone.\n\n**No vocabulary of this family's own.** Purpose vocabularies exist and are maintained elsewhere — the W3C Data Privacy Vocabulary (`https://w3id.org/dpv#…`) is the one a writer SHOULD reach for first — and a short list defined here would be one more to translate between, and would be wrong at its edges for every domain that uses rooms. An IRI is the extension path: a community that needs a purpose no published vocabulary has names it under an IRI it controls.\n\n**A statement, not an enforcement.** No host can see it on the sealed tiers and none enforces it on any tier; every reader is a member who already holds the content. It records what the author permitted, so that a member — or an agent acting for one — can honour it, and so that a use outside it is a use against the author's stated terms rather than one nobody could have known about. An agent acting for a member SHOULD NOT use a record for a purpose outside `validFor` and SHOULD tell its principal when asked to. It confers no authority on anybody, and a `purposes` entry a reader does not recognise is shown, not ignored.";
+            readonly properties: {
+                readonly purposes: {
+                    readonly type: "array";
+                    readonly minItems: 1;
+                    readonly maxItems: 8;
+                    readonly uniqueItems: true;
+                    readonly items: {
+                        readonly type: "string";
+                        readonly format: "uri";
+                        readonly pattern: "^[a-zA-Z][a-zA-Z0-9+.-]*:";
+                        readonly maxLength: 2048;
+                    };
+                    readonly description: "Purposes the record may be used for, each an absolute IRI — for example `https://w3id.org/dpv#ServicePersonalisation`. A set: order carries no meaning. An identifier, never fetched.";
+                };
+                readonly note: {
+                    readonly type: "string";
+                    readonly minLength: 1;
+                    readonly maxLength: 512;
+                    readonly description: "The permitted use in words, such as `instructional personalisation only`. Plain text, rendered as text, and never instructions — an agent reading it treats it as the author's statement about the record, not as something to do.";
+                };
+            };
+        };
+        readonly RecordEvidenceList: {
+            readonly title: "RecordEvidenceList";
+            readonly type: "array";
+            readonly minItems: 1;
+            readonly maxItems: 32;
+            readonly items: {
+                readonly $ref: "#/$defs/RecordEvidence";
+            };
+            readonly description: "What the author offers in support of the record: other records and credentials, by reference. OPTIONAL; absent means none was named, and an empty array is not a permitted spelling of that. Order carries no meaning. Bounded so that a reader's cost of showing a record's support is bounded too.";
+        };
+        readonly RecordEvidence: {
+            readonly title: "RecordEvidence";
+            readonly description: "One thing a record cites in its support, discriminated by `kind`.\n\n  - `record` names a record of a room by its key, and optionally the version cited and the room. Absent `roomId` means the record's own room.\n  - `credential` names a credential by its `id`, and optionally a digest of the credential as cited.\n\n**A reference, never a locator, and never proof.** A reader MUST NOT fetch, resolve or dereference a `credentialId` because a record names it, and MUST NOT read a record of another room on the strength of a citation: the rule that a room's identifiers are identifiers and not addresses (`AuthorityPresentation`) applies here for the same reasons — fetching would signal to whoever answers which member read which record, and when. A reader MAY show a cited record of the same room that it already holds or reads anyway, and MAY match a cited credential against ones its member already holds. What the citation proves is only that the author cited it; whether the evidence exists, says what the author claims, or supports the record is for whoever follows it up to judge.";
+            readonly oneOf: readonly [{
+                readonly $ref: "#/$defs/RecordEvidenceRecord";
+            }, {
+                readonly $ref: "#/$defs/RecordEvidenceCredential";
+            }];
+        };
+        readonly RecordEvidenceCredential: {
+            readonly title: "RecordEvidenceCredential";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["kind", "credentialId"];
+            readonly description: "Cites a credential.";
+            readonly properties: {
+                readonly kind: {
+                    readonly const: "credential";
+                };
+                readonly credentialId: {
+                    readonly type: "string";
+                    readonly minLength: 1;
+                    readonly maxLength: 2048;
+                    readonly description: "The credential's `id`. An identifier: never fetched because a record names it.";
+                };
+                readonly digest: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                    readonly description: "OPTIONAL. A digest of the credential as cited — the SHA-256 multihash of its RFC 8785 (JCS) canonicalization, `proof` included — so a reader holding a credential with this `id` can tell whether it is the one the author meant.";
+                };
+            };
+        };
+        readonly RecordEvidenceRecord: {
+            readonly title: "RecordEvidenceRecord";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["kind", "key"];
+            readonly description: "Cites a record of a room.";
+            readonly properties: {
+                readonly kind: {
+                    readonly const: "record";
+                };
+                readonly key: {
+                    readonly type: "string";
+                    readonly minLength: 1;
+                    readonly maxLength: 512;
+                    readonly description: "The cited record's key, as in `rooms/records/put`. Opaque on the sealed tiers, like every key there.";
+                };
+                readonly version: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The version cited. OPTIONAL; present, it pins the citation to what the record said then, since a record can be rewritten under the same key. A reader that shows a later version SHOULD say that it is not the one cited.";
+                };
+                readonly roomId: {
+                    readonly type: "string";
+                    readonly pattern: "^did:";
+                    readonly maxLength: 2048;
+                    readonly description: "The cited record's room. Absent means the citing record's own room. A citation into another room tells the reader that room's identifier, so a writer SHOULD NOT cite into a room the citing room's readers are not meant to learn of.";
+                };
+            };
+        };
+        readonly RecordConfidence: {
+            readonly title: "RecordConfidence";
+            readonly type: "number";
+            readonly minimum: 0;
+            readonly maximum: 1;
+            readonly description: "The author's own estimate, from 0 to 1, that what the record says is correct. OPTIONAL; absent means no estimate was given, never 1. Meaningful only beside the author who gave it: two writers' numbers are not on one scale, so a reader MUST NOT rank records by `confidence` across authors as though they were, and an agent that weights by it SHOULD weight within an author's own records. Never authority.";
+        };
+        readonly RecordBasis: {
+            readonly title: "RecordBasis";
+            readonly type: "string";
+            readonly enum: readonly ["declared", "observed", "verified", "inferred"];
+            readonly description: "What kind of claim a record is, as its author states it. OPTIONAL wherever it appears; absent means the author did not say, and a reader shows it as unstated rather than assuming any of these.\n\n  - `declared` — the author's own statement: a decision, a preference, an intention, a commitment. True because the author says so, and only as far as the author speaks for it.\n  - `observed` — something the author saw, measured or was told directly, recorded as found.\n  - `verified` — checked against evidence that somebody else can check again, such as a credential or another record. A record that says `verified` SHOULD name that evidence in `evidence`; one that does not is an unsupported claim to have checked, and a reader SHOULD present it so.\n  - `inferred` — derived by reasoning from other information: an agent's conclusion, a summary's generalisation, a model's guess. The value an agent writer uses when it does not know which of the others applies.\n\nThe values are the author's account of their own record, signed with it. They are not checked by anybody, confer nothing, and say nothing about whether the record is right — `inferred` can be correct and `observed` mistaken. Aligned with the provenance vocabulary of personal agent memory, so that a record moved between a member's memory and a room keeps its meaning.";
+        };
+        readonly SealedRecord: {
+            readonly title: "SealedRecord";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["ciphertext", "nonce", "epoch"];
+            readonly description: "A record as a host stores it on an `attributed` or `private` room. Title, description, body, author and tags are sealed together in one blob rather than separately: splitting them would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.";
+            readonly properties: {
+                readonly ciphertext: {
+                    readonly type: "string";
+                    readonly description: "The sealed record, base64url. Bound by AEAD associated data to `roomId`, `key`, the version it was sealed at, and `epoch`, so a host that relocates it to another key, version, epoch or room produces a mismatch and the open fails. The record cannot be moved undetected even though the host holds every byte of it. The version it was sealed at is `version` below where present, and the record's own `version` otherwise.";
+                };
+                readonly nonce: {
+                    readonly type: "string";
+                    readonly description: "AEAD nonce, base64url.";
+                };
+                readonly epoch: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The key epoch this record was sealed under. Cleartext because the host must serve the right ciphertext, and bound into the associated data so that relabelling it fails authentication rather than causing a reader to try the wrong key.";
+                };
+                readonly version: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The version this ciphertext was sealed at, where that is no longer the record's own `version`. A record's version moves when it is curated (`rooms/records/curate`, which MUST assign a new one so that every `sinceVersion` watermark sees the change), but a curation other than a retraction keeps the body — and the body is bound, by the AEAD and by its author's signature (`SealedRecordBody`), to the version it was written at. Without this member a curated record would be opened at a version it was never sealed for, and would not open for anyone.\n\nA host MUST record the version a body was sealed at when it stores it, MUST NOT change it while that body is kept — a curation alters a record's standing, never its sealed content — and MUST include it whenever it differs from the record's `version`. It is absent where the two are equal, which is every record that has not been curated since it was written, so the members a record carries are unchanged until a curation needs this one. It is part of `sealed`, and so of the record the data commitment covers (`CommittedRecord`): a host cannot change it without changing the root.\n\nA reader opens and verifies the body at this version, and MUST refuse a record whose `sealed.version` is greater than its own `version` — a body cannot have been sealed for a version the room had not reached. A host that pairs a newer version with an older body of the same key is rolling the record back; that is a change to the committed record like any other, visible to the comparisons `CommittedRecord` exists for.";
+                };
+            };
+        };
+        readonly AuthorityPresentation: {
+            readonly title: "AuthorityPresentation";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["membership", "authority"];
+            readonly description: "What a party presents to act on a room. Carries the whole authority chain: a host MUST NOT dereference an authority credential's `parent` to fetch a link it was not given. Resolving over the network would make verification depend on availability, turn every identifier into a request the host can be induced to make against an address the holder chooses, and signal credential use to whoever hosts the identifier. A host MUST bind the presenter to the chain's leaf. A chain that verifies is evidence that authority was conferred on somebody; it is not evidence that the party presenting it is that somebody. The leaf's subject MUST equal the party the host authenticated for this request — an identity the transport established or a document `proof` proved, never one named in a payload. A host that omits this check authorizes every captured presentation, and the omission is silent, because the chain still verifies.\n\n**Every credential is its issuer's attestation, and only its issuer's.** For the membership credential and for every link of `authority`, a host MUST verify the credential's `proof` with a key that the credential's own `issuer` lists for `assertionMethod` in its DID document, and MUST refuse a credential whose proof names a verification method that is not its issuer's. A proof that verifies under some other party's key is that party's statement, not the issuer's, and confers nothing. The same binding holds for every other document a room signs, such as a `RevocationList`.\n\n**A chain that verifies may still be revoked.** A host that has accepted a `RevocationList` for the room (`rooms/revocations/put`) MUST, from the moment it accepted it, refuse every presentation in which the membership credential or any link of `authority` is revoked by that list, under every task and every version of every task it serves for the room. A chain from which any link is revoked is refused whole: a credential delegated from a revoked one confers nothing, however it was attenuated. The refusal is the same `permissionDenied` as any other failed presentation.";
+            readonly properties: {
+                readonly membership: {
+                    readonly type: "string";
+                    readonly description: "The presenter's membership credential for this room, or — on a `private` room — a zero-knowledge presentation of it. Serialized per the governing profile.";
+                };
+                readonly authority: {
+                    readonly type: "array";
+                    readonly minItems: 1;
+                    readonly maxItems: 8;
+                    readonly items: {
+                        readonly type: "string";
+                    };
+                    readonly description: "The authority chain, LEAF FIRST: the first element is the credential being relied on and the last MUST be one issued by the room itself. Every link the presenter relies on is present, because the host will not fetch one. Capped at 8: verification is linear in chain length and runs on every operation, so an unbounded chain is a denial-of-service surface against the host. The known uses need 2 to 3 — a person attenuating to an agent, and that agent to a sub-agent.";
+                };
+                readonly subjectBinding: {
+                    readonly type: "string";
+                    readonly description: "REQUIRED on a `private` room, where the subject identifier is withheld: a proof that the membership credential and the authority chain's leaf describe the SAME subject. Without it two parties pool credentials — one contributes membership, the other authority — and the combination verifies as a single party holding both. A host MUST refuse a private-room presentation that omits this.";
+                };
+            };
+        };
+    };
+};
+/** As {@link PAYLOAD_SCHEMA}, for the success-response variant. */
+export declare const RESPONSE_PAYLOAD_SCHEMA: {
+    readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+    readonly $ref: "#/$defs/Response";
+    readonly $defs: {
+        readonly Response: {
+            readonly $anchor: "response";
+            readonly title: "Rooms Records Put — response payload";
+            readonly description: "Success response to rooms/records/put. Type https://trusttasks.org/spec/rooms/records/put/0.3#response.";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["key", "version"];
+            readonly properties: {
+                readonly key: {
+                    readonly type: "string";
+                    readonly maxLength: 512;
+                    readonly description: "The stored record's key.";
+                };
+                readonly version: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The version assigned, monotonic per room.";
+                };
+                readonly epoch: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The epoch the record was stored under.";
+                };
+                readonly ext: {
+                    readonly $ref: "#/$defs/Ext";
+                };
+            };
+        };
+        readonly Ext: {
+            readonly title: "Ext";
+            readonly 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.";
+            readonly type: "object";
+            readonly minProperties: 1;
+            readonly additionalProperties: true;
+            readonly propertyNames: {
+                readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+            };
+        };
+        readonly BlobRef: {
+            readonly title: "BlobRef";
+            readonly description: "The name of one blob: the digest of its BlobManifest, taken over the manifest's RFC 8785 (JCS) canonicalization. sha2-256 is RECOMMENDED and MUST be implemented. Content addressing over ciphertext, never plaintext, so a BlobRef says nothing about what the file contains, and two uploads of one file have different BlobRefs (a fresh `fileId` gives a different key, and so different ciphertext). Rooms cannot be correlated by the files they share. Compared as decoded multihash bytes, never as encoded strings. A BlobRef is defined over the manifest's JSON, as this schema states it and RFC 8785 canonicalizes it, never over any binding's generated type: two bindings that model the manifest as distinct types still compute the same BlobRef from the same JSON.";
+            readonly $ref: "#/$defs/DigestMultibase";
+        };
+        readonly DigestMultibase: {
+            readonly title: "DigestMultibase";
+            readonly 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`.";
+            readonly type: "string";
+            readonly minLength: 16;
+            readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+            readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+        };
+        readonly RecordValidUntil: {
+            readonly title: "RecordValidUntil";
+            readonly type: "string";
+            readonly format: "date-time";
+            readonly description: "The instant after which the record's author no longer stands behind it as current. OPTIONAL; absent means the record does not expire. A reader hides a record whose `validUntil` has passed from default listings, search and recall, and shows it only on explicit request (`SealedRecordBody`, **Expiry**). No host enforces it.";
+        };
+        readonly PermittedUse: {
+            readonly title: "PermittedUse";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly minProperties: 1;
+            readonly description: "What the author permits the record to be used for — for example, that a learner's record is for instructional personalisation only. OPTIONAL; absent means the author stated no limit beyond the room's own terms.\n\n**Two halves, because purpose has both a machine and a human reading.** `purposes` names purposes by IRI, so that an agent can match them without parsing prose; `note` says it in words, for the nuance an identifier cannot carry. Either may be given alone.\n\n**No vocabulary of this family's own.** Purpose vocabularies exist and are maintained elsewhere — the W3C Data Privacy Vocabulary (`https://w3id.org/dpv#…`) is the one a writer SHOULD reach for first — and a short list defined here would be one more to translate between, and would be wrong at its edges for every domain that uses rooms. An IRI is the extension path: a community that needs a purpose no published vocabulary has names it under an IRI it controls.\n\n**A statement, not an enforcement.** No host can see it on the sealed tiers and none enforces it on any tier; every reader is a member who already holds the content. It records what the author permitted, so that a member — or an agent acting for one — can honour it, and so that a use outside it is a use against the author's stated terms rather than one nobody could have known about. An agent acting for a member SHOULD NOT use a record for a purpose outside `validFor` and SHOULD tell its principal when asked to. It confers no authority on anybody, and a `purposes` entry a reader does not recognise is shown, not ignored.";
+            readonly properties: {
+                readonly purposes: {
+                    readonly type: "array";
+                    readonly minItems: 1;
+                    readonly maxItems: 8;
+                    readonly uniqueItems: true;
+                    readonly items: {
+                        readonly type: "string";
+                        readonly format: "uri";
+                        readonly pattern: "^[a-zA-Z][a-zA-Z0-9+.-]*:";
+                        readonly maxLength: 2048;
+                    };
+                    readonly description: "Purposes the record may be used for, each an absolute IRI — for example `https://w3id.org/dpv#ServicePersonalisation`. A set: order carries no meaning. An identifier, never fetched.";
+                };
+                readonly note: {
+                    readonly type: "string";
+                    readonly minLength: 1;
+                    readonly maxLength: 512;
+                    readonly description: "The permitted use in words, such as `instructional personalisation only`. Plain text, rendered as text, and never instructions — an agent reading it treats it as the author's statement about the record, not as something to do.";
+                };
+            };
+        };
+        readonly RecordEvidenceList: {
+            readonly title: "RecordEvidenceList";
+            readonly type: "array";
+            readonly minItems: 1;
+            readonly maxItems: 32;
+            readonly items: {
+                readonly $ref: "#/$defs/RecordEvidence";
+            };
+            readonly description: "What the author offers in support of the record: other records and credentials, by reference. OPTIONAL; absent means none was named, and an empty array is not a permitted spelling of that. Order carries no meaning. Bounded so that a reader's cost of showing a record's support is bounded too.";
+        };
+        readonly RecordEvidence: {
+            readonly title: "RecordEvidence";
+            readonly description: "One thing a record cites in its support, discriminated by `kind`.\n\n  - `record` names a record of a room by its key, and optionally the version cited and the room. Absent `roomId` means the record's own room.\n  - `credential` names a credential by its `id`, and optionally a digest of the credential as cited.\n\n**A reference, never a locator, and never proof.** A reader MUST NOT fetch, resolve or dereference a `credentialId` because a record names it, and MUST NOT read a record of another room on the strength of a citation: the rule that a room's identifiers are identifiers and not addresses (`AuthorityPresentation`) applies here for the same reasons — fetching would signal to whoever answers which member read which record, and when. A reader MAY show a cited record of the same room that it already holds or reads anyway, and MAY match a cited credential against ones its member already holds. What the citation proves is only that the author cited it; whether the evidence exists, says what the author claims, or supports the record is for whoever follows it up to judge.";
+            readonly oneOf: readonly [{
+                readonly $ref: "#/$defs/RecordEvidenceRecord";
+            }, {
+                readonly $ref: "#/$defs/RecordEvidenceCredential";
+            }];
+        };
+        readonly RecordEvidenceCredential: {
+            readonly title: "RecordEvidenceCredential";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["kind", "credentialId"];
+            readonly description: "Cites a credential.";
+            readonly properties: {
+                readonly kind: {
+                    readonly const: "credential";
+                };
+                readonly credentialId: {
+                    readonly type: "string";
+                    readonly minLength: 1;
+                    readonly maxLength: 2048;
+                    readonly description: "The credential's `id`. An identifier: never fetched because a record names it.";
+                };
+                readonly digest: {
+                    readonly $ref: "#/$defs/DigestMultibase";
+                    readonly description: "OPTIONAL. A digest of the credential as cited — the SHA-256 multihash of its RFC 8785 (JCS) canonicalization, `proof` included — so a reader holding a credential with this `id` can tell whether it is the one the author meant.";
+                };
+            };
+        };
+        readonly RecordEvidenceRecord: {
+            readonly title: "RecordEvidenceRecord";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["kind", "key"];
+            readonly description: "Cites a record of a room.";
+            readonly properties: {
+                readonly kind: {
+                    readonly const: "record";
+                };
+                readonly key: {
+                    readonly type: "string";
+                    readonly minLength: 1;
+                    readonly maxLength: 512;
+                    readonly description: "The cited record's key, as in `rooms/records/put`. Opaque on the sealed tiers, like every key there.";
+                };
+                readonly version: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The version cited. OPTIONAL; present, it pins the citation to what the record said then, since a record can be rewritten under the same key. A reader that shows a later version SHOULD say that it is not the one cited.";
+                };
+                readonly roomId: {
+                    readonly type: "string";
+                    readonly pattern: "^did:";
+                    readonly maxLength: 2048;
+                    readonly description: "The cited record's room. Absent means the citing record's own room. A citation into another room tells the reader that room's identifier, so a writer SHOULD NOT cite into a room the citing room's readers are not meant to learn of.";
+                };
+            };
+        };
+        readonly RecordConfidence: {
+            readonly title: "RecordConfidence";
+            readonly type: "number";
+            readonly minimum: 0;
+            readonly maximum: 1;
+            readonly description: "The author's own estimate, from 0 to 1, that what the record says is correct. OPTIONAL; absent means no estimate was given, never 1. Meaningful only beside the author who gave it: two writers' numbers are not on one scale, so a reader MUST NOT rank records by `confidence` across authors as though they were, and an agent that weights by it SHOULD weight within an author's own records. Never authority.";
+        };
+        readonly RecordBasis: {
+            readonly title: "RecordBasis";
+            readonly type: "string";
+            readonly enum: readonly ["declared", "observed", "verified", "inferred"];
+            readonly description: "What kind of claim a record is, as its author states it. OPTIONAL wherever it appears; absent means the author did not say, and a reader shows it as unstated rather than assuming any of these.\n\n  - `declared` — the author's own statement: a decision, a preference, an intention, a commitment. True because the author says so, and only as far as the author speaks for it.\n  - `observed` — something the author saw, measured or was told directly, recorded as found.\n  - `verified` — checked against evidence that somebody else can check again, such as a credential or another record. A record that says `verified` SHOULD name that evidence in `evidence`; one that does not is an unsupported claim to have checked, and a reader SHOULD present it so.\n  - `inferred` — derived by reasoning from other information: an agent's conclusion, a summary's generalisation, a model's guess. The value an agent writer uses when it does not know which of the others applies.\n\nThe values are the author's account of their own record, signed with it. They are not checked by anybody, confer nothing, and say nothing about whether the record is right — `inferred` can be correct and `observed` mistaken. Aligned with the provenance vocabulary of personal agent memory, so that a record moved between a member's memory and a room keeps its meaning.";
+        };
+        readonly SealedRecord: {
+            readonly title: "SealedRecord";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["ciphertext", "nonce", "epoch"];
+            readonly description: "A record as a host stores it on an `attributed` or `private` room. Title, description, body, author and tags are sealed together in one blob rather than separately: splitting them would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.";
+            readonly properties: {
+                readonly ciphertext: {
+                    readonly type: "string";
+                    readonly description: "The sealed record, base64url. Bound by AEAD associated data to `roomId`, `key`, the version it was sealed at, and `epoch`, so a host that relocates it to another key, version, epoch or room produces a mismatch and the open fails. The record cannot be moved undetected even though the host holds every byte of it. The version it was sealed at is `version` below where present, and the record's own `version` otherwise.";
+                };
+                readonly nonce: {
+                    readonly type: "string";
+                    readonly description: "AEAD nonce, base64url.";
+                };
+                readonly epoch: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The key epoch this record was sealed under. Cleartext because the host must serve the right ciphertext, and bound into the associated data so that relabelling it fails authentication rather than causing a reader to try the wrong key.";
+                };
+                readonly version: {
+                    readonly type: "integer";
+                    readonly minimum: 1;
+                    readonly description: "The version this ciphertext was sealed at, where that is no longer the record's own `version`. A record's version moves when it is curated (`rooms/records/curate`, which MUST assign a new one so that every `sinceVersion` watermark sees the change), but a curation other than a retraction keeps the body — and the body is bound, by the AEAD and by its author's signature (`SealedRecordBody`), to the version it was written at. Without this member a curated record would be opened at a version it was never sealed for, and would not open for anyone.\n\nA host MUST record the version a body was sealed at when it stores it, MUST NOT change it while that body is kept — a curation alters a record's standing, never its sealed content — and MUST include it whenever it differs from the record's `version`. It is absent where the two are equal, which is every record that has not been curated since it was written, so the members a record carries are unchanged until a curation needs this one. It is part of `sealed`, and so of the record the data commitment covers (`CommittedRecord`): a host cannot change it without changing the root.\n\nA reader opens and verifies the body at this version, and MUST refuse a record whose `sealed.version` is greater than its own `version` — a body cannot have been sealed for a version the room had not reached. A host that pairs a newer version with an older body of the same key is rolling the record back; that is a change to the committed record like any other, visible to the comparisons `CommittedRecord` exists for.";
+                };
+            };
+        };
+        readonly AuthorityPresentation: {
+            readonly title: "AuthorityPresentation";
+            readonly type: "object";
+            readonly additionalProperties: false;
+            readonly required: readonly ["membership", "authority"];
+            readonly description: "What a party presents to act on a room. Carries the whole authority chain: a host MUST NOT dereference an authority credential's `parent` to fetch a link it was not given. Resolving over the network would make verification depend on availability, turn every identifier into a request the host can be induced to make against an address the holder chooses, and signal credential use to whoever hosts the identifier. A host MUST bind the presenter to the chain's leaf. A chain that verifies is evidence that authority was conferred on somebody; it is not evidence that the party presenting it is that somebody. The leaf's subject MUST equal the party the host authenticated for this request — an identity the transport established or a document `proof` proved, never one named in a payload. A host that omits this check authorizes every captured presentation, and the omission is silent, because the chain still verifies.\n\n**Every credential is its issuer's attestation, and only its issuer's.** For the membership credential and for every link of `authority`, a host MUST verify the credential's `proof` with a key that the credential's own `issuer` lists for `assertionMethod` in its DID document, and MUST refuse a credential whose proof names a verification method that is not its issuer's. A proof that verifies under some other party's key is that party's statement, not the issuer's, and confers nothing. The same binding holds for every other document a room signs, such as a `RevocationList`.\n\n**A chain that verifies may still be revoked.** A host that has accepted a `RevocationList` for the room (`rooms/revocations/put`) MUST, from the moment it accepted it, refuse every presentation in which the membership credential or any link of `authority` is revoked by that list, under every task and every version of every task it serves for the room. A chain from which any link is revoked is refused whole: a credential delegated from a revoked one confers nothing, however it was attenuated. The refusal is the same `permissionDenied` as any other failed presentation.";
+            readonly properties: {
+                readonly membership: {
+                    readonly type: "string";
+                    readonly description: "The presenter's membership credential for this room, or — on a `private` room — a zero-knowledge presentation of it. Serialized per the governing profile.";
+                };
+                readonly authority: {
+                    readonly type: "array";
+                    readonly minItems: 1;
+                    readonly maxItems: 8;
+                    readonly items: {
+                        readonly type: "string";
+                    };
+                    readonly description: "The authority chain, LEAF FIRST: the first element is the credential being relied on and the last MUST be one issued by the room itself. Every link the presenter relies on is present, because the host will not fetch one. Capped at 8: verification is linear in chain length and runs on every operation, so an unbounded chain is a denial-of-service surface against the host. The known uses need 2 to 3 — a person attenuating to an agent, and that agent to a sub-agent.";
+                };
+                readonly subjectBinding: {
+                    readonly type: "string";
+                    readonly description: "REQUIRED on a `private` room, where the subject identifier is withheld: a proof that the membership credential and the authority chain's leaf describe the SAME subject. Without it two parties pool credentials — one contributes membership, the other authority — and the combination verifies as a single party holding both. A host MUST refuse a private-room presentation that omits this.";
+                };
+            };
+        };
+    };
+};
+/**
+ * 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 declare const SPEC: {
+    readonly typeUri: "https://trusttasks.org/spec/rooms/records/put/0.3";
+    readonly isBearer: false;
+    readonly isProofRequired: true;
+    readonly isRecipientRequired: true;
+    readonly isIssuedAtRequired: true;
+    readonly payloadSchema: {
+        readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+        readonly $id: "https://trusttasks.org/spec/rooms/records/put/0.3";
+        readonly title: "Rooms Records Put — payload";
+        readonly description: "A member writes a record to a data room, authorized by an authority chain the room itself issued. 0.2 added `blobs`: a record can carry a file, whose ciphertext the host stores outside the record and whose description is sealed inside it. 0.3 lets an `open` room's `cleartext` carry the record's provenance — `basis`, `confidence`, `evidence`, `validFor` — and its `validUntil`, which the sealed tiers carry inside the signed `SealedRecordBody`.";
+        readonly type: "object";
+        readonly additionalProperties: false;
+        readonly required: readonly ["roomId", "key", "presentation"];
+        readonly properties: {
+            readonly roomId: {
+                readonly type: "string";
+                readonly description: "The room's identifier. A host verifies the presentation against credentials issued by this identifier, never against a member list of its own — which is what lets a room move hosts without reissuing a credential.";
+            };
+            readonly key: {
+                readonly type: "string";
+                readonly maxLength: 512;
+                readonly description: "The record's key within the room. MUST be opaque on an `attributed` or `private` room; see RecordMetadata.key.";
+            };
+            readonly presentation: {
+                readonly $ref: "#/$defs/AuthorityPresentation";
+                readonly description: "Must confer the `write` action at this room's scope.";
+            };
+            readonly expectedVersion: {
+                readonly type: "integer";
+                readonly minimum: 0;
+                readonly description: "Optional precondition. Omit to overwrite unconditionally; `0` means create-only and fails if the key exists. On mismatch the host returns `rooms/records/put:versionConflict` CARRYING THE CURRENT VERSION AND RECORD — a bare rejection would force a re-read, and between rejection and re-read the record can change again, so the pattern has no fixed point under contention.";
+            };
+            readonly sealed: {
+                readonly $ref: "#/$defs/SealedRecord";
+                readonly description: "REQUIRED on an `attributed` or `private` room. Mutually exclusive with `cleartext`.";
+            };
+            readonly cleartext: {
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["body"];
+                readonly description: "REQUIRED on an `open` room, where the host reads records and can therefore search them. Mutually exclusive with `sealed`. On this tier the record is not signed by its author: every member here is the writer's claim as the host stores it, provenance and expiry included.";
+                readonly properties: {
+                    readonly title: {
+                        readonly type: "string";
+                        readonly maxLength: 512;
+                    };
+                    readonly description: {
+                        readonly type: "string";
+                        readonly maxLength: 2048;
+                    };
+                    readonly body: {
+                        readonly type: "string";
+                        readonly maxLength: 1048576;
+                    };
+                    readonly tags: {
+                        readonly type: "array";
+                        readonly items: {
+                            readonly type: "string";
+                            readonly maxLength: 64;
+                        };
+                        readonly maxItems: 32;
+                    };
+                    readonly basis: {
+                        readonly $ref: "#/$defs/RecordBasis";
+                        readonly description: "What kind of claim the record is. A writer SHOULD set it; an agent writer that does not know SHOULD write `inferred`. Provenance for display and weighting, never authority.";
+                    };
+                    readonly confidence: {
+                        readonly $ref: "#/$defs/RecordConfidence";
+                    };
+                    readonly evidence: {
+                        readonly $ref: "#/$defs/RecordEvidenceList";
+                    };
+                    readonly validFor: {
+                        readonly $ref: "#/$defs/PermittedUse";
+                    };
+                    readonly validUntil: {
+                        readonly $ref: "#/$defs/RecordValidUntil";
+                        readonly description: "When the writer stops standing behind the record as current. Readers hide the record once it has passed and show it only on explicit request. A host stores and serves it like any other cleartext member and MUST NOT act on it: it neither hides, refuses nor deletes an expired record.";
+                    };
+                };
+            };
+            readonly blobs: {
+                readonly type: "array";
+                readonly minItems: 1;
+                readonly maxItems: 1;
+                readonly uniqueItems: true;
+                readonly items: {
+                    readonly $ref: "#/$defs/BlobRef";
+                };
+                readonly description: "The blobs this record keeps alive: today at most one, the file the record carries. Cleartext on every tier, because the host must know which blobs a record references to refuse a record naming a blob it does not hold, to count usage, and to collect a blob no record names. Every blob named MUST have been committed in THIS room (rooms/blobs/upload/commit). An array so that several files per record is a later minor version rather than a reshaped member. Omit for a record with no file; a rewrite that omits it releases whatever blob the previous version named.";
+            };
+            readonly ext: {
+                readonly $ref: "#/$defs/Ext";
+                readonly description: "Ecosystem-defined extension members per SPEC.md §4.5.1.";
+            };
+        };
+        readonly $defs: {
+            readonly Response: {
+                readonly $anchor: "response";
+                readonly title: "Rooms Records Put — response payload";
+                readonly description: "Success response to rooms/records/put. Type https://trusttasks.org/spec/rooms/records/put/0.3#response.";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["key", "version"];
+                readonly properties: {
+                    readonly key: {
+                        readonly type: "string";
+                        readonly maxLength: 512;
+                        readonly description: "The stored record's key.";
+                    };
+                    readonly version: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The version assigned, monotonic per room.";
+                    };
+                    readonly epoch: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The epoch the record was stored under.";
+                    };
+                    readonly ext: {
+                        readonly $ref: "#/$defs/Ext";
+                    };
+                };
+            };
+            readonly Ext: {
+                readonly title: "Ext";
+                readonly 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.";
+                readonly type: "object";
+                readonly minProperties: 1;
+                readonly additionalProperties: true;
+                readonly propertyNames: {
+                    readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+                };
+            };
+            readonly BlobRef: {
+                readonly title: "BlobRef";
+                readonly description: "The name of one blob: the digest of its BlobManifest, taken over the manifest's RFC 8785 (JCS) canonicalization. sha2-256 is RECOMMENDED and MUST be implemented. Content addressing over ciphertext, never plaintext, so a BlobRef says nothing about what the file contains, and two uploads of one file have different BlobRefs (a fresh `fileId` gives a different key, and so different ciphertext). Rooms cannot be correlated by the files they share. Compared as decoded multihash bytes, never as encoded strings. A BlobRef is defined over the manifest's JSON, as this schema states it and RFC 8785 canonicalizes it, never over any binding's generated type: two bindings that model the manifest as distinct types still compute the same BlobRef from the same JSON.";
+                readonly $ref: "#/$defs/DigestMultibase";
+            };
+            readonly DigestMultibase: {
+                readonly title: "DigestMultibase";
+                readonly 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`.";
+                readonly type: "string";
+                readonly minLength: 16;
+                readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+                readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+            };
+            readonly RecordValidUntil: {
+                readonly title: "RecordValidUntil";
+                readonly type: "string";
+                readonly format: "date-time";
+                readonly description: "The instant after which the record's author no longer stands behind it as current. OPTIONAL; absent means the record does not expire. A reader hides a record whose `validUntil` has passed from default listings, search and recall, and shows it only on explicit request (`SealedRecordBody`, **Expiry**). No host enforces it.";
+            };
+            readonly PermittedUse: {
+                readonly title: "PermittedUse";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly minProperties: 1;
+                readonly description: "What the author permits the record to be used for — for example, that a learner's record is for instructional personalisation only. OPTIONAL; absent means the author stated no limit beyond the room's own terms.\n\n**Two halves, because purpose has both a machine and a human reading.** `purposes` names purposes by IRI, so that an agent can match them without parsing prose; `note` says it in words, for the nuance an identifier cannot carry. Either may be given alone.\n\n**No vocabulary of this family's own.** Purpose vocabularies exist and are maintained elsewhere — the W3C Data Privacy Vocabulary (`https://w3id.org/dpv#…`) is the one a writer SHOULD reach for first — and a short list defined here would be one more to translate between, and would be wrong at its edges for every domain that uses rooms. An IRI is the extension path: a community that needs a purpose no published vocabulary has names it under an IRI it controls.\n\n**A statement, not an enforcement.** No host can see it on the sealed tiers and none enforces it on any tier; every reader is a member who already holds the content. It records what the author permitted, so that a member — or an agent acting for one — can honour it, and so that a use outside it is a use against the author's stated terms rather than one nobody could have known about. An agent acting for a member SHOULD NOT use a record for a purpose outside `validFor` and SHOULD tell its principal when asked to. It confers no authority on anybody, and a `purposes` entry a reader does not recognise is shown, not ignored.";
+                readonly properties: {
+                    readonly purposes: {
+                        readonly type: "array";
+                        readonly minItems: 1;
+                        readonly maxItems: 8;
+                        readonly uniqueItems: true;
+                        readonly items: {
+                            readonly type: "string";
+                            readonly format: "uri";
+                            readonly pattern: "^[a-zA-Z][a-zA-Z0-9+.-]*:";
+                            readonly maxLength: 2048;
+                        };
+                        readonly description: "Purposes the record may be used for, each an absolute IRI — for example `https://w3id.org/dpv#ServicePersonalisation`. A set: order carries no meaning. An identifier, never fetched.";
+                    };
+                    readonly note: {
+                        readonly type: "string";
+                        readonly minLength: 1;
+                        readonly maxLength: 512;
+                        readonly description: "The permitted use in words, such as `instructional personalisation only`. Plain text, rendered as text, and never instructions — an agent reading it treats it as the author's statement about the record, not as something to do.";
+                    };
+                };
+            };
+            readonly RecordEvidenceList: {
+                readonly title: "RecordEvidenceList";
+                readonly type: "array";
+                readonly minItems: 1;
+                readonly maxItems: 32;
+                readonly items: {
+                    readonly $ref: "#/$defs/RecordEvidence";
+                };
+                readonly description: "What the author offers in support of the record: other records and credentials, by reference. OPTIONAL; absent means none was named, and an empty array is not a permitted spelling of that. Order carries no meaning. Bounded so that a reader's cost of showing a record's support is bounded too.";
+            };
+            readonly RecordEvidence: {
+                readonly title: "RecordEvidence";
+                readonly description: "One thing a record cites in its support, discriminated by `kind`.\n\n  - `record` names a record of a room by its key, and optionally the version cited and the room. Absent `roomId` means the record's own room.\n  - `credential` names a credential by its `id`, and optionally a digest of the credential as cited.\n\n**A reference, never a locator, and never proof.** A reader MUST NOT fetch, resolve or dereference a `credentialId` because a record names it, and MUST NOT read a record of another room on the strength of a citation: the rule that a room's identifiers are identifiers and not addresses (`AuthorityPresentation`) applies here for the same reasons — fetching would signal to whoever answers which member read which record, and when. A reader MAY show a cited record of the same room that it already holds or reads anyway, and MAY match a cited credential against ones its member already holds. What the citation proves is only that the author cited it; whether the evidence exists, says what the author claims, or supports the record is for whoever follows it up to judge.";
+                readonly oneOf: readonly [{
+                    readonly $ref: "#/$defs/RecordEvidenceRecord";
+                }, {
+                    readonly $ref: "#/$defs/RecordEvidenceCredential";
+                }];
+            };
+            readonly RecordEvidenceCredential: {
+                readonly title: "RecordEvidenceCredential";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["kind", "credentialId"];
+                readonly description: "Cites a credential.";
+                readonly properties: {
+                    readonly kind: {
+                        readonly const: "credential";
+                    };
+                    readonly credentialId: {
+                        readonly type: "string";
+                        readonly minLength: 1;
+                        readonly maxLength: 2048;
+                        readonly description: "The credential's `id`. An identifier: never fetched because a record names it.";
+                    };
+                    readonly digest: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                        readonly description: "OPTIONAL. A digest of the credential as cited — the SHA-256 multihash of its RFC 8785 (JCS) canonicalization, `proof` included — so a reader holding a credential with this `id` can tell whether it is the one the author meant.";
+                    };
+                };
+            };
+            readonly RecordEvidenceRecord: {
+                readonly title: "RecordEvidenceRecord";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["kind", "key"];
+                readonly description: "Cites a record of a room.";
+                readonly properties: {
+                    readonly kind: {
+                        readonly const: "record";
+                    };
+                    readonly key: {
+                        readonly type: "string";
+                        readonly minLength: 1;
+                        readonly maxLength: 512;
+                        readonly description: "The cited record's key, as in `rooms/records/put`. Opaque on the sealed tiers, like every key there.";
+                    };
+                    readonly version: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The version cited. OPTIONAL; present, it pins the citation to what the record said then, since a record can be rewritten under the same key. A reader that shows a later version SHOULD say that it is not the one cited.";
+                    };
+                    readonly roomId: {
+                        readonly type: "string";
+                        readonly pattern: "^did:";
+                        readonly maxLength: 2048;
+                        readonly description: "The cited record's room. Absent means the citing record's own room. A citation into another room tells the reader that room's identifier, so a writer SHOULD NOT cite into a room the citing room's readers are not meant to learn of.";
+                    };
+                };
+            };
+            readonly RecordConfidence: {
+                readonly title: "RecordConfidence";
+                readonly type: "number";
+                readonly minimum: 0;
+                readonly maximum: 1;
+                readonly description: "The author's own estimate, from 0 to 1, that what the record says is correct. OPTIONAL; absent means no estimate was given, never 1. Meaningful only beside the author who gave it: two writers' numbers are not on one scale, so a reader MUST NOT rank records by `confidence` across authors as though they were, and an agent that weights by it SHOULD weight within an author's own records. Never authority.";
+            };
+            readonly RecordBasis: {
+                readonly title: "RecordBasis";
+                readonly type: "string";
+                readonly enum: readonly ["declared", "observed", "verified", "inferred"];
+                readonly description: "What kind of claim a record is, as its author states it. OPTIONAL wherever it appears; absent means the author did not say, and a reader shows it as unstated rather than assuming any of these.\n\n  - `declared` — the author's own statement: a decision, a preference, an intention, a commitment. True because the author says so, and only as far as the author speaks for it.\n  - `observed` — something the author saw, measured or was told directly, recorded as found.\n  - `verified` — checked against evidence that somebody else can check again, such as a credential or another record. A record that says `verified` SHOULD name that evidence in `evidence`; one that does not is an unsupported claim to have checked, and a reader SHOULD present it so.\n  - `inferred` — derived by reasoning from other information: an agent's conclusion, a summary's generalisation, a model's guess. The value an agent writer uses when it does not know which of the others applies.\n\nThe values are the author's account of their own record, signed with it. They are not checked by anybody, confer nothing, and say nothing about whether the record is right — `inferred` can be correct and `observed` mistaken. Aligned with the provenance vocabulary of personal agent memory, so that a record moved between a member's memory and a room keeps its meaning.";
+            };
+            readonly SealedRecord: {
+                readonly title: "SealedRecord";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["ciphertext", "nonce", "epoch"];
+                readonly description: "A record as a host stores it on an `attributed` or `private` room. Title, description, body, author and tags are sealed together in one blob rather than separately: splitting them would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.";
+                readonly properties: {
+                    readonly ciphertext: {
+                        readonly type: "string";
+                        readonly description: "The sealed record, base64url. Bound by AEAD associated data to `roomId`, `key`, the version it was sealed at, and `epoch`, so a host that relocates it to another key, version, epoch or room produces a mismatch and the open fails. The record cannot be moved undetected even though the host holds every byte of it. The version it was sealed at is `version` below where present, and the record's own `version` otherwise.";
+                    };
+                    readonly nonce: {
+                        readonly type: "string";
+                        readonly description: "AEAD nonce, base64url.";
+                    };
+                    readonly epoch: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The key epoch this record was sealed under. Cleartext because the host must serve the right ciphertext, and bound into the associated data so that relabelling it fails authentication rather than causing a reader to try the wrong key.";
+                    };
+                    readonly version: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The version this ciphertext was sealed at, where that is no longer the record's own `version`. A record's version moves when it is curated (`rooms/records/curate`, which MUST assign a new one so that every `sinceVersion` watermark sees the change), but a curation other than a retraction keeps the body — and the body is bound, by the AEAD and by its author's signature (`SealedRecordBody`), to the version it was written at. Without this member a curated record would be opened at a version it was never sealed for, and would not open for anyone.\n\nA host MUST record the version a body was sealed at when it stores it, MUST NOT change it while that body is kept — a curation alters a record's standing, never its sealed content — and MUST include it whenever it differs from the record's `version`. It is absent where the two are equal, which is every record that has not been curated since it was written, so the members a record carries are unchanged until a curation needs this one. It is part of `sealed`, and so of the record the data commitment covers (`CommittedRecord`): a host cannot change it without changing the root.\n\nA reader opens and verifies the body at this version, and MUST refuse a record whose `sealed.version` is greater than its own `version` — a body cannot have been sealed for a version the room had not reached. A host that pairs a newer version with an older body of the same key is rolling the record back; that is a change to the committed record like any other, visible to the comparisons `CommittedRecord` exists for.";
+                    };
+                };
+            };
+            readonly AuthorityPresentation: {
+                readonly title: "AuthorityPresentation";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["membership", "authority"];
+                readonly description: "What a party presents to act on a room. Carries the whole authority chain: a host MUST NOT dereference an authority credential's `parent` to fetch a link it was not given. Resolving over the network would make verification depend on availability, turn every identifier into a request the host can be induced to make against an address the holder chooses, and signal credential use to whoever hosts the identifier. A host MUST bind the presenter to the chain's leaf. A chain that verifies is evidence that authority was conferred on somebody; it is not evidence that the party presenting it is that somebody. The leaf's subject MUST equal the party the host authenticated for this request — an identity the transport established or a document `proof` proved, never one named in a payload. A host that omits this check authorizes every captured presentation, and the omission is silent, because the chain still verifies.\n\n**Every credential is its issuer's attestation, and only its issuer's.** For the membership credential and for every link of `authority`, a host MUST verify the credential's `proof` with a key that the credential's own `issuer` lists for `assertionMethod` in its DID document, and MUST refuse a credential whose proof names a verification method that is not its issuer's. A proof that verifies under some other party's key is that party's statement, not the issuer's, and confers nothing. The same binding holds for every other document a room signs, such as a `RevocationList`.\n\n**A chain that verifies may still be revoked.** A host that has accepted a `RevocationList` for the room (`rooms/revocations/put`) MUST, from the moment it accepted it, refuse every presentation in which the membership credential or any link of `authority` is revoked by that list, under every task and every version of every task it serves for the room. A chain from which any link is revoked is refused whole: a credential delegated from a revoked one confers nothing, however it was attenuated. The refusal is the same `permissionDenied` as any other failed presentation.";
+                readonly properties: {
+                    readonly membership: {
+                        readonly type: "string";
+                        readonly description: "The presenter's membership credential for this room, or — on a `private` room — a zero-knowledge presentation of it. Serialized per the governing profile.";
+                    };
+                    readonly authority: {
+                        readonly type: "array";
+                        readonly minItems: 1;
+                        readonly maxItems: 8;
+                        readonly items: {
+                            readonly type: "string";
+                        };
+                        readonly description: "The authority chain, LEAF FIRST: the first element is the credential being relied on and the last MUST be one issued by the room itself. Every link the presenter relies on is present, because the host will not fetch one. Capped at 8: verification is linear in chain length and runs on every operation, so an unbounded chain is a denial-of-service surface against the host. The known uses need 2 to 3 — a person attenuating to an agent, and that agent to a sub-agent.";
+                    };
+                    readonly subjectBinding: {
+                        readonly type: "string";
+                        readonly description: "REQUIRED on a `private` room, where the subject identifier is withheld: a proof that the membership credential and the authority chain's leaf describe the SAME subject. Without it two parties pool credentials — one contributes membership, the other authority — and the combination verifies as a single party holding both. A host MUST refuse a private-room presentation that omits this.";
+                    };
+                };
+            };
+        };
+    };
+};
+/**
+ * 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 declare const RESPONSE_SPEC: {
+    readonly typeUri: "https://trusttasks.org/spec/rooms/records/put/0.3#response";
+    readonly isBearer: false;
+    readonly isProofRequired: true;
+    readonly isRecipientRequired: true;
+    readonly isIssuedAtRequired: true;
+    readonly payloadSchema: {
+        readonly $schema: "https://json-schema.org/draft/2020-12/schema";
+        readonly $ref: "#/$defs/Response";
+        readonly $defs: {
+            readonly Response: {
+                readonly $anchor: "response";
+                readonly title: "Rooms Records Put — response payload";
+                readonly description: "Success response to rooms/records/put. Type https://trusttasks.org/spec/rooms/records/put/0.3#response.";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["key", "version"];
+                readonly properties: {
+                    readonly key: {
+                        readonly type: "string";
+                        readonly maxLength: 512;
+                        readonly description: "The stored record's key.";
+                    };
+                    readonly version: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The version assigned, monotonic per room.";
+                    };
+                    readonly epoch: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The epoch the record was stored under.";
+                    };
+                    readonly ext: {
+                        readonly $ref: "#/$defs/Ext";
+                    };
+                };
+            };
+            readonly Ext: {
+                readonly title: "Ext";
+                readonly 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.";
+                readonly type: "object";
+                readonly minProperties: 1;
+                readonly additionalProperties: true;
+                readonly propertyNames: {
+                    readonly pattern: "^[a-z][a-z0-9-]*(\\.[a-z0-9-]+)+$";
+                };
+            };
+            readonly BlobRef: {
+                readonly title: "BlobRef";
+                readonly description: "The name of one blob: the digest of its BlobManifest, taken over the manifest's RFC 8785 (JCS) canonicalization. sha2-256 is RECOMMENDED and MUST be implemented. Content addressing over ciphertext, never plaintext, so a BlobRef says nothing about what the file contains, and two uploads of one file have different BlobRefs (a fresh `fileId` gives a different key, and so different ciphertext). Rooms cannot be correlated by the files they share. Compared as decoded multihash bytes, never as encoded strings. A BlobRef is defined over the manifest's JSON, as this schema states it and RFC 8785 canonicalizes it, never over any binding's generated type: two bindings that model the manifest as distinct types still compute the same BlobRef from the same JSON.";
+                readonly $ref: "#/$defs/DigestMultibase";
+            };
+            readonly DigestMultibase: {
+                readonly title: "DigestMultibase";
+                readonly 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`.";
+                readonly type: "string";
+                readonly minLength: 16;
+                readonly pattern: "^(z[1-9A-HJ-NP-Za-km-z]+|u[A-Za-z0-9_-]+)$";
+                readonly examples: readonly ["zQmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR"];
+            };
+            readonly RecordValidUntil: {
+                readonly title: "RecordValidUntil";
+                readonly type: "string";
+                readonly format: "date-time";
+                readonly description: "The instant after which the record's author no longer stands behind it as current. OPTIONAL; absent means the record does not expire. A reader hides a record whose `validUntil` has passed from default listings, search and recall, and shows it only on explicit request (`SealedRecordBody`, **Expiry**). No host enforces it.";
+            };
+            readonly PermittedUse: {
+                readonly title: "PermittedUse";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly minProperties: 1;
+                readonly description: "What the author permits the record to be used for — for example, that a learner's record is for instructional personalisation only. OPTIONAL; absent means the author stated no limit beyond the room's own terms.\n\n**Two halves, because purpose has both a machine and a human reading.** `purposes` names purposes by IRI, so that an agent can match them without parsing prose; `note` says it in words, for the nuance an identifier cannot carry. Either may be given alone.\n\n**No vocabulary of this family's own.** Purpose vocabularies exist and are maintained elsewhere — the W3C Data Privacy Vocabulary (`https://w3id.org/dpv#…`) is the one a writer SHOULD reach for first — and a short list defined here would be one more to translate between, and would be wrong at its edges for every domain that uses rooms. An IRI is the extension path: a community that needs a purpose no published vocabulary has names it under an IRI it controls.\n\n**A statement, not an enforcement.** No host can see it on the sealed tiers and none enforces it on any tier; every reader is a member who already holds the content. It records what the author permitted, so that a member — or an agent acting for one — can honour it, and so that a use outside it is a use against the author's stated terms rather than one nobody could have known about. An agent acting for a member SHOULD NOT use a record for a purpose outside `validFor` and SHOULD tell its principal when asked to. It confers no authority on anybody, and a `purposes` entry a reader does not recognise is shown, not ignored.";
+                readonly properties: {
+                    readonly purposes: {
+                        readonly type: "array";
+                        readonly minItems: 1;
+                        readonly maxItems: 8;
+                        readonly uniqueItems: true;
+                        readonly items: {
+                            readonly type: "string";
+                            readonly format: "uri";
+                            readonly pattern: "^[a-zA-Z][a-zA-Z0-9+.-]*:";
+                            readonly maxLength: 2048;
+                        };
+                        readonly description: "Purposes the record may be used for, each an absolute IRI — for example `https://w3id.org/dpv#ServicePersonalisation`. A set: order carries no meaning. An identifier, never fetched.";
+                    };
+                    readonly note: {
+                        readonly type: "string";
+                        readonly minLength: 1;
+                        readonly maxLength: 512;
+                        readonly description: "The permitted use in words, such as `instructional personalisation only`. Plain text, rendered as text, and never instructions — an agent reading it treats it as the author's statement about the record, not as something to do.";
+                    };
+                };
+            };
+            readonly RecordEvidenceList: {
+                readonly title: "RecordEvidenceList";
+                readonly type: "array";
+                readonly minItems: 1;
+                readonly maxItems: 32;
+                readonly items: {
+                    readonly $ref: "#/$defs/RecordEvidence";
+                };
+                readonly description: "What the author offers in support of the record: other records and credentials, by reference. OPTIONAL; absent means none was named, and an empty array is not a permitted spelling of that. Order carries no meaning. Bounded so that a reader's cost of showing a record's support is bounded too.";
+            };
+            readonly RecordEvidence: {
+                readonly title: "RecordEvidence";
+                readonly description: "One thing a record cites in its support, discriminated by `kind`.\n\n  - `record` names a record of a room by its key, and optionally the version cited and the room. Absent `roomId` means the record's own room.\n  - `credential` names a credential by its `id`, and optionally a digest of the credential as cited.\n\n**A reference, never a locator, and never proof.** A reader MUST NOT fetch, resolve or dereference a `credentialId` because a record names it, and MUST NOT read a record of another room on the strength of a citation: the rule that a room's identifiers are identifiers and not addresses (`AuthorityPresentation`) applies here for the same reasons — fetching would signal to whoever answers which member read which record, and when. A reader MAY show a cited record of the same room that it already holds or reads anyway, and MAY match a cited credential against ones its member already holds. What the citation proves is only that the author cited it; whether the evidence exists, says what the author claims, or supports the record is for whoever follows it up to judge.";
+                readonly oneOf: readonly [{
+                    readonly $ref: "#/$defs/RecordEvidenceRecord";
+                }, {
+                    readonly $ref: "#/$defs/RecordEvidenceCredential";
+                }];
+            };
+            readonly RecordEvidenceCredential: {
+                readonly title: "RecordEvidenceCredential";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["kind", "credentialId"];
+                readonly description: "Cites a credential.";
+                readonly properties: {
+                    readonly kind: {
+                        readonly const: "credential";
+                    };
+                    readonly credentialId: {
+                        readonly type: "string";
+                        readonly minLength: 1;
+                        readonly maxLength: 2048;
+                        readonly description: "The credential's `id`. An identifier: never fetched because a record names it.";
+                    };
+                    readonly digest: {
+                        readonly $ref: "#/$defs/DigestMultibase";
+                        readonly description: "OPTIONAL. A digest of the credential as cited — the SHA-256 multihash of its RFC 8785 (JCS) canonicalization, `proof` included — so a reader holding a credential with this `id` can tell whether it is the one the author meant.";
+                    };
+                };
+            };
+            readonly RecordEvidenceRecord: {
+                readonly title: "RecordEvidenceRecord";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["kind", "key"];
+                readonly description: "Cites a record of a room.";
+                readonly properties: {
+                    readonly kind: {
+                        readonly const: "record";
+                    };
+                    readonly key: {
+                        readonly type: "string";
+                        readonly minLength: 1;
+                        readonly maxLength: 512;
+                        readonly description: "The cited record's key, as in `rooms/records/put`. Opaque on the sealed tiers, like every key there.";
+                    };
+                    readonly version: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The version cited. OPTIONAL; present, it pins the citation to what the record said then, since a record can be rewritten under the same key. A reader that shows a later version SHOULD say that it is not the one cited.";
+                    };
+                    readonly roomId: {
+                        readonly type: "string";
+                        readonly pattern: "^did:";
+                        readonly maxLength: 2048;
+                        readonly description: "The cited record's room. Absent means the citing record's own room. A citation into another room tells the reader that room's identifier, so a writer SHOULD NOT cite into a room the citing room's readers are not meant to learn of.";
+                    };
+                };
+            };
+            readonly RecordConfidence: {
+                readonly title: "RecordConfidence";
+                readonly type: "number";
+                readonly minimum: 0;
+                readonly maximum: 1;
+                readonly description: "The author's own estimate, from 0 to 1, that what the record says is correct. OPTIONAL; absent means no estimate was given, never 1. Meaningful only beside the author who gave it: two writers' numbers are not on one scale, so a reader MUST NOT rank records by `confidence` across authors as though they were, and an agent that weights by it SHOULD weight within an author's own records. Never authority.";
+            };
+            readonly RecordBasis: {
+                readonly title: "RecordBasis";
+                readonly type: "string";
+                readonly enum: readonly ["declared", "observed", "verified", "inferred"];
+                readonly description: "What kind of claim a record is, as its author states it. OPTIONAL wherever it appears; absent means the author did not say, and a reader shows it as unstated rather than assuming any of these.\n\n  - `declared` — the author's own statement: a decision, a preference, an intention, a commitment. True because the author says so, and only as far as the author speaks for it.\n  - `observed` — something the author saw, measured or was told directly, recorded as found.\n  - `verified` — checked against evidence that somebody else can check again, such as a credential or another record. A record that says `verified` SHOULD name that evidence in `evidence`; one that does not is an unsupported claim to have checked, and a reader SHOULD present it so.\n  - `inferred` — derived by reasoning from other information: an agent's conclusion, a summary's generalisation, a model's guess. The value an agent writer uses when it does not know which of the others applies.\n\nThe values are the author's account of their own record, signed with it. They are not checked by anybody, confer nothing, and say nothing about whether the record is right — `inferred` can be correct and `observed` mistaken. Aligned with the provenance vocabulary of personal agent memory, so that a record moved between a member's memory and a room keeps its meaning.";
+            };
+            readonly SealedRecord: {
+                readonly title: "SealedRecord";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["ciphertext", "nonce", "epoch"];
+                readonly description: "A record as a host stores it on an `attributed` or `private` room. Title, description, body, author and tags are sealed together in one blob rather than separately: splitting them would let a host learn the shape of the material from ciphertext lengths, for no benefit, since a reader decrypts the whole record either way.";
+                readonly properties: {
+                    readonly ciphertext: {
+                        readonly type: "string";
+                        readonly description: "The sealed record, base64url. Bound by AEAD associated data to `roomId`, `key`, the version it was sealed at, and `epoch`, so a host that relocates it to another key, version, epoch or room produces a mismatch and the open fails. The record cannot be moved undetected even though the host holds every byte of it. The version it was sealed at is `version` below where present, and the record's own `version` otherwise.";
+                    };
+                    readonly nonce: {
+                        readonly type: "string";
+                        readonly description: "AEAD nonce, base64url.";
+                    };
+                    readonly epoch: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The key epoch this record was sealed under. Cleartext because the host must serve the right ciphertext, and bound into the associated data so that relabelling it fails authentication rather than causing a reader to try the wrong key.";
+                    };
+                    readonly version: {
+                        readonly type: "integer";
+                        readonly minimum: 1;
+                        readonly description: "The version this ciphertext was sealed at, where that is no longer the record's own `version`. A record's version moves when it is curated (`rooms/records/curate`, which MUST assign a new one so that every `sinceVersion` watermark sees the change), but a curation other than a retraction keeps the body — and the body is bound, by the AEAD and by its author's signature (`SealedRecordBody`), to the version it was written at. Without this member a curated record would be opened at a version it was never sealed for, and would not open for anyone.\n\nA host MUST record the version a body was sealed at when it stores it, MUST NOT change it while that body is kept — a curation alters a record's standing, never its sealed content — and MUST include it whenever it differs from the record's `version`. It is absent where the two are equal, which is every record that has not been curated since it was written, so the members a record carries are unchanged until a curation needs this one. It is part of `sealed`, and so of the record the data commitment covers (`CommittedRecord`): a host cannot change it without changing the root.\n\nA reader opens and verifies the body at this version, and MUST refuse a record whose `sealed.version` is greater than its own `version` — a body cannot have been sealed for a version the room had not reached. A host that pairs a newer version with an older body of the same key is rolling the record back; that is a change to the committed record like any other, visible to the comparisons `CommittedRecord` exists for.";
+                    };
+                };
+            };
+            readonly AuthorityPresentation: {
+                readonly title: "AuthorityPresentation";
+                readonly type: "object";
+                readonly additionalProperties: false;
+                readonly required: readonly ["membership", "authority"];
+                readonly description: "What a party presents to act on a room. Carries the whole authority chain: a host MUST NOT dereference an authority credential's `parent` to fetch a link it was not given. Resolving over the network would make verification depend on availability, turn every identifier into a request the host can be induced to make against an address the holder chooses, and signal credential use to whoever hosts the identifier. A host MUST bind the presenter to the chain's leaf. A chain that verifies is evidence that authority was conferred on somebody; it is not evidence that the party presenting it is that somebody. The leaf's subject MUST equal the party the host authenticated for this request — an identity the transport established or a document `proof` proved, never one named in a payload. A host that omits this check authorizes every captured presentation, and the omission is silent, because the chain still verifies.\n\n**Every credential is its issuer's attestation, and only its issuer's.** For the membership credential and for every link of `authority`, a host MUST verify the credential's `proof` with a key that the credential's own `issuer` lists for `assertionMethod` in its DID document, and MUST refuse a credential whose proof names a verification method that is not its issuer's. A proof that verifies under some other party's key is that party's statement, not the issuer's, and confers nothing. The same binding holds for every other document a room signs, such as a `RevocationList`.\n\n**A chain that verifies may still be revoked.** A host that has accepted a `RevocationList` for the room (`rooms/revocations/put`) MUST, from the moment it accepted it, refuse every presentation in which the membership credential or any link of `authority` is revoked by that list, under every task and every version of every task it serves for the room. A chain from which any link is revoked is refused whole: a credential delegated from a revoked one confers nothing, however it was attenuated. The refusal is the same `permissionDenied` as any other failed presentation.";
+                readonly properties: {
+                    readonly membership: {
+                        readonly type: "string";
+                        readonly description: "The presenter's membership credential for this room, or — on a `private` room — a zero-knowledge presentation of it. Serialized per the governing profile.";
+                    };
+                    readonly authority: {
+                        readonly type: "array";
+                        readonly minItems: 1;
+                        readonly maxItems: 8;
+                        readonly items: {
+                            readonly type: "string";
+                        };
+                        readonly description: "The authority chain, LEAF FIRST: the first element is the credential being relied on and the last MUST be one issued by the room itself. Every link the presenter relies on is present, because the host will not fetch one. Capped at 8: verification is linear in chain length and runs on every operation, so an unbounded chain is a denial-of-service surface against the host. The known uses need 2 to 3 — a person attenuating to an agent, and that agent to a sub-agent.";
+                    };
+                    readonly subjectBinding: {
+                        readonly type: "string";
+                        readonly description: "REQUIRED on a `private` room, where the subject identifier is withheld: a proof that the membership credential and the authority chain's leaf describe the SAME subject. Without it two parties pool credentials — one contributes membership, the other authority — and the combination verifies as a single party holding both. A host MUST refuse a private-room presentation that omits this.";
+                    };
+                };
+            };
+        };
+    };
+};
+//# sourceMappingURL=payload.d.ts.map