Skip to content

Bounded informational-Rote exchange

This capability implements one operator-mediated exchange between explicitly verified AncientOS instances. It is a Rote domain executor over Core identity, governed execution, Rubick registration, Zeus evidence, and LifeVault raw custody. It adds no listener, discovery service, public advertisement, index, or autonomous execution. The default conversational runtime does not register this executor. The explicit operator surface is python -m app.transports.rote_cli.

Authority and identity

The CLI authenticates LUNA_ROTE_SESSION_TOKEN against the existing operator web session registry. It never authenticates identity supplied in the JSON request. LUNA_DATA_DIR and LUNA_GOVERNED_STATE_DB_PATH select the instance's normal storage; these are trusted deployment configuration, not peer-controlled inputs. The existing environment bootstrap provisions configured principal/session records. The runtime image includes the unchanged canonical path policy required by a fresh Rubick bootstrap; this capability does not relax its rules. The authentication context retains its web_tui credential provenance; evidence separately records requested_interface=rote_cli and the actual executor. Other trusted ingress adapters can pass their attested principal context to the same transport-neutral service.

Each initialized instance has an independent Ed25519 key in the existing operator identity database, restricted to filesystem mode 0600. Its identifier derives from its public key. Local principal authorization creates its declaration. An operator must independently verify the intended counterpart's principal/instance fingerprint before explicitly pinning the declaration. Self-signing proves key control; it does not alone establish the principal association. The independently verified pin is the bounded trust anchor. Nothing performs automatic trust-on-first-use.

Bindings expire within one day and admit only that exact instance. Replacement requires another verified binding; replacing a principal's current peer pin does not erase historical evidence or migrate old consent. No legal identity, provider account, global directory, or general delegation mechanism is required.

The shared broker supports explicit_principal_instruction only when the capability registry explicitly declares that mode. It consumes an exact, short-lived local principal instruction before claiming execution. Existing Lich-required capabilities keep their Lich gate. Capability visibility does not authenticate a peer or grant redistribution rights. No transport-specific Lich bypass is introduced.

Operator-mediated flow

Every command reads one bounded JSON object from standard input, requires a unique --request-id, and writes its result to standard output. Protected refusals have one shape and message: No exchange is offered for this request. Private artifacts must be carried over an already authorized channel; signatures authenticate their origin and integrity, not confidentiality. No transport channel is selected or created here.

  1. initialize on each instance returns its signed declaration. Verify the identity association independently and compare content_hash(declaration.payload.speaker).
  2. bind takes declaration, that independently obtained fingerprint, an absolute expires_at within one day, and the exact verification statement: I independently verified this principal and instance fingerprint with the intended peer.
  3. create takes kind=informational, up to 8192 UTF-8 content bytes, a purpose of at most 240 characters, and the explicit rights statement below. Its identity binds the complete informational text, purpose, and originating principal/instance.
  4. offer takes rote_id, a unique bounded exchange identifier, the exact recipient identity, validity of at most 300 seconds, and the offer rights statement below. The signed offer reveals only the exact object binding, purpose, content size, informational effect, involved identities, bounded rights assertion and restrictions.
  5. B reviews the offer and invokes consent with offer and the exact decision below. The resulting signature binds the entire offer, exchange, sender, recipient and Rote.
  6. A invokes transfer with offer and consent. Both authority contexts must match; only the exact originally authorized content is released once. Deliver its returned signed artifact to B. No unrelated metadata or holdings are included.
  7. B invokes receive with transfer. Current peer binding, authenticity, exact local consent, validity and content identity are checked before raw LifeVault custody. The returned signed receipt acknowledges actual verified informational retention.
  8. A invokes receipt with exchange and receipt. Only B's exact authentic result is admitted. An intermediary's delivery report is insufficient.

Exact original rights statement:

I originated this content and authorize its retention; no third-party or confidential material is included.

Exact offer rights statement:

I authorize this exact offer disclosure and one transfer to this recipient under the stated restrictions.

Exact recipient decision:

Receive and retain this exact informational Rote and acknowledge the observed result under these restrictions.

These authenticated assertions are retained as assertions, not independently proved copyright findings. This first capability supports only principal-originated material with these explicit assertions. Missing, third-party or otherwise unresolved rights fail closed. Import does not create an original-rights record, so prior receipt cannot be used as authority for an onward offer.

Custody, evidence and failure

Unadmitted request bodies remain in a bounded, request-local buffer. Core action and principal records bind their exact hash rather than retaining unverified remote content. The executor checks that hash again before use; the buffer is discarded after the command.

ArtifactStore retains bounded inert bytes. Offers and transfers resolve their content from hash-verified LifeVault custody; Zeus retains the rights/custody linkage and cannot resurrect content when that custody is absent or damaged. LifeVault EvidenceStore records raw, unindexed cognition with acquisition provenance. The existing Rubick memory.enabled gate is checked before custody. A backward-compatible LifeVault custody_only flag prevents later ordinary keyword rebuilds, semantic indexing, reasoning-use and promotion from treating retention as authority. Ordinary evidence defaults to its existing behavior. There is no operation in this slice that clears this restriction. This small shared extension is required because unrelated future ingestion can rebuild the ordinary memory index. No parser executes embedded text, no retrieval index is rebuilt, and no capability or configuration is installed. Future explicit governance remains necessary for any additional effect. An executable kind is unsupported. Informational content is not asserted to be true.

Zeus retains principal authorizer, authentication transport, interface, executor, exact authority reference, peer binding evidence, signed consent/transfer/receipt, rights assertions, restrictions and execution results. Local provenance and a remote claim remain distinguishable. Existing PendingAction records provide durable local execution and remote-phase replay claims; no additional evidence or memory store is introduced. Claims survive restart. Exceptions after custody might have started produce an uncertain broker outcome requiring inspection rather than invented success.

Disclosure/transfer is not reversible by a local rollback, and no remote erasure is claimed. Preserve governed history. Older memory consumers that do not understand custody_only must not be used with these records during a downgrade.

Replayed consent cannot authorize another exchange or another transfer. Duplicate receive cannot create a second acquisition. A late receipt can acknowledge only its original transfer while its peer binding remains valid. Missing acknowledgement leaves the result unknown; no automatic retry occurs. Refusal text does not disclose private holdings or reasons. Timing and repeated-query leakage are not claimed solved.

The cryptographic implementation uses the library's documented Ed25519 signing and verification interface. There is no claim that authentication proves a remote instance's honesty or prevents its principal from violating restrictions outside AncientOS. Local database access and trusted authentication ingress remain within the existing platform trust boundary.

Validation and scope

Observational received-Rote inspection

The shared runtime registers the reviewed operator-only rote_received_inspection operation on rote_informational_exchange through InspectionAdapters.rote_received_inspection. Registration requires the existing implemented capability and enabled, wired runtime provider. This read registration does not register the exchange executor or change its explicit authority requirements.

The operation accepts an optional bounded exchange reference. Without one, exactly one local received receipt must exist; zero receipts are unavailable and multiple receipts require an explicit reference. The reader opens the already-wired Zeus database read-only, checks the receiving principal, verifies existing custody fact hashes and signed consent, offer and receipt bindings, and projects only stable Rote and exchange identity, provenance, restrictions, receipt and evidence metadata. It does not read retained Rote content or create identity, custody or evidence. Historical receipt metadata does not establish current possession, independent trust, endorsement, redistribution rights or additional execution authority.

Missing or inconsistent evidence fails closed. In particular, an empty canonical Zeus receipt state returns no_received_rote_evidence; a receipt from isolated peer acceptance storage cannot establish receipt by this runtime. A genuine authorized exchange into the canonical receiving instance is the prerequisite for inspection. Conversational inquiries may begin with the optional direct address Luna,; the shared observational classifier still requires an observational verb and retains its existing authority and mutation exclusions. When repository discovery is selected alongside an independent reviewed read, composition retains both in the existing bounded inspection batch. Initial corpus ranges still become discovery until actual paths are established. Document-led investigations keep their existing route and separately execute and retain selected independent reads; explicit investigation continuations keep their existing route. Every retained operation remains subject to registration and principal revalidation.

tests/test_rote_received_inspection.py verifies the registry gates, real existing exchange facts, metadata projection, database non-mutation, transport parity, fail-closed evidence handling and narrow direct-address classification. Deployed acceptance must exercise the authenticated conversational runtime; registry presence alone is insufficient to establish successful inspection of a received Rote.

Exchange validation

tests/test_rote_exchange.py exercises real keys, independent registry databases, Core brokerage, LifeVault custody, signed receipts, private refusals, all seven peer admission failure classes, replacement/rebinding, replay, tampering, informational limits and principal/Lich separation. Existing broker and principal-setting suites cover platform regression. Deployed acceptance must use the packaged CLI across two separate instance custody/identity contexts; an in-process test is insufficient.

Deferred: discovery, public indexes, networking services, executable Rotes, general rights negotiation, onward propagation, recovery protocols and collectible markets.