Application transitions

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.

Select source and runtime separately

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

bijection operation run invoices:applyCorrectionPlan \
  organization=acme plan_id=<plan-id> revision=<plan-revision> \
  --deployment warehouse:prod --request-id "$REQUEST_ID" --format json
bijection request get <original-request> --format json
bijection request wait <original-request> --until assessed --timeout 30s --format json
bijection operation share-review <original-request> --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:

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:

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.

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<typeof api.correctionScenario.start>;
type CorrectionPlan = FunctionReturnType<typeof api.correctionPlans.propose>;

export function startScenario(
  client: BijectionHttpClient,
  input: FunctionArgs<typeof api.correctionScenario.start>,
) {
  // Retain input.request_id before dispatch; reuse it after an uncertain reply.
  return client.mutation(api.correctionScenario.start, input);
}

export function observeScenario(
  client: BijectionClient,
  run: CorrectionRun,
  render: (view: FunctionReturnType<typeof api.correctionScenario.get>) => void,
) {
  return client.onUpdate(api.correctionScenario.get, { run }, render);
}

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.

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

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

bijection release capture what-if --request-id release-42 --format json
bijection review create --subject <release-reference> --target warehouse:prod \
  --request-id install-42 --format json
bijection review get <review-reference> --format json
bijection review wait <review-reference> --until assessed --timeout 30s --format json
bijection review apply <review-reference> --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.

Get Started

Use-case atlas

Platform

Data and Operations

Guides

Client Libraries

Tools

API Reference

Application transitions

One vocabulary, distinct responsibilities

Select source and runtime separately

Request a reviewed business transition

Adopt a scenario through a live Plan

Publish code through the same Review vocabulary

Follow external completion separately

​One vocabulary, distinct responsibilities

​Select source and runtime separately

​Request a reviewed business transition

​Adopt a scenario through a live Plan

​Publish code through the same Review vocabulary

​Follow external completion separately

One vocabulary, distinct responsibilities

Select source and runtime separately

Request a reviewed business transition

Adopt a scenario through a live Plan

Publish code through the same Review vocabulary

Follow external completion separately