Upgrade and migration

This guide describes the explicit development-profile transition to the RC1 implementation candidate. It preserves earlier signed records and wire-version boundaries; it does not approve a production deployment.

Versions are not interchangeable

Material	Preserved identity	Transition
Native policy	1.2.0-draft.1	Keep the same tested policy semantics; advance a policy revision whenever exact published bytes change
Public historical service/receipt/evidence	1.2.0-draft.2	Keep its original validator, signatures and immutable download; do not rewrite envelope versions
Current service/authority/asset contracts	1.2.0-draft.3	Select the current exact family; create new current agreements rather than relabelling old ones
Fixed quote	fixed-quote-v1	Explicit accepted quote and separately authenticated payer mandate; all-zero use stays on the free profile
Continuing storage	storage_sessions_v1	Select it in request, offer, signed acceptance and receipt before emitting selected session events
Asset publication	asset_evidence_v1	Publish immutable version/representation identities with current origin-appointed publication authority
Observation coverage	observation_coverage_v1	Publish the separate exact-policy-bound registry; it does not alter agreement or event shapes
Archive combinations	Exact profile IDs in the specification	Select ordinary/storage/asset and free/paid explicitly; never infer or downgrade a failed combination
Python distribution	0.0.0.dev3	Package version is independent of wire compatibility; current command is odexa-current, legacy command remains odexa-reference

Draft 3 distinguishes origin, selected service, operator issuer and explicit delegation in the common binding. Its current operational metadata supports scoped capabilities and role-specific keys. Paid, continuing-storage and asset archive shapes are explicit additions, not permissive fields accepted by ordinary free handlers. Each message is validated as the original selected document; a temporary projection used internally for shared unversioned checks is never an accepted rewritten signature payload.

Install and stage a current operator

1. Retain the original service configuration, exact accepted evidence, authority history and any existing immutable published packages. Keep their private credentials outside archives and web roots.
2. Install the current package into a separate environment using CURRENT-QUICKSTART.md. Use odexa-current init in a fresh private directory. The initializer deliberately refuses an existing configuration; it is not a database upgrader.
3. Provision the intended origin/service/issuer, new keys and independently scoped role credentials. Verify actual TLS and origin publication before admitting agents. A same-origin free deployment needs no payment or third-party account.
4. For a new provider or changed contract/profile, follow the fresh-agreement handover. Publish origin-controlled appointment changes, obtain fresh assent, and keep old accepted obligations/evidence tied to their original identities. A new paid arrangement needs its own accepted quote and payer mandate.
5. Verify independent observation, exact receipts/retries, protected retrieval, original reporting, revocation and separately pinned archive verification before exposing the deployment. The reference’s installed flow and independent Node clients provide reproducible checks; they do not configure a production reverse proxy or provider payment rail.

There is no in-place conversion of a draft-2 database, active token, signed receipt or running managed-copy session into draft 3. Storage copies do not gain a renewed acquisition time or retention deadline when a service changes. A moved asset URL does not inherit an old URL-scoped bearer grant. Export/import preserves inert evidence; it does not transfer live access or legal rights automatically.

Keys, origin history and rollback

Rotation uses a new key ID, independently published overlap and the documented active/retired/revoked states. Preserve original signatures and their historical context. Known compromise remains disqualifying under the selected verifier; retirement alone is a different state. Service identity changes use new origin-qualified IDs/issuers. Exact old quote/verifier-route bindings do not silently follow a new endpoint.

Do not roll an origin revision backward to undo a deployment. If a publication needs correction, publish a new monotonically increasing revision. Do not restore a live service/history database from an old copy and assume its expired tokens or withdrawn keys are current. Local history is not an anti-rollback guarantee against a privileged administrator; recovery needs independently current origin knowledge and reconciliation of durable state.

A static website rollback can restore its previous page/artifact links while retaining immutable releases and operational history. It does not justify rewriting earlier policy, authority, agreement or asset bytes under their existing identities. The release publication plan keeps website rollback separate from protocol-state recovery.

Managed storage journal compatibility

The integrated correction adds a local cancelled intent state for custody refused before any managed bytes are written. It has no completed-write or session evidence and is not a new wire event. Existing journals remain readable by the corrected executor. Older executors can reject journals containing cancelled entries; do not downgrade over such a journal or rewrite those entries into active/completed custody. Retain the corrected executor and exact journal during recovery. An uncertain cleanup/persistence outcome still blocks dependent use.

Evidence

The final current-source run includes the six actual two-provider handover methods, key/history cases, paid evidence replay and the independent free/paid/storage/asset clients. The requirement map links exact methods, and the release audit identifies completed review dispositions and outstanding operational prerequisites. No candidate is approved merely by following an upgrade command.