> ## Documentation Index > Fetch the complete documentation index at: https://docs.bijection.com/llms.txt > Use this file to discover all available pages before exploring further. # Application transitions > Publish code, review business changes, adopt scenario results, and follow external delivery through their original owners An application uses ordinary generated queries, mutations and actions. Add an Operation when a business action needs a durable request, a tentative assessment, independent approval or a retained acceptance. Git versions application source; the execution context selects the installed program and database. ## One vocabulary, distinct responsibilities | Name | Meaning | | - | - | | Application | The installed functions, schema and component declarations. | | Context | An exact deployment incarnation and live state, branch generation or retained snapshot. | | Request | Original caller, arguments, contract and destination retained before dispatch. | | Run | Work whose execution, result availability and cleanup can progress independently. | | Plan | Proposed business intent with typed modeled, predicted or confirmed evidence. | | Release | An immutable installed executable selected for publication. | | Review | An assessment of exact intended meaning, with current approval requirements. | | Decision | A person's approval or rejection of that assessed meaning. | | Receipt | Evidence that the local transition committed. External delivery has its own owner. | A shared Review protocol does not make business approval into deployment authority. Permission to see a reference does not permit reading its source, executing its operation or installing its code. ```mermaid theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} flowchart LR Git[Git source] --> Build[Build or capture Release] Build --> CodeReview[Program Review] CodeReview --> Installed[Install program] Scenario[Isolated scenario Run] --> Result[Retained modeled result] Result --> Plan[Live Plan with current evidence] Plan --> BusinessReview[Operation Review] BusinessReview --> Commit[Atomic business commit and receipt] Commit --> Delivery[External delivery owner] Delivery --> Observation[Confirmed or uncertain provider outcome] ``` ## Select source and runtime separately ```sh theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} git switch feature/correction bijection deployment select warehouse:prod --branch what-if bijection status bijection dev ``` `git switch` changes files. `deployment select` changes where new application commands run. `dev` installs source in the selected writable context. A retained request, Review or run reference continues to identify its original destination after navigation. A snapshot is read-only. A stale generation refuses instead of silently selecting live or a replacement branch. ## Request a reviewed business transition ```sh theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} bijection operation run invoices:applyCorrectionPlan \ organization=acme plan_id= revision= \ --deployment warehouse:prod --request-id "$REQUEST_ID" --format json bijection request get --format json bijection request wait --until assessed --timeout 30s --format json bijection operation share-review --format json ``` The optional `--request-id` accepts an original UUIDv7. Omit it on a first call to have the CLI generate and retain one; `$REQUEST_ID` above names that original ID when recovering it. One request ID retains one meaning. Repeating the original call with identical arguments recovers it; changing its arguments under that ID refuses. The server owns preparation through an ordinary action that coordinates retained component mutations and native assessment under the authenticated caller. There is no separate preparation key in the ordinary CLI. An interrupted backend action requires explicit resumption; it reuses the retained assessment ticket. Background programs require their own explicit authority. A lost reply is uncertainty about that original request, not proof that nothing happened. Keep the returned request reference, or use `--save-request` for a portable private custody file. An eligible reviewer opens the shared reference under their own identity: ```sh theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} bijection review get @review.json --format json > observation.json bijection review watch @review.json --format jsonl # When assessment.kind is available, save observation.ref as assessment.json. bijection review approve @review.json --assessment @assessment.json --policy organization ``` The authorized requester explicitly applies that exact Review: ```sh theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} bijection review apply @review.json --format json ``` Read, watch and wait only observe. Approval records a decision; it does not apply business state. Application rechecks the current source, permissions, candidate and decision. An accepted result carries its receipt. A pending result states its remaining requirements. A refused result states its reason. ## Adopt a scenario through a live Plan The maintained `examples/governed-export` application exports these ordinary generated functions. Its small model evaluates an assumed invoice amount; it reads no protected business source during simulation. Live source confirmation is acquired independently by the Planning inspector. These snippets are generated from `examples/governed-export/client.ts`, which imports the application's generated `api` and is checked with its TypeScript project. Pass the same original scenario ID after an uncertain start; observe execution and availability before proposing adoption. ```ts theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} import type { BijectionClient, BijectionHttpClient } from "bijection/browser"; import type { FunctionArgs, FunctionReturnType } from "bijection/server"; import { createOperationClient, operationReference, } from "@bijectionhq/operations/browser"; import { api } from "./bijection/_generated/api.js"; type CorrectionRun = FunctionReturnType; type CorrectionPlan = FunctionReturnType; ``` ```ts theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} export function startScenario( client: BijectionHttpClient, input: FunctionArgs, ) { // Retain input.request_id before dispatch; reuse it after an uncertain reply. return client.mutation(api.correctionScenario.start, input); } ``` ```ts theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} export function observeScenario( client: BijectionClient, run: CorrectionRun, render: (view: FunctionReturnType) => void, ) { return client.onUpdate(api.correctionScenario.get, { run }, render); } ``` ```ts theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} export function proposePlan( client: BijectionHttpClient, input: { organization: string; request_id: string; run: CorrectionRun }, ) { // Live loads the retained result and current evidence through its inspector. return client.mutation(api.correctionPlans.propose, input); } ``` The live Plan is only a proposal. Request its assessed business transition with an original UUIDv7; independently review it and explicitly apply the Review. ```ts theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} export function requestPlan( client: BijectionHttpClient, organization: string, plan: CorrectionPlan, request_id: string, ) { // request_id is an original UUIDv7. This assesses; approval never auto-applies. return createOperationClient(client).run( operationReference(api.invoices.applyCorrectionPlan), { organization, plan_id: plan.id, revision: plan.revision }, { request_id }, ); } ``` The reference contains the live coordinator's deployment, incarnation and exact branch location plus its original run ID. The installed inspector resolves the result through that owner, verifies its business scope, and acquires current source evidence. Caller-authored amounts and branch-local record IDs are not accepted as replacement evidence. ```mermaid theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} sequenceDiagram participant User participant Simulation participant Planning participant Source as Current source participant Operations participant Reviewer User->>Simulation: start with original request ID Simulation-->>User: qualified run reference User->>Planning: propose from that run Planning->>Simulation: read original retained result Planning->>Source: read complete current authorized join Planning-->>User: modeled candidate plus required confirmed basis User->>Operations: request application of exact Plan revision Reviewer->>Operations: approve assessed meaning independently User->>Operations: apply exact Review Operations->>Planning: recheck original result and required evidence Operations->>Source: authorize and write current business state Operations-->>User: atomic Plan application and acceptance receipt ``` The candidate remains modeled. Required evidence can demand confirmation; modeled and predicted claims cannot satisfy that condition. Changing any joined source value invalidates the earlier fingerprint. A new proposal and a new assessment need fresh consent. `invoices:applyCorrectionPlan` composes `plans.apply` with the existing local invoice writer in one ordinary mutation transaction. Plan bookkeeping, business writes and the Operations receipt either commit together or roll back together. Retiring the scenario does not undo an accepted live operation: ```ts theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} export function retireScenario( client: BijectionHttpClient, run: CorrectionRun, ) { // Retirement does not undo live acceptance. Observe cleanup separately. return client.mutation(api.correctionScenario.retire, { run }); } ``` ## Publish code through the same Review vocabulary ```sh theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}} bijection release capture what-if --request-id release-42 --format json bijection review create --subject --target warehouse:prod \ --request-id install-42 --format json bijection review get --format json bijection review wait --until assessed --timeout 30s --format json bijection review apply --format json ``` Program governance determines eligible reviewers and required domains. Program installation consumes current deployment authority. It does not merge private business records. The Release, Review and acceptance retain their exact source and target identities through recovery. ## Follow external completion separately Local acceptance can atomically admit delivery, but it cannot establish a provider's eventual outcome. Follow the delivery reference through Connections. A child can finish while its siblings remain pending. A provider timeout can leave an uncertain outcome; repeating the business request is not permission to resend an uncertain effect. The maintained reference runner inventories four journeys: code publication, reviewed business acceptance, scenario adoption and external delivery. Its qualification receipts bind the exact SDK, CLI, generated bindings, component fork lock, application program and backend build identities. Source tests do not establish deployed behavior. Atlas qualification runs only when explicitly requested; unfinished cases and pending cleanup stay visible in its report. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.