TIBET Semantic Surface Manifest

TIBET Semantic Surface Manifest Humotica

Netherlands info@humotica.com https://humotica.com/

Security Internet Engineering Task Force semantic surface routing admission TIBET TBZ sealed containers 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.

Introduction 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 () as a complement to the Claim-Verified extension (). 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 (); a description of the places a surface can be carried and which of them count as intrinsic (); clarifications to the processing model on type recognition, origin anchoring, and the order of checks (); a Disguised Surface mismatch class (); guidance for self-describing artefacts (); and an Implementation Status section (). All changes are listed in .

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Problem Statement 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.

Terminology

Identity-Bound Continuity Container:: A cryptographically sealed bundle that combines identity binding, continuity semantics, and containerized payload transfer.
Semantic Surface Manifest:: A human-readable routing surface associated with a bundle, typically expressed through filename or object-name structure and optionally mirrored into sealed manifest fields.
Intrinsic Truth:: Properties established by the sealed object itself and covered by its integrity verification, such as magic bytes, manifest, signatures, hashes, and chain anchors. A field is intrinsic because verification covers it, not because it is located inside the object's bytes; see .
Extrinsic Surface:: Properties expressed outside the integrity coverage of the sealed object for dispatch and routing, such as time fragment, context, profile, and priority.
Surface-Integrity Event:: A meaningful mismatch or anomaly involving visible routing surface and mirrored sealed routing fields, or between the visible surface and the object's recognized type.
Carrier:: The sealed object as it travels, including any visible header or name attached to it.
Sidecar Descriptor:: A separate, unsealed record stored or transmitted beside a carrier that names its destination, kind, or surface label without being part of the carrier's integrity coverage.
Routing Hint:: Any decision input taken from the extrinsic surface, a sidecar descriptor, or the transport context, used to select a queue, handler, lane, or processing path.
Admission Verdict:: The result of evaluating whether an object may be treated as more than opaque bytes at a given consumer: for example, whether it may be opened, materialized, registered, or treated as identity-bound. An admission verdict is computed from intrinsic truth and local policy.
Arrival:: The event of an object being received or stored. Arrival is not admission.

Design Goals 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.

Syntax The normative external form is: ...[.] ]]> The Semantic Surface Manifest is intentionally flat and dot-delimited in version 1. The formal grammar uses ABNF as defined in . Each segment is restricted to lowercase letters, digits, and hyphens. Segments must not contain spaces, slashes, underscores, nested dots, or uppercase letters. 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 .

Time Fragment Format 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:

Vocabulary Registries

Profile Registry 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 (), not a type determination.

Priority Registry Initial priority values include urgent, normal, background, and sealed.

Context The context field remains open-text in version 1 but is expected to be short, low-leakage, and ABNF-conforming.

Unknown Values 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.

Surface Carriage A semantic surface can travel with an object in several places. The place determines how much it can be relied upon.

Object name:: The filename or object-store key. Any party that can rename the object can change it. A receiver may also rename an object on arrival (for example, naming a landed carrier by its content hash), so the original name need not survive transport.
Sidecar descriptor:: A separate record next to the carrier (for example, a small JSON document naming destination, kind, and surface label) that a forwarder can read without unsealing the carrier. It is as mutable as the object name.
In-band header outside integrity coverage:: Bytes inside the carrier, such as a format header field or a declared payload class, that are not covered by the signature, hash, or AEAD authentication that protects the payload. Although physically inside the object, these are extrinsic surface.
In-band header inside integrity coverage:: A visible header that is itself signed, or whose signature and body hash bind it to the sealed payload. This is readable before decryption and, once the binding has been verified, is intrinsic truth.
Mirrored sealed fields:: Surface fields repeated inside the sealed manifest (). These are intrinsic once the container has been verified and are the durable copy of the surface.

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.

Processing Model

Surface Parse 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 ().

Type Sniff 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 (). 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.

Deep Verification 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.

Admission 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:

bound: the declared bindings verify; the object may be admitted subject to local policy;
carried: the object declares no binding and none is broken; it may be stored and forwarded but not treated as identity-bound;
refused: a declared binding fails, or bound and unbound parts are mixed;
unprovable: a binding could not be evaluated either way.

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.

Surface-to-Manifest Consistency 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 (). It MUST NOT be accepted silently.

Recorded Disposition 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 Hints and Admission Verdicts Routing and admission are different decisions with different inputs.

Routing MAY happen before any inspection and MAY use the semantic surface, sidecar descriptors, and transport context.
Admission MUST be based on intrinsic truth and local policy, and MUST NOT rest on the visible surface.

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.

Mirrored Manifest Fields 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 ().

Example Example external surface: 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.

Mismatch Classes

Cosmetic Mismatch A visible label changes while sealed truth remains intact. Recommended disposition is triage with manifest semantics prevailing.

Routing-Risk Mismatch 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).

Disguised Surface 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.

No Mirrored Fields Legacy bundles may provide visible routing only, yielding a reduced-assurance mode because no sealed-surface comparison is possible.

Self-Describing Artefacts 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.

The existence of a file is not the existence of the thing it describes. A descriptor found in a location that is read for such descriptors SHOULD remain inert (not registered, not loaded, not offered as usable) until it is admitted.
A surface the artefact declares about itself SHOULD be checked against the internal fields it summarizes (for example, a declared surface that must embed the artefact's own name). A disagreement is a reason to reject the artefact.
Admission SHOULD rest on an anchor outside the artefact, such as a release-signed hash manifest that pins the artefact's digest, or a receipt issued locally by an authorized party and bound to that digest. Write access to the location is not such an anchor.
The artefact SHOULD be read once, within a size bound, and the bytes that were judged SHOULD be the bytes that are used. A consumer that re-opens the artefact by path after admission reintroduces a time-of-check to time-of-use gap.
An artefact that is not admitted SHOULD remain available for inspection, separate from usable artefacts, rather than being silently discarded.

Claim-Verified Extension (Privacy-Preserving Policy Answers) 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.

Design goal 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.

Challenge envelope fields 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").

Response envelope fields 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).

Normative privacy posture 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.

Semantics 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.

Audit and CBOM implications 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.

Relationship to broader claim-verification 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.

Sealed Authentication Module (SAM) Extension 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.

Design goal 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 (): claim-verified responses say "this rule is satisfied"; SAM envelopes say "this single bounded act is now authorised".

SAM envelope fields 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).

Normative posture 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.

Causal chain implications 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.

Example 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.

Generalisation across credential domains 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.

Position in the four-W family 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.

Implementation Status [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 . 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 , "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 as a validating parser; they implement the processing model around it.

TIBET-ZIP (tbz) codec

Organization:: Humotica.
Description:: Rust codec and command-line tool for the TBZ container format, version 2.4.1. Relevant behaviour: container recognition by the three-octet magic prefix 0x54 0x42 0x5A ("TBZ") before the file extension is considered; refusal to treat a file named with a container extension as a container when the magic bytes are absent; a notice when a container is found under a name without a container extension; an optional one-octet in-band surface slot in the version 2 header, signalled by a header flag; a declared payload class in the version 2 header, checked after opening against the outer file extension and against the inner manifest entries (executable entries inside an envelope not declared as code), as a warning or, in strict mode, as a refusal; and a binding report command that reports producer and block binding state without issuing a verdict.
Findings that informed this revision:: In the version 2 sealed container, the sender signature covers the ciphertext and the AEAD additional data is the transfer identifier; the header flags and the declared payload class are not covered. They are therefore extrinsic surface in the sense of , even though they are inside the file. The sealed-container writer examined does not emit the one-octet surface slot. The automatic mode of the command-line tool recognizes a version-specific four-octet prefix; by code reading, a version 2 container with a container extension would be reported as lacking magic bytes rather than as a newer version, which motivated the version-independence guidance in .
Maturity:: Research implementation.
Licensing:: MIT OR Apache-2.0.
Contact:: Jasper van de Meent, info@humotica.com.

tibet-continuityd

Organization:: Humotica.
Description:: Python daemon, version 0.6.17, that watches intake directories and runs a sniff, verify, and fork pipeline on arriving objects. Its sniff stage states the rule "name is hint, content is truth, arrival is event"; classifies arrivals by magic bytes into, among others, sealed, sealed without a recognized extension, disguised (the name implies a sealed container but the magic bytes are absent), and executable; uses the initial Profile Registry values of this document as the set of names that imply a sealed container; ignores files with in-flight staging suffixes until they are renamed into place; and, in its verification stage, reconstructs the canonical surface name from the manifest and records both names when they differ.
Findings that informed this revision:: In one operating mode, an arrival that is not a sealed container is logged and then not given any further disposition, while a stricter mode quarantines it. This motivated .
Maturity:: Research implementation.
Licensing:: MIT.
Contact:: Jasper van de Meent, info@humotica.com.

AInternet-in-a-box

Organization:

Humotica.

Description:

A self-hosted node runtime (Python and shell) that exchanges sealed carriers between identities. Relevant components:

A content-blind lane holder and a minimal relay that accept only objects carrying the TBZ magic bytes, route by a destination taken from a sidecar descriptor or request field, record the presented name as ignored, and never open the payload. A landed carrier is stored under a name chosen by the receiver (a transport identifier or a prefix of its content hash), not under the name the sender gave it.
A sealed offer carrier with a plaintext discovery header that is signed by the sender's identity key and carries a hash of the sealed body, so that the readable header is bound to the payload (the "in-band header inside integrity coverage" case of ). Sender origin is established by comparing the header's key with the key the recipient holds for the claimed sender; where the recipient holds no such key, the message is presented as unproven.
A message flow in which the sender's software composes a surface label, mirrors it inside the sealed body, and stages it as a plaintext label in a sidecar descriptor. On reading, decryption and the header binding checks run first; the label is then compared with the sealed sender, recipient, priority flag, and lane, and with the descriptor label. A mismatch flags the message for triage and does not refuse an otherwise valid message. This flow uses an addressing grammar of its own (), not the version 1 grammar.
An admission predicate for archives with the outcomes producer_bound, carried, refused, and unprovable, which rejects a caller's claim to have checked key currentness rather than honouring it; and an open path that derives the predicate's inputs from the archive bytes via the codec's binding report, in which a verified forward expectation cannot lift a failing admission and the refusal names the admission.
Admission on read for tool descriptors ("a raw file is not a tool"): one bounded read; schema validation; a declared surface that must embed the descriptor's own name; admission only by a release-signed hash-manifest pin or a local receipt bound to the descriptor digest; otherwise the descriptor is inert and is listed separately from usable tools.
A cold storage path that treats decryption as proof of nothing about origin, requires the package signer to equal an externally held root key, and refuses containers that set the in-band surface flag.
A registry of named local surfaces with classes and default projections, whose stated rule is that a readable filename is not authority and whose fallback may only degrade.

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.

Maturity:

Research implementation under active development.

Licensing:

AGPL-3.0-or-later.

Contact:

Jasper van de Meent, info@humotica.com.

Security Considerations 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 (). The following threats were made concrete during implementation:

Rename and disguise. An attacker renames an arbitrary file so that its surface implies a sealed container, or renames a container so that its surface implies a different profile or recipient. Type recognition by magic bytes () and surface-to-manifest comparison () address these. Conversely, because the name carries no authority, a sender can give a carrier any name, including one chosen for the recipient; this is a property, not a weakness, provided no consumer relies on the name.
Unauthenticated in-band fields. A header field inside the object but outside its integrity coverage can be altered without breaking any signature. Treating such a field as intrinsic would let an attacker change classification while verification still passes ().
Embedded keys. A signature that verifies under a key carried in the same object proves only that whoever made the object held that key ().
Expectation as grant. If a matched routing pattern or a pre-arranged expectation is allowed to stand in for admission, anyone able to produce an object that matches the expectation obtains admission.
Downgrade by tooling. If an older or absent verifier yields a benign default, running old tooling becomes a way past the check. Unverifiable must mean unprovable.
Check and use. If a consumer verifies one read of an object and then uses a second read, the object can be replaced in between ().
Silent drop. A pipeline that logs an arrival and then takes no decision gives the appearance of handling without its effect ().

Magic bytes are public and trivially reproduced. They identify a format; they do not authenticate anything.

Privacy Considerations 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 (), 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 () retains the name an operator chose; if names may carry personal information, audit records of renames carry it too.

Interoperability Considerations 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.

Surface Grammars Other Than Version 1 Implementation experience shows that deployments may use a surface grammar other than the version 1 dispatch grammar of . 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 , the separation of , and the mismatch classes of 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.

Relationship to JIS, TIBET, TAT, and ICC 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.

Future Work

richer but still bounded registries for profile
explicit mirrored-surface validation modes
MUX or SNAFT routing integration
UI conventions for displaying safe routing metadata
signed or policy-bound surface-to-manifest binding hints
bringing in-band surface and payload-class bytes of container formats under the container's integrity mechanism
a registry or identifier scheme for surface grammars other than version 1
test vectors for disguised surfaces, renamed carriers, and mismatch classes

Questions for Future Revisions The following topics are non-blocking for the present -03 revision and are recorded here to guide later discussion and interoperability work.

whether profile should remain open-text or move to a tighter registry
whether the optional suffix should be preserved, normalized, or ignored by parsers
whether seconds-level time fragments should be allowed in version 1
whether some domains should escalate all mismatch to quarantine while others allow low-risk auto-continue
whether an addressing grammar that names sender and recipient should be specified as a second surface grammar, given its privacy cost
whether this document should define a minimal admission verdict vocabulary, or leave it to each consumer

IANA Considerations This document requests two registries: a Surface Profile Registry and a Surface Priority Registry. Registration policy for both is Expert Review as described in . 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.

References Normative References Key words for use in RFCs to Indicate Requirement Levels Augmented BNF for Syntax Specifications: ABNF Guidelines for Writing an IANA Considerations Section in RFCs Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words Informative References Improving Awareness of Running Code: The Implementation Status Section

Changes from -02

Abstract: added a paragraph on the distinction between routing hints and admission verdicts; added keyword "admission".
Section 1: the former "Status of This Memo (-02 revision)" section is renamed "Introduction", describes the purpose of the document, and summarizes this revision. The stale statement that the present version is -00 is removed.
Section 2 (new): Requirements Language (BCP 14). The Claim-Verified and SAM sections already used uppercase key words; RFC 2119 and RFC 8174 are added as normative references.
Section 3: added a paragraph on the risk of a readable surface being read as a decision.
Section 4: "Intrinsic Truth" now requires integrity coverage, not mere location inside the object; "Extrinsic Surface" and "Surface-Integrity Event" adjusted accordingly; new terms Carrier, Sidecar Descriptor, Routing Hint, Admission Verdict, and Arrival.
Section 5: added the design goal that a surface is not an admission input.
Section 6: a name that does not match the grammar is not a version 1 surface and must not be repaired into one; pointer to other grammars. The ABNF is unchanged.
Section 8: profile values may be used as an expectation that an object is sealed, as a routing hint only; new subsection Unknown Values (fallback may degrade, never elevate).
Section 9 (new): Surface Carriage (object name, sidecar descriptor, in-band header outside or inside integrity coverage, mirrored sealed fields).
Section 10: Processing Model keywords made normative (MAY, SHOULD, MUST) where -02 used lowercase. Type Sniff: version- independent family recognition, disguised surfaces, renamed carriers, magic bytes as necessary but not sufficient, in-flight writes. Deep Verification: origin requires an externally anchored key; key currentness is a separate axis; unverifiable is unprovable. New subsections Admission and Recorded Disposition. Surface-to-Manifest Consistency: compare after verification, include sidecar labels, mismatch must not be accepted silently.
Section 11 (new): Routing Hints and Admission Verdicts, including expectations that narrow but do not grant.
Section 12: mirrored fields as the durable copy; rename detection by reconstructing the canonical name.
Section 13: the example now identifies which steps are routing, type recognition, admission inputs, and the admitted action.
Section 14: Routing-Risk Mismatch examples added; new mismatch class Disguised Surface.
Section 15 (new): Self-Describing Artefacts (admission on read, inert until admitted, external anchor, single bounded read).
Section 17: the reference to the Claim-Verified Extension previously read "Section 13" and pointed at the wrong section; it is now a cross-reference.
Section 18 (new): Implementation Status per RFC 7942.
Section 19: Security Considerations extended with threats made concrete during implementation.
Section 20: Privacy Considerations extended for addressing surfaces and recorded renames.
Section 21: new subsection on surface grammars other than version 1.
Section 22: added the address, truth, and intent split.
Sections 23 and 24: new future-work items and questions; stale "-00" reference corrected.
Section 25: states that this revision requests no additional registries.
References split into normative and informative; RFC 2119, RFC 8174, and RFC 7942 added.
The Claim-Verified and SAM extensions are otherwise unchanged.

Acknowledgements 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.