# Sovereign operations: implementation and handoff Edition 2.6.1 adds signed release staging, recoverable deletion, real local search and object adapters, and encrypted isolated recovery. These are executable local components. They do not claim production deployment, a completed device installer, external provider deletion or independent custody. ## Reproduce the implementation Use Python 3.11 or newer. The base runtime uses the standard library. Release staging and encrypted recovery require the optional `release` dependency: ```sh python3 -m pip install '.[release]' python3 -m unittest discover -s tests -v python3 scripts/validate_package.py python3 scripts/handoff_rehearsal.py ``` The crypto path was tested with cryptography 46.0.0. This is a reproduction pin, not a statement that the version has passed a current independent vulnerability review. The fresh-directory rehearsal uses the already installed interpreter dependencies; it does not prove a fresh offline package installation. ## Release staging `zora_core.release_artifacts.ReleaseStager` receives a trusted device binding, release public keys, owner public keys, and an authoritative current-consent callback. Neither keys nor callback come from the downloaded release. 1. Build an opaque release artifact, limited to 64 MiB in this reference. 2. Create a `zora.release.v1` manifest containing release ID, monotonic sequence, version, platform, channel, SHA-256, byte length, issue time and expiry. 3. Sign the manifest with the release signing key using `sign`. The envelope binds its key ID and payload under a dedicated domain prefix. 4. Obtain a separate owner-signed `zora.release-consent.v1` grant binding that manifest hash to the exact device, tenant, expiry and consent ID. 5. Construct a stager in the owned host with pinned public keys. Its callback must check current consent; unknown or offline consent returns false. 6. Call `stage(owner, artifact_path, signed_manifest, signed_grant)`. 7. Treat the result as staged bytes only. The result explicitly says `installed: false`. No archive is unpacked and no code is launched. Sequence history prevents staging an older release while the local state is intact. Reissuing different bytes at the same sequence is rejected. Replaying the same release checks the staged bytes again. Signature, ownership, platform, expiry, consent and artifact-hash failures stop staging. The existing fleet API's boolean signature report is still historical metadata; it is not cryptographic device attestation. Production work remains: release-key custody and revocation, authenticated owner-key provisioning, online grant binding to fleet records, platform-specific installation, health-checked activation, rollback recovery and real-device testing. An attacker able to restore both the local device database and filesystem can bypass a purely local sequence floor; hardware or independently retained antirollback state is still required. ## Deletion across stores `PrivacyJobs` freezes the store names and adapter revisions at request creation. The owner supplies record IDs and an idempotency key, never a Python import, filesystem path, tenant override or store configuration. The delivered adapters are: - Memory: SQLite records and deletion tombstones commit with the receipt. - Search: tenant-filtered SQLite FTS5 index plus underlying records; deletion removes both and prevents reuse of the deleted record ID. - Objects: tenant-and-record-hashed file paths; durable deletion intent hides records before unlink, then reconciles an interrupted unlink on the next pass. Use `local_registry(runtime, include_search=True, object_root=owned_path)` for all three. The object root is pinned in the database. Supply consistent host configuration after restart. Existing unrelated files are never imported. The loopback API defaults to memory only. Set `ZORA_PRIVACY_SEARCH=1` and `ZORA_PRIVACY_OBJECT_ROOT` in the owned server environment to register the other local adapters. This does not automatically migrate the existing website or canonical runtime into these stores. A request reports exactly its frozen store coverage; adding a store later requires another request for that expanded scope. The new API routes are: - POST `/v1/privacy/jobs/request`: owner record IDs and request ID. - POST `/v1/privacy/jobs/status`: owner-visible status by job ID. - POST `/v1/privacy/jobs/run`: same-tenant authority executes one store step. - POST `/v1/privacy/jobs/retry-review`: same-tenant authority records a review note before resetting exhausted retries. Reconciliation remains mandatory. Customers can request and inspect their own jobs. A company authority principal does not acquire access to a personal tenant by calling these routes. Processing requires an authority identity in that same tenant, authenticated by the host. The reference's static local tokens must become scoped workload identities before production deployment. ## Run without a chat session Use this bounded command in an owned scheduler with the same registry as the API: ```sh python3 -m zora_core.privacy_worker --db /owned/path/state.db --tenant tenant-id --include-search --object-root /owned/path/objects ``` It processes at most 25 eligible store steps per invocation and continues other steps when one is blocked. It does not install a scheduler, send notifications or grant itself remote authority. Protect its database and configuration using the tenant's service identity. Omit the optional flags for a memory-only registry. Each step has a lease and at most five attempts before review. A timeout produces an unknown result; the next attempt reconciles the stable operation ID before any new deletion. Local object reconciliation finishes only the durable original intent. A retained record reports a retention exception, never complete erasure. Exception strings from adapters are redacted because they can contain secrets. Deletion here means removal from active logical records and managed object paths. It does not prove forensic erasure from SQLite free pages, operating-system caches, filesystem snapshots, provider stores or backups. Those require deployed retention/expiry, encryption-key lifecycle and independently verified procedures. ## Encrypted recovery `recovery.seal` takes an owner principal, an externally supplied 32-byte key and a new output path. It copies the database consistently, verifies integrity and requires exactly one tenant. Mixed-tenant databases are rejected. AES-GCM authenticates the ciphertext and binds it to the tenant; the nonce is generated fresh for each seal. The key is never included in the backup or receipt. The returned digest must be retained by an independent custodian. Keep the key under separate controlled custody; placing it next to the ciphertext defeats the intended separation. This implementation does not provision a KMS or custodian. `recovery.restore` requires the ciphertext, key, tenant, independently retained digest, current external tombstone list and a new output path. It verifies the digest, decrypts, checks SQLite integrity and the audit chain, reapplies memory tombstones, and sets the operational stop flag before publishing the isolated database. It never overwrites an existing destination or starts a service. An empty tombstone list is an explicit caller assertion, not evidence that no deletions occurred. The recovery operator must independently prove completeness and freshness before reopening service. This database-only backup excludes external object files. When store tables are present, provide current `store_tombstones` explicitly, using the owner-scoped `RecordStore.tombstones` export from independent custody. Restore applies search deletion and quarantines every object-root binding so it cannot reattach to live files. Restore and reconcile object storage separately in isolation; that file-restoration procedure is not implemented by this module. Whole-database substitution is only detectable against a genuinely independent retained digest. ## Source reconciliation The additional ZoraCoreInspection archive was inspected. It contains local brain, mailbox, console, continuity and runtime interfaces. It is not a verified current public ambassador gateway and does not contain the full current ZoraTrade product. These files were not exposed as a public website service or redistributed as customer-facing identity context. The gap remains a specific source/deployment dependency; it does not stop the independent work delivered here. ## Verification and remaining acceptance Edition 2.6.1 has 93 passing local tests. New tests exercise signed-byte tampering, wrong-owner grants, expiry, revocation, sequence rollback, staged corruption, three-store erasure, interrupted unlink recovery, timeout reconciliation, same-tenant authority, foreign-owner HTTP denial, retention exceptions, retry review, backup tampering, wrong keys, later deletion replay and no-overwrite restore. No production acceptance group is promoted by these local results. External providers, independent custody, fresh machine setup, real devices, security review and the canonical website connection remain separate acceptance work. ## Implementation references The cryptographic APIs follow the versioned upstream documentation: - https://cryptography.io/en/46.0.0/hazmat/primitives/asymmetric/ed25519/ - https://cryptography.io/en/46.0.0/hazmat/primitives/aead/ These references support the API usage, not a certification of the surrounding system or a claim of independent security audit. ## Operational health GET `/v1/operations/health` is restricted to same-tenant authority. It reports queue counts, expired leases, review age, unresolved assessment cost, privacy step states and local audit-chain validity without conversation or task payloads. Company and privacy processing loops emit local heartbeats. A heartbeat older than five minutes is flagged; missing components remain unobserved. These heartbeats indicate loop activity, not that every department is healthy or that work succeeded. The endpoint does not send external notifications or certify production health. Deploy a scoped collector and alert destination in the owned environment before treating it as monitored operations.