| Internet-Draft | SSM | October 2026 |
| van de Meent | Expires 2 May 2027 | [Page] |
This document defines the Semantic Surface Manifest, a human-readable and policy-matchable routing layer for identity-bound continuity containers and TBZ-based sealed bundles.¶
The Semantic Surface Manifest exposes limited dispatch metadata such as time fragment, context, profile, and priority without exposing sealed content. It is intended for use in systems where routing decisions may need to occur before deep inspection, while trust remains anchored in intrinsic bundle properties such as magic bytes, manifests, hashes, signatures, and causal references.¶
This revision separates two decisions that earlier revisions left implicit: a routing hint, which may be taken from the visible surface before any inspection, and an admission verdict, which must never rest on the visible surface.¶
In short: address visible, content sealed.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Semantic Surface Manifest (SSM) gives a sealed object a short, readable name that can be used to dispatch it without opening it. The name is a hint. What the object is, who produced it, and whether it may be acted upon are established from the object's intrinsic, verifiable properties.¶
This is the -03 revision. Revision -02 added the Sealed Authentication Module extension (Section 17) as a complement to the Claim-Verified extension (Section 16). Revision -03 incorporates what was learned from implementing the surface model since May 2026. The main additions are: an explicit distinction between routing hints and admission verdicts (Section 11); a description of the places a surface can be carried and which of them count as intrinsic (Section 9); clarifications to the processing model on type recognition, origin anchoring, and the order of checks (Section 10); a Disguised Surface mismatch class (Section 14.3); guidance for self-describing artefacts (Section 15); and an Implementation Status section (Section 18). All changes are listed in Appendix A.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Sealed containers often provide strong integrity but weak dispatch semantics.¶
Systems therefore face a recurring tradeoff: either encrypt and seal everything, delaying routing and policy choice until deep inspection, or expose too much metadata, weakening privacy and creating new security ambiguities.¶
The Semantic Surface Manifest addresses this by providing a constrained, readable routing layer that supports dispatch without decrypting content, minimizes metadata exposure, does not replace cryptographic verification, and composes with existing sealed-container workflows.¶
A second, quieter problem appears once such a layer exists: a readable surface invites being read as a decision. A queue that was chosen from a name, or an object that arrived where it was expected, can come to be treated as accepted. This document therefore states explicitly which decisions a surface may inform and which it may not.¶
The Semantic Surface Manifest is intended to remain human-readable, machine-parseable, bounded in disclosure, and composable with existing ICC or TBZ verification workflows.¶
It should support wildcard or policy matching, align with logs and audit ecosystems, and support mirrored sealed fields for consistency checks. It must not be treated as proof of identity or content, override manifest truth, or carry rich payload details.¶
It must also not be usable as an admission input: a surface may choose where an object goes, never whether it is accepted there.¶
The normative external form is:¶
<time-fragment>.<context>.<profile>.<priority>[.<icc-ext>]¶
The Semantic Surface Manifest is intentionally flat and dot-delimited in version 1. The formal grammar uses ABNF as defined in [RFC5234].¶
Each segment is restricted to lowercase letters, digits, and hyphens. Segments must not contain spaces, slashes, underscores, nested dots, or uppercase letters.¶
surface-name = time-fragment "." context "." profile "." priority
[ "." icc-ext ]
time-fragment = date-frag [ "t" time-frag "z" ]
date-frag = 4DIGIT "-" 2DIGIT "-" 2DIGIT
time-frag = 2DIGIT "-" 2DIGIT
context = 1*32(segment-char)
profile = 1*16(segment-char)
priority = 1*16(segment-char)
icc-ext = 1*16(segment-char)
segment-char = LCALPHA / DIGIT / "-"
LCALPHA = %x61-7A
DIGIT = %x30-39
¶
A name that does not match this grammar is not a version 1 semantic surface. A parser MUST NOT repair or reinterpret such a name into a version 1 surface. Implementations that use a different surface grammar are discussed in Section 21.1.¶
This document prefers an ISO8601-style fragment over compact local date forms because it is lexicographically sortable, readable across jurisdictions, aligned with logs, and supports both coarse and fine routing granularity.¶
Two forms are recommended in version 1:¶
2026-05-08 2026-05-08t18-38z¶
Initial profile values include claude, gemini, gpt, kit, iddrop, parentattest, capsule, and tza. These values describe semantic class, not vendor authenticity.¶
An implementation MAY use a profile value as an expectation that the object is a sealed container (for example, treating a name whose final segment is a registered profile as one that should carry container magic bytes). Such an expectation is a routing hint; when it is not met, the result is a surface-integrity event (Section 14.3), not a type determination.¶
Initial priority values include urgent, normal, background, and sealed.¶
The context field remains open-text in version 1 but is expected to be short, low-leakage, and ABNF-conforming.¶
A profile, priority, or other surface value that a processor does not recognize MUST NOT be mapped by default onto a class or handling level that carries more capability than the processor would give an object with no surface at all. A fallback may degrade handling; it may not elevate it.¶
A semantic surface can travel with an object in several places. The place determines how much it can be relied upon.¶
An implementation MUST classify each surface location it reads according to whether its integrity verification covers that location, and MUST treat locations outside that coverage as extrinsic surface, wherever they are physically stored. A format that places surface or classification bytes in a header SHOULD either bring them under the integrity mechanism or document them as extrinsic.¶
A compliant implementation MAY parse the semantic surface before opening the bundle in order to choose a queue, handler, retention policy, or operator lane. The result of a surface parse is a routing hint (Section 11).¶
An implementation SHOULD verify container type using intrinsic signals such as TBZ magic bytes before deep handling.¶
Type recognition SHOULD identify the container family from its magic bytes independently of the format version that follows them, so that a newer version of a known family is reported as a version the reader does not handle rather than as a non-container.¶
If the visible surface implies a sealed container and the magic bytes do not match, the object MUST NOT be routed or handled as a sealed container; this is a Disguised Surface (Section 14.3). Conversely, an object whose magic bytes identify a sealed container SHOULD be handled as one regardless of its name or extension; a renamed carrier is still a carrier.¶
Magic bytes establish type, not origin or integrity. A matching prefix is necessary for treating an object as a sealed container and is never sufficient for admitting it.¶
Implementations that observe a directory or queue SHOULD NOT sniff an object while it is still being written. Writers SHOULD write to a temporary name and rename the object into place when complete.¶
Before trust-sensitive operations, an implementation MUST verify the sealed container according to its intrinsic integrity rules.¶
A signature that verifies under a public key carried inside the same object establishes internal consistency only. Origin is established by comparing that key with a key anchored outside the object, such as a trust store, a name-service record, or a key the consumer already holds. An implementation MUST NOT treat a key carried inside an object as an authority by virtue of being carried there.¶
Whether the producer's key was current (not rotated, not revoked) at the relevant point is a separate question from whether the signature verifies. An implementation that does not evaluate key currentness SHOULD NOT describe a verified object as "trusted", and SHOULD use a term that states only what was measured (for example, "producer bound").¶
If the reader cannot perform verification at all (for example, because the available tooling predates the container version, or the verification component cannot be loaded), the result MUST be treated as unprovable and MUST NOT default to acceptance.¶
After deep verification, a consumer decides whether the object may be admitted at that consumer: opened, materialized, registered, or treated as identity-bound. The admission verdict is computed from intrinsic truth and local policy only. The semantic surface, sidecar descriptors, and any in-band header outside integrity coverage MUST NOT contribute to it.¶
This document does not define a verdict vocabulary. An implementation SHOULD, however, keep at least the following outcomes distinct, because each leads to a different next action:¶
An object whose declared binding fails verification MUST NOT be treated more favourably than an object that declares no binding. The absence of a claim and an unverifiable claim MUST NOT be collapsed into the same outcome.¶
If the sealed manifest contains mirrored surface fields, the implementation SHOULD compare them against the external semantic surface. Meaningful mismatch SHOULD be treated as a surface-integrity event leading to triage, quarantine, or policy review rather than silent acceptance.¶
The comparison SHOULD be made after deep verification, against verified mirrored fields. A comparison made against unverified fields is itself only a hint. Where a sidecar descriptor carries a surface label in addition to the object name, the descriptor label SHOULD also be compared with the mirrored fields.¶
A mismatch on an object that otherwise verifies does not by itself invalidate the object; it means the visible surface is not a reliable description of it. Whether such an object is delivered with a flag, held for triage, or refused is a policy decision (Section 14). It MUST NOT be accepted silently.¶
When a type sniff, verification, or admission step declines to proceed with an object, the implementation SHOULD record a disposition with a reason (for example, refused, quarantined, held for triage, or ignored as an incomplete write). Recording an arrival and then returning without any disposition makes an undecided object indistinguishable from a handled one.¶
Routing and admission are different decisions with different inputs.¶
A forwarder or relay can therefore be content-blind: it can check that an object carries the expected container magic bytes, read a destination from a descriptor, and pass the bytes on without opening them. Doing so is arrival and transport, not admission. Storing and forwarding a sealed object MAY occur without an admission verdict; treating it as identity-bound MUST NOT.¶
A routing hint can also take the form of an expectation, for example a signed statement by a predecessor that a particular successor is expected, or a surface pattern that a consumer has been told to watch for. A matched expectation MAY select a faster processing path. It MUST NOT substitute for, or upgrade, an admission verdict. An expectation narrows what is acceptable; it does not grant acceptance. When admission fails and an expectation matched, the reason reported SHOULD name the failed admission, so that operators do not repair the expectation in place of the object.¶
If a declared expectation is itself checked and fails, the result SHOULD be treated as refused even if admission succeeded, because the expectation was stated by a party entitled to restrict what follows it.¶
This document defines optional mirrored manifest fields such as surface_time_fragment, surface_context, surface_profile, and surface_priority.¶
If both an external semantic surface and internal mirrored fields are present, the mirrored fields are authoritative for triage classification and deep semantic handling.¶
Because names can change in transit and on arrival, an implementation MAY reconstruct the canonical surface name from the verified mirrored fields and compare it with the name under which the object was found. A difference SHOULD be recorded with both names, so that an operator rename is explicit rather than silent. A recorded rename of an otherwise consistent object is a Cosmetic Mismatch (Section 14.1).¶
Example external surface:¶
2026-05-08.redspecter-review.claude.urgent¶
Processing may route to an urgent queue, classify as a candidate profile, verify TBZ magic bytes, inspect the manifest, verify signatures and hashes, compare visible and sealed surface, and only then hand to a profile-aware handler if consistent or policy-approved.¶
The steps divide as follows. Choosing the urgent queue and the candidate profile are routing hints. Verifying magic bytes is type recognition. Verifying signatures and hashes, and comparing the signer's key with an externally anchored key, produce the inputs to admission. Handing the object to a profile-aware handler is the admitted action. If the object is renamed in transit, for example to a name chosen for the recipient, the routing hint changes but none of the later steps do.¶
A visible label changes while sealed truth remains intact. Recommended disposition is triage with manifest semantics prevailing.¶
A visible profile and a sealed profile differ in a way that creates significant misrouting risk. Recommended disposition is triage or quarantine, not auto-materialization.¶
Examples include a visible surface that names a different sender or recipient than the sealed fields, a visible priority or flag that disagrees with the sealed value, a sealed routing field (such as a lane) that the visible surface omits, and a declared payload class that disagrees with the content (for example, executable entries inside an object declared as a document).¶
The visible surface implies a sealed container (for example, through a registered profile or a container extension), but the object does not carry the container's magic bytes. The object MUST NOT be routed, stored, or handled as a sealed container. Recommended disposition is refusal at a forwarder and triage or quarantine at a consumer.¶
Legacy bundles may provide visible routing only, yielding a reduced-assurance mode because no sealed-surface comparison is possible.¶
The surface model applies beyond bundles in transit. Any artefact that declares what it is (a tool descriptor, a capability manifest, a sealed result) presents a surface, and the same rule holds: the declaration is a hint until it is admitted.¶
This allows an operation to be expressed against an object without opening it. The verb expresses intent; the magic bytes establish type; admission establishes whether the verb may act on the object; and the semantic surface is where verb and object meet. An implementation may, for example, refuse a verb against an object whose recognized class it does not permit, before any content is unpacked.¶
For self-describing artefacts the following guidance applies.¶
This section defines an OPTIONAL extension to the SSM that allows a sealed envelope to carry a privacy-preserving policy answer such as an age-gate verification, without disclosing the underlying personal data used to derive that answer.¶
The Claim-Verified Extension is intended for challenge-response flows where: a verifier (e.g. a merchant) MUST be assured that a rule is satisfied (e.g. "user is age 18 or older"); a responder (e.g. a wallet on a Secure Enclave smartphone) holds the personal data needed to evaluate the rule locally; and neither side wishes to transmit the personal data itself.¶
A response envelope using this extension answers: did this challenge satisfy the requested rule. It explicitly does NOT answer: who the person is, what their exact birth date is, what document number they carry, or any other personal payload.¶
The verifier issues a challenge as a sealed envelope carrying the following fields. Required: intent (policy intent, e.g. "verify_age"); threshold (rule parameter, e.g. 18); reply_to (verifier address as AINS or JIS-DID); challenge_nonce (opaque per-challenge random value); challenge_hash (sha256 of canonical challenge material). Optional: valid_until (expiry timestamp, RFC3339); policy_domain (e.g. "age-gate"); jurisdiction (country or policy-scope identifier); evidence_class (e.g. "minimal-disclosure").¶
The responder issues a response as a sealed envelope carrying the following fields. Required: intent (the response form, e.g. "verify_age_response"); challenge_hash (sha256 copied from the challenge); claim_verified (symbolic claim, e.g. "age_over_threshold"); threshold (MUST match challenge); result (boolean true or false). Optional: issuer_anchor (trust anchor reference); valid_at (time of local verification); result_scope (e.g. "session-only"); receipt_requested (boolean).¶
A response envelope using this extension MUST NOT include full legal name, birth date, passport number, citizen number, face template, or raw credential payload. It MAY include trust anchor reference for the issuing credential, policy domain reference, and challenge-bound correlation material such as challenge_hash, only where needed for downstream verification or audit.¶
A claim_verified response asserts: "a trusted wallet answered this exact challenge with a valid claim_verified result against the parameter threshold". It explicitly does NOT assert "this is natural person X". This keeps the statement policy-bound, not identity-maximal. The cryptographic binding between challenge and response via challenge_hash prevents replay across distinct verifier sessions.¶
Implementations MAY record the challenge-response pair in a Causal Bill of Materials (CBOM) to enable subsequent regulatory review. A compliant CBOM trace SHOULD show: challenge received with challenge_hash; local policy evaluation performed; response emitted with matching challenge_hash; response accepted or denied by verifier; receipt logged if receipt_requested is true. The CBOM trace MUST NOT cause the merchant or auditor to retain personal identity payloads. The cryptographic chain alone is sufficient evidence that the policy answer was produced by an identity-bound wallet for a specific challenge.¶
This extension is intentionally minimal. The same shape generalizes to other policy domains: verify_age with threshold (age-gate); verify_residency with jurisdiction (region-gate); verify_kyc_class with level (tiered consent); verify_role with role (attestation-bound capability). In all cases the responder discloses only the symbolic claim and boolean result, never the underlying personal evidence.¶
This section defines an OPTIONAL extension to the SSM that permits a sealed envelope to carry an intent-bound, one-shot authentication artifact, such that an agent may request execution of a specific action without ever holding the underlying secret material in cleartext.¶
The SAM extension is intended for credential-bearing flows where: an upstream caller (e.g. an automated agent) needs to cause a specific action to occur (e.g. publish a package, sign a transaction, deploy a container); the calling actor MUST NOT possess the raw credential needed to perform that action; and a bounded execution boundary (e.g. tibet-gateway) holds custody of the credential and performs the action on behalf of the caller under cryptographically enforced scope.¶
A SAM envelope answers: which single bounded act is this artifact permitted to authorise, by which actor, for which target, until when. It does NOT carry the secret material in a form the holder can read; the encrypted credential block can only be unsealed inside the trusted execution boundary that materialised the SAM.¶
This is the natural complement to the Claim-Verified Extension (Section 16): claim-verified responses say "this rule is satisfied"; SAM envelopes say "this single bounded act is now authorised".¶
A SAM envelope carries the following fields in its sealed manifest. Required: intent (semantic label for the bounded act, e.g. "upload_package"); secret_id (opaque identifier of the underlying credential in the issuing keychain); target_action (the action endpoint or contract address); actor_id (JIS-DID of the actor permitted to present this envelope); valid_until (RFC3339 expiry timestamp); ephemeral_id (single- use identifier tied to this materialisation).¶
Optional: constraints (array of key-value pairs that further bound the act, e.g. package="tibet-zip", registry="pypi"); policy_lane (which policy regime authorised this SAM); receipt_required (boolean, whether a sealed receipt is expected after execution); supersedes_sam_id (link to a prior SAM this one replaces, in rotation chains).¶
A SAM envelope MUST NOT include the underlying secret material in cleartext form. The encrypted credential block, if present in the sealed payload, MUST be decryptable only by the execution boundary identified in the manifest (typically identified by its public key or AINS reference).¶
An execution boundary that materialises a SAM envelope MUST: validate the manifest signature against the issuing keychain; check that the actor_id matches the entity presenting the envelope (via TIBET-SIG-V1 or equivalent identity proof); confirm that valid_until has not elapsed; enforce that the intended action matches target_action and all constraints; and destroy the ephemeral session after execution completes, whether successful or not.¶
An execution boundary MUST NOT permit a SAM envelope to be replayed: the ephemeral_id is single-use and MUST be recorded in a non-replay log for at least the duration of valid_until plus the conservative network-clock-skew margin.¶
SAM materialisation is itself a causally-anchored event. The issuing keychain SHOULD record a secret-proxied event in its custody timeline (see related tibet-keychain specification), with action_id and parent_action_id linking the SAM materialisation to the originating intent request.¶
Upon execution, the execution boundary SHOULD emit a provenance-sealed response that references the SAM envelope's sam_id and ephemeral_id, so that downstream audit walkers (e.g. tibet-cbom) can construct the full chain: intent request - SAM materialisation - execution - response. Each step is Ed25519-signed by the actor responsible for that step.¶
Agent intent: "upload tibet-zip v1.0.3 to PyPI". Keychain materialises a SAM envelope with the following manifest fields:¶
intent = "upload_package", secret_id = "sec_pypi_001", target_action = "/upload/pypi", actor_id = "jis:humotica:codex", valid_until = "2026-05-12T10:34:18Z", ephemeral_id = "eph_d7fad2165e13", constraints = [package="tibet-zip", registry="pypi"].¶
The agent receives the SAM as a sealed .tza envelope; the agent cannot extract the underlying PyPI token. The agent forwards the envelope to a tibet-gateway endpoint, which validates the manifest, breaks the seal in its own runtime, executes the upload against PyPI, emits a provenance-sealed response back to the agent, and destroys the ephemeral session. The agent never possessed the PyPI token at any point.¶
The same envelope shape generalises to any credential- bearing action where bounded delegation is required: publication to package registries (PyPI, crates.io, npm, Maven), source-code platforms (GitHub PATs, GitLab tokens), cloud APIs (AWS service accounts, GCP service credentials), signing operations (smart-contract transactions, code-signing keys, TLS-certificate issuance), and database access where the agent should not see the connection string. In all cases the envelope captures intent + scope, and the gateway performs the act under cryptographic enforcement.¶
The SAM extension defines the WHY primitive in a four-part family of credential-life-cycle artifacts: a temporal-trigger layer (WHEN, see related tibet-vault specification) decides when a sealed result may be disclosed; a custody-and-timeline layer (WHERE/HOW, see related tibet-keychain specification) records where the secret lives and who touched it; the SAM layer (WHY, this section) authorises a single bounded act without releasing the secret; and an execution-boundary layer (WHERE-EXEC, see related tibet-gateway specification) safely performs the act. The four layers compose into one causally verifiable credential workflow.¶
[Note to the RFC Editor: please remove this section, and the reference to RFC 7942, before publication.]¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
All three implementations below are by the author's organization. They are research implementations. None of them implements the version 1 surface grammar of Section 6 as a validating parser; they implement the processing model around it.¶
A self-hosted node runtime (Python and shell) that exchanges sealed carriers between identities. Relevant components:¶
The self-tests of the admission predicate, the open predicate, the tool-descriptor admission, and the lane holder passed in the author's workspace on 29 October 2026.¶
The Semantic Surface Manifest is not a source of trust. Implementations must assume that external names can be changed and visible routing labels can be misleading. The sealed container remains the only strong source of truth.¶
Routing may depend on SSM, but trust must not depend on SSM alone. Admission must not depend on it at all (Section 11).¶
The following threats were made concrete during implementation:¶
Magic bytes are public and trivially reproduced. They identify a format; they do not authenticate anything.¶
The Semantic Surface Manifest intentionally exposes limited metadata. Implementers should keep context low-sensitivity, avoid direct secrets or detailed personal data, and prefer naming for dispatch rather than disclosure.¶
A surface that names a sender and a recipient, as addressing grammars do (Section 21.1), discloses the communication relationship to every party that can see the name or a sidecar descriptor, including relays that cannot read the content. Implementers should weigh this against the routing benefit, and should prefer that relays route on a destination field alone rather than on a name that also identifies the sender.¶
A recorded rename (Section 12) retains the name an operator chose; if names may carry personal information, audit records of renames carry it too.¶
The SSM is designed to compose with TBZ, ICC-based continuity containers, TIBET Drop or TAT flows, session-state bundles, attestation bundles, sealed capsules, local storage, transport objects, attachments, queues, and router decisions.¶
Implementation experience shows that deployments may use a surface grammar other than the version 1 dispatch grammar of Section 6. One implementation uses an addressing grammar of the form sender@locus.subject.recipient, optionally followed by a recipient host, a lane, and an uppercase flag. That grammar uses characters the version 1 grammar excludes and carries fields (sender, recipient) that version 1 does not.¶
This document does not define such grammars. The processing model of Section 10, the separation of Section 11, and the mismatch classes of Section 14 apply to them unchanged. A processor MUST know which grammar it is parsing and MUST NOT attempt to interpret a surface under a grammar it was not written for. A surface that fails its grammar yields no routing hint, and its object is handled as if it had no surface.¶
This document does not replace JIS identity semantics, TIBET causal ordering, TAT transfer flow, or ICC sealed object semantics. It adds a visible routing surface above them.¶
A clean split is that JIS decides who is acting, TIBET decides causal truth, TAT decides transfer flow, ICC decides sealed object class, and SSM decides visible dispatch semantics.¶
In a single hand-off, three distinct questions are answered by three distinct artefacts: the semantic surface answers what the object appears to be (address); the verified sealed manifest answers what it is (truth); and an accompanying instruction or message, where one exists, answers what the sender expects the receiver to do with it (intent). None of the three substitutes for another.¶
The following topics are non-blocking for the present -03 revision and are recorded here to guide later discussion and interoperability work.¶
This document requests two registries: a Surface Profile Registry and a Surface Priority Registry.¶
Registration policy for both is Expert Review as described in [RFC8126]. Initial profile values are claude, gemini, gpt, kit, iddrop, parentattest, capsule, and tza. Initial priority values are urgent, normal, background, and sealed.¶
No registries are requested for time-fragment, context, or icc-ext in version 1. This revision requests no additional registries.¶
The author thanks the Humotica team for editorial assistance, RFC outline preparation, mismatch class formalization, and the operational tooling that made the surface consistency model concrete.¶
The author also thanks Richard Barron of Red Specter Security Research for adversarial framing that helped sharpen the address visible, content sealed principle and the rename-attack perspective.¶