Refresh, review and accept

Branches are in beta.

Application code and operational intent use the same Review protocol with typed subjects. Git owns source history; the deployment owner installs an exact release. A Change captures an immutable revision of business operations; an assessment evaluates it against live. Ordinary record updates use typed operations and durable request IDs. They need no commit, push or merge request.

One SDK contract across execution contexts

Resolve a name once, then retain its exact generation reference. Opening that reference is local and every use rechecks the original generation and access.

const branch = await client.branches.resolve("what-if");
const savedBranch = branch.ref;
const reopened = client.branches.open(savedBranch);
const value = await reopened.query(api.inventory.total, {});
const evidence = await reopened.queryWithBasis(api.inventory.total, {});
const accepted = await reopened.operation(
  api.inventory.reserve,
  { target: orderId, args: { quantity: 3 } },
  { requestId: "reserve-1" },
);

query returns the application value in live, branch and snapshot contexts. queryWithBasis returns { value, basis } for comparisons and evidence. Ordinary commands throw RequestUnconfirmed with requestRef after a lost reply. Explicit request handles also expose uncertainty in their observation state. Reopening or observing a request never creates a replacement intention. SDK composition uses requestId, expectedVersion, approvalContract, retainFor and timeoutMs. Retired spellings are refused. Native records and serialized references retain their own schema; CLI JSON uses snake_case.

const observation = useReview(review.ref); // from bijection/react
if (observation === undefined) return <Loading />;
return <ReviewPanel observation={observation} />;

review.watch() and useReview subscribe to a native query over the client’s shared Convex sync connection. Identical Review subscriptions share the same query. Assessment completion, approvals, acceptance, external execution and current access invalidate their actual database dependencies. Evidence expiry also wakes the query without a database write. There is no inspection polling.

const watch = review.watch();
const renderCurrent = () => {
  const view = watch.localQueryResult(); // throws structured query errors
  console.log(view?.decision, view?.actions);
};
const stop = watch.onUpdate(renderCurrent);
renderCurrent();
// When this observer is no longer needed:
stop();

Reconnection revalidates the server answer; it never submits or resumes work. The React hook clears its observation during reconnection, account changes and authentication refresh, and waits for confirmed sign-in. A query refusal clears the current value while retaining the subscription, so restored authority can produce a fresh answer. Unsubscribe removes this observer immediately; the shared query remains while other observers use it. Each projection keeps its own disclosure decision; the combined inspection reads one database snapshot. External systems still confirm their work independently.

Capture, submit and review

Application clients use the existing private request journal. In Node, configure requestStore: fileRequests(directory, { deployment: url, namespace: principal }) from bijection/node. The workspace uses private browser custody. Capture, submission and approval allocate request identities and retain their exact bodies before dispatch. Explicit SDK requestId / CLI --request-id remains available. After an interrupted CLI reply, use its recorded request_ref or continuation; repeating a command without its original identity starts new work.

bijection change capture what-if --through receipt.json --title "Reserve stock"
bijection change submit <revision-id>
bijection review inspect <review-reference>
bijection change status <revision-id>

# Use an independent authorized reviewer account when governance requires it.
bijection review approve <review-reference> --assessment-digest <inspected-digest>

# Apply as the author. Inspect the same revision after an interrupted reply.
bijection review apply <review-reference>
bijection change inspect <revision-id>

Capture keys belong to the authenticated caller and deployment. Two authors can use the same key independently. Reuse your key only to recover identical intent; each new capture returns an opaque revision_id for inspection, review and application. Retain that returned reference. Capture requires an explicit selection. --through receipt.json selects a complete ordered prefix ending at one qualified operation receipt. --intent intent.json selects exact qualified receipts or an application-authored typed proposal graph. Native transaction evidence preserves whole commits and refuses omitted dependencies, returning the required receipt closure for inspection. By default it refuses omitted dependencies. Explicit dependencies: "include" allows explained prerequisite expansion. Unknown evidence requires the conservative prefix. Graphs use declared output references between operations. Assessment never adds later branch operations. The review workspaces accept an explicit JSON array of qualified operation receipts. Capture stays disabled until you select receipts. The saved selection remains fixed during lost-reply recovery; revising a Change requires another explicit selection. Native admission records the exact request and revision ID before preparing the checkpoint and private source. Pending preparation has a fixed deadline of at most five minutes. A retry resumes its original source; it never selects later branch operations. Closed or applied revisions retain the same immutable capture receipt. client.changes.inspectCapture(request_id) and bijection request inspect <request-ref> read the capture as unseen, preparing, captured or refused, without submitting work. SDK and CLI recovery can use native custody after losing their local request journal. Inspect (await change.inspect()).source.explanation to see why operations were included. requested records the deliberate selection; included records its same exact admitted history. Default capture refuses omitted dependencies. Explicit dependencies: "include" adds prerequisites and records their reasons in the explanation. Dependency entries name an operation and its prerequisite indices in included, with reasons such as document_read, created_record, request_outcome or same_transaction. proven_closure uses exact native evidence. conservative_closure accounts for missing proof, assumed outcomes or relevant non-operation changes. The explanation survives the working branch and contains selection metadata, not protected record values. The capture receipt and CLI JSON include the same explanation. Authored intention graphs return empty source-history lists; their declared operation dependencies remain in the proposal content.

const change = await client.changes.capture({
  requestId: "stock_reallocation_1",
  from: branch,
  title: "Reserve stock",
  intent: { kind: "prefix", through: acceptedAllocation },
});
const review = await change.submit();
await review.wait({ until: "assessed", timeoutMs: 30_000 });
await change.share({
  requestId: "invite-stock-reviewer", // Retain with the original expected version
  expectedVersion: (await change.discussion()).version,
  principals: [reviewerTokenIdentifier],
});
// In the independently authenticated reviewer's client:
const independent = reviewerClient.reviews.open(review.ref);
const inspected = await independent.inspect();
if (
  inspected.approvals.kind === "available" &&
  inspected.approvals.value.kind === "required" &&
  inspected.actions.canApprove &&
  inspected.assessment.kind === "assessed" &&
  inspected.assessment.meaning
) {
  await independent.approve({
    requestId: "reservation_approval_1",
    expectedVersion: inspected.approvals.value.version,
    meaning: inspected.assessment.meaning,
  });
}
// Back in the author's client, once all required approvals are satisfied:
const applied = await review.apply();
if (applied.kind === "accepted") {
  const receipt = client.receipts.open(applied.receipt);
  const execution = await receipt.wait({ until: "settled", timeoutMs: 30_000 });
}

const saved = JSON.stringify(change.ref);
const reopened = client.changes.open(JSON.parse(saved));
const current = await reopened.inspect(); // reads only; never submits

The capture owns a private immutable source through the existing snapshot and fork machinery. Subsequent edits, refresh or retirement of the working branch do not change its program or operation selection. Retention is finite and uses existing branch, pin and storage limits. A new intention uses a new key. To revise a logical Change, call change.revise(...) in the SDK or bijection change revise <revision> in the CLI; both keep the change_id, bind the exact previous_revision, and close the preceding revision atomically with admission. Discover your retained revisions with client.changes.list() or bijection change list. Each page contains up to eight items and a next_cursor; pass it as { cursor } or --cursor to continue. Use { view: "shared_with_me" } or { view: "needs_my_review" } for a collaboration inbox; the CLI accepts the same values through --view. Shared inboxes contain the current revision of each Change. Pagination can return an empty filtered page with a continuation cursor; continue until that cursor is absent. Closed history remains readable after source reclamation. The workspace can open a retained revision from live, without reopening the original working branch.

Explicit business intent and bounded approvals

Use intent: { kind: "receipts", receipts: [...] } in SDK capture, or pass the same BusinessIntent to change capture --intent intent.json. A selection that omits a prerequisite returns a typed boundary with required qualified receipts and is_complete. Inspect those requirements, then capture the exact revised selection under a new request ID. For an application-authored decision, use intent: { kind: "graph", component: null, content }, where content is the existing typed proposal graph. Capture is inert; assessment prepares the graph, and native acceptance applies all its nodes in one transaction. Exploratory record IDs do not replace declared graph output references. Exact assessment approval is the default. A finite envelope can authorize one or more uses among exact assessed choices:

const approval = await client.governance.proposeBounded({
  requestId: "reservation_choices",
  spec: {
    choices: assessedChoices,
    executors: [authorTokenIdentifier],
    max_uses: 1,
    expires_at: expiryNanoseconds,
  },
});
// A separate eligible reviewer inspects and approves the returned contract.
await review.apply({ approvalContract: approval.id });

The native contract binds the exact choices, program, resource effects, allowed executors, expiry and usage budget. Consumption commits with business acceptance. Concurrent requests cannot exceed the shared budget; retrying an accepted choice returns its existing receipt. An executor cannot approve the envelope. The contract does not accept arbitrary client predicates or client-reported costs.

bijection governance propose-bounded envelope.json --format json
bijection review apply <review-reference> --approval-contract <approval-id> --format json

Collaborate without changing intent

const sharing = {
  requestId: "invite-stock-reviewer",
  expectedVersion: (await change.discussion()).version,
  principals: [reviewerTokenIdentifier],
};
// Persist sharing before dispatch; retry this same object after a lost response.
await change.share(sharing);
const discussion = await change.discussion();
await change.editDiscussion({
  requestId: "reservation_comment_1",
  expectedVersion: discussion.version,
  action: { kind: "comment", body: "Please review the reservation." },
});
// The author can clarify presentation without creating a new revision:
await change.editDiscussion({
  requestId: "reservation_title_1",
  expectedVersion: (await change.discussion()).version,
  action: { kind: "set_title", title: "Reserve stock for the priority order" },
});

The discussion has its own version. Repeating an edit with the same request ID, version and content recovers the original edit; different content under that ID is refused. A stale version requires inspection and a new request ID. SDK and CLI edits retain the exact request before sending. Opening a handle or restoring the workspace never submits it. Pending SDK commands remain available through client.requests.pending(); client.requests.open(ref) inspects or resumes one. Comments and revision metadata belong to the logical Change’s current audience. change.share() and change.unshare() require the stable request identity and original collaboration version, just like approval and discussion commands. An uncertain retry never generates a new identity or refreshes that expected version. They update only this Change, including its revision history. Other Changes on the same branch retain their own audiences. Membership survives a new revision and retirement of the original working branch. Sharing grants no business read, approval or execution permission. Withdrawing membership withdraws access to all revisions and invalidates that person’s approval at application. The author cannot be removed. Comment authors and the Change author can redact text while retaining its identity. A revision retains at most 64 comments of 4096 bytes and 128 ordinary discussion edits. Native edit receipts are stored separately, so expiry and those limits cannot block permitted redaction or withdrawal of sharing. Each edit uses the revision’s current discussion version, including sharing changes. The immutable capture still retains its original title, program, receipts and digest. Inspection, listing and discussion() return the current presentation title. Editing discussion never changes an assessment or approval binding. New executable intent uses change.revise({ requestId, from, intent: { kind: "prefix", through } }), which captures a new revision and closes its predecessor atomically. It needs a new assessment.

bijection change share <revision> '<reviewer-token-identifier>' \
  --request-id share_1 --expected-version 0
bijection change discussion <revision>
bijection change edit <revision> --request-id comment_1 --expected-version 1 \
  --comment 'Please review the reservation.'
bijection change edit <revision> --request-id title_1 --expected-version 2 \
  --title 'Reserve stock for the priority order'
bijection change edit <revision> --request-id remove_1 --expected-version 3 \
  --remove-comment <comment-id>

The workspace exposes discussion, sharing, revision creation and the exact program, source commit, selected receipts and registered reviews. It retains an uncertain edit for explicit recovery; mounting and inspecting never post it.

Reopen business evidence safely

const evidence = await reopened.inspectAssessment(assessmentRef);
if (evidence.report) {
  console.log(evidence.validity, evidence.report.operations);
  console.log(evidence.report.effects); // Exact native values, including int64 and bytes
}
const status = await reopened.status({ assessment: assessmentRef });
console.log(status.execution, status.observation_errors);
// changeFeedback(status) supplies the shared next-action presentation.

Inspection reads the original retained assessment; it never replays operations, creates another assessment, or submits a decision. A participant can read the report only when current native read/disclosure rules admit its retained proof. Proposed after-images also require current unrestricted read authority on their table: a provisional image has no committed row that could establish row-scoped permission. A reviewer with only scoped row access receives an unavailable report. Missing evidence is explicit (report: null with an unavailable reason). It never means that the proposal has no effects. The report retains its basis, captured program, ordered evaluated arguments and targets, native effect digest, exclusion counts, and limitations. Inputs use the exact assessed target identities; trial-created IDs are tentative. Internal validation seals stay private. Historical content that has changed or lost retention remains explicitly unavailable; a readable replacement row does not authorize the original values. A reclaimed assessment returns validity: "unavailable" and assessment_reclaimed; an accepted receipt remains consumed even when its report has been reclaimed. Independent approval binds the exact assessment, current policy epoch, current reviewer authentication and Change participation. Native admission checks current business disclosure for a new approval, including clients that bypass the UI. Retrying the exact saved decision recovers its receipt after expiry or subsequent state changes; it does not create a new approval. Assess the same intent again when live data, code or access invalidates its dependencies. Operational approval routing uses the assessed read/write and external-call footprint. Map policy sources with exact native keys: table:stock, component:warehouse/table:stock, or integration:payments. Domains with empty sources remain mandatory. Missing proof, file effects, or unmapped resources keep all policy domains required. Program changes retain conservative review of arbitrary code. Source mappings do not grant business access or prove downstream provider behavior. The workspace restores the selected assessment, shows its proposed business consequences, and refreshes status using read-only requests. Its URL retains the exact Change and assessment for sharing. Acceptance is a durable local transition. Status preserves the selected assessment and approval observations after acceptance, and reads execution through the existing request and external-call owners. Observation errors are separate from the acceptance receipt. Pending delivery, required attention, settled incomplete outcomes, and completed execution have distinct feedback. change.execution() and bijection change execution are also explicit read-only observations. Any current Change participant with the required operation and source-disclosure authority can observe them; sharing supplies neither permission. Uncertain captures do not block navigation. Interrupted requests opens the SDK’s private journal, independently of the currently selected Change or working branch. Inspection never resumes a request. Resumption explicitly submits its original identity and content, including when inspection says unseen after an uncertain submission. The incoming URL selects the exact revision and assessment. Discussion comments remain revision-specific. The returned discussion version fences collaboration across the whole logical Change, including revisions and membership; an edit through historical discussion cannot overwrite a newer membership decision.

Select an evaluated Plan

A Plan declares business intent, constraints and alternative captured Changes. Its draft is local. Selecting a candidate captures a new Change revision with the exact choice, rationale and retained evaluation references. Assess and review that new revision against live before applying it. Declare a typed evaluation query with definePlan from bijection/server:

import { definePlan } from "bijection/server";
import { v } from "bijection/values";

export const evaluateCandidate = definePlan({
  intent: { units: v.int64() },
  constraints: { maximum_cost: v.int64() },
  args: { cost: v.int64() },
  async evaluate(_ctx, input) {
    return {
      is_feasible: input.args.cost <= input.constraints.maximum_cost,
      metrics: { cost: input.args.cost },
    };
  },
});

Evaluate it through a scenario’s named query instruction and checkpoint afterward. Supply the candidate’s exact revision_id and intent_digest together with the same intent and constraints. The checkpoint preserves the producing code, input, query basis and any preceding computation. External compute uses the existing computation integration.

const checkpoint = await evaluationRun.checkpoint("evidence");
const selected = await client.plans
  .draft({
    intent: { units: 10n },
    constraints: { maximum_cost: 20n },
    alternatives: [
      {
        key: "bounded-cost",
        change: candidate.ref,
        evidence: [{ snapshot: checkpoint, step: "evaluation" }],
      },
    ],
  })
  .select("bounded-cost", {
    requestId: "choose-replenishment-42",
    rationale: "Meets the recorded cost constraint",
  });
const review = await selected.submit();

Selection checks the original retained query values under current access. Client JSON cannot substitute for checkpoint evidence. Selected evaluations must be feasible and match the candidate, intent and constraints. Keep the evidence unexpired and unreleased through acceptance. Each Plan allows 1–16 alternatives, 1–4 evaluations per alternative and at most 32 references in total. The candidate’s private retained source survives retirement of its working branch. Reusing the same selection key recovers the original decision. Changed actions or constraints require a new revision and fresh assessment; approvals never carry forward automatically. client.plans.inspect(selected.ref) returns decision metadata. Read protected results separately with client.runs.readEvidence(reference), which checks current disclosure. Its basis.application retains the producing state, program, input-manifest identity and assumption-set identity after the exploratory run retires. These identities do not extend retention or authorize disclosure. Native revision consistency leaves external provider snapshot consistency explicitly unproven. Intent, constraints and rationale are shared Change metadata; keep protected result values in their checkpoint. The workspace displays the decision and offers an explicit authorized evidence read. The CLI accepts the native decision JSON through bijection change capture <branch> --request-id <id> --plan plan.json.

Coordinate Changes with a live procedure

Use defineLiveProcedure from bijection/scenarios to wait for review, apply a Change and observe its external responsibilities. Register the definition in your application’s procedures map. It uses the existing durable run journal, compiler and worker.

import { defineLiveProcedure } from "bijection/scenarios";
import { v } from "bijection/values";

export const fulfillment = defineLiveProcedure({
  args: {
    revision_id: v.string(),
    review_id: v.string(),
    approvalContract: v.optional(v.string()),
  },
  capabilities: () => ({
    controls: ["wait_review", "apply_change", "wait_execution"],
  }),
  async handler(ctx, input) {
    const reviewed = await ctx.changes.waitReview(input, {
      name: "consent",
      approvalContract: input.approvalContract,
    });
    const accepted = await ctx.changes.apply(reviewed, {
      name: "accept",
      approvalContract: input.approvalContract,
    });
    await ctx.changes.waitExecution(accepted, { name: "external" });
    return accepted.revision_id;
  },
});

Start the registered procedure with the exact reviewed revision:

const run = await client.runs.start(procedures.fulfillment, {
  input: {
    revision_id: selected.ref.revision_id,
    review_id: review.ref.review_id,
  },
  retention: { outputHours: 0, evidenceHours: 24 },
});

bijection run start --procedure fulfillment --input @input.json --output run.json
bijection run inspect <run-id>
bijection run trace <run-id>
bijection run resume <run-id>

The native runtime binds exact code, input, Change and review identities. It rechecks current authority when advancing and uses the original acceptance identity after interruption. waitReview waits for current independent consent without approving on anyone’s behalf. Optional approvalContract selection is retained with each review/apply instruction and cannot change during recovery. waitExecution requires confirmed completion of every accepted request. Unknown or attention states keep waiting; partial or unsuccessful outcomes fail the step.

Submit operations as durable steps

A live procedure can submit declared operations itself. Each named step owns one stable request identity, so a restart recovers its original acceptance or refusal instead of submitting again. Declared inputs are supplied with the run’s input and read durably with ctx.input. ctx.waitFor waits until the accepted request’s external effects are confirmed complete.

export const fulfillOrder = defineLiveProcedure({
  args: { order_id: v.id("orders") },
  journaledInputs: { stock_id: v.id("stock"), quantity: v.int64() },
  capabilities: () => ({
    operations: [reserve, dispatchOperation, completeOrder],
    controls: ["wait_execution"],
  }),
  async handler(ctx, args) {
    const reservation = await ctx.step("reserve", reserve, {
      order_id: args.order_id,
      stock_id: await ctx.input("stock_id"),
      quantity: await ctx.input("quantity"),
    });
    const dispatch = await ctx.step("dispatch", dispatchOperation, {
      reservation_id: reservation.value.reservation_id,
      carrier: "rail",
    });
    await ctx.waitFor(dispatch.receipt.ref, {
      until: "external_effects_completed",
    });
    return (
      await ctx.step("complete", completeOrder, {
        order_id: args.order_id,
      })
    ).value;
  },
});

await client.runs.start(procedures.fulfillOrder, {
  input: { order_id, stock_id, quantity: 12n },
  retention: { outputHours: 0, evidenceHours: 24 },
});

When an operation’s policy requires review, approval or agreement, its step saves the exact proposal and waits (OperationReviewRequired in bijection run inspect). Approve that proposal through the ordinary proposal commands; the step then submits it. An expired or refused proposal fails the step. A refused operation throws a catchable ScenarioRefusal. Settled unsuccessful external work fails a wait; compensation is another operation. Live procedures support queries, computation, checks and operation steps. They cannot inherit a scenario snapshot, simulate writes, advance a modeled clock or retain a writable output. Each step reads its current live basis; several Change applications remain separately atomic. No database transaction stays open while waiting for a person or provider. Cancellation stops future coordination. Accepted Changes and external work keep their existing owners; compensation requires another explicitly assessed and reviewed Change. Recover or resume the original run after an uncertain reply. Recompute and resample refuse live procedures; new coordination requires an explicit new start. Evidence defaults to 24 hours and remains bounded by the original admission deadline. The workspace lists live procedures and opens their normal run inspector without submitting them.

Author a Change as a typed graph

import { defineChange } from "bijection/server";
import { v } from "bijection/values";
import { api } from "./_generated/api";

export const reserveAndShip = defineChange({
  args: { order_id: v.id("orders"), quantity: v.number() },
  build(graph, args) {
    const reservation = graph.call(api.stock.reserve, {
      args: { quantity: args.quantity },
      target: args.order_id,
    });
    graph.call(api.shipping.schedule, {
      args: { reservation_id: reservation.output.reservation_id },
      target: args.order_id,
    });
  },
});

The builder declares inert intention. It executes no business operations. The operation references supply argument, target and output types. Native graph assessment checks the declared output dependencies and atomic preparation.

const change = await client.changes.capture({
  from: trial,
  requestId: "reserve-and-ship-1",
  intent: {
    kind: "definition",
    definition: api.changes.reserveAndShip,
    args: { order_id: orderId, quantity: 3 },
  },
});

bijection change capture what-if --definition changes:reserveAndShip --args @arguments.json --request-id reserve-and-ship-1

Capture evaluates the definition as a query under the selected branch program, then freezes the resulting graph and program into native Change custody. Subsequent review and request resumption use that graph; they never rerun today’s definition. Business arguments and operation targets remain separate.

Build source or capture installed code

A Release freezes executable code. build compiles one exact Git revision on isolated native state; capture freezes a program already installed on a branch. Both return the same immutable Release and use the same installation Review. Neither command installs code on live.

bijection release build --source HEAD --profile production --request-id release-build-1 --target warehouse/prod/live --format json
bijection release capture what-if --request-id release-capture-1
bijection release submit <release-ref> --request-id release-installation-1

Source builds retain the resolved Git commit before compiling. Their build_source records the Git commit and source_digest; the program’s native source identity names that same content digest. A branch’s installed program may come from a different source checkout. Editing or switching Git cannot change an existing Release. Reusing a build or capture request ID continues its original inputs; changing those inputs requires a new ID. In a Node worker, configure the build and deployment capabilities once:

import { BijectionHttpClient } from "bijection/browser";
import { fileRequests, cliReleaseBuilder } from "bijection/node";

const requests = fileRequests(privateDirectory, {
  deployment: url,
  namespace: servicePrincipal,
});
const client = new BijectionHttpClient(url, {
  requests,
  capabilities: {
    build: cliReleaseBuilder({
      directory: sourceDirectory,
      deploymentUrl: url,
      requests,
    }),
    deployment: publishThroughReleaseOwner,
  },
});
client.setAuth(businessToken);
const built = await client.releases.build({
  source: { repository_id: repositoryId, commit: exactGitCommit },
  requestId: "release-build-1",
});
if (built.status !== "ready") {
  // Keep built.requestRef to inspect or resume this exact build.
  return;
}
const review = await built.release.submit({
  requestId: "release-installation-1",
});

cliReleaseBuilder uses the installed native CLI and its current sign-in. It retains the CLI’s opaque request handle before dispatching compilation. Its inspection path reads existing custody and never creates or starts a build. publishThroughReleaseOwner is the application’s configured deployment capability, separate from the caller’s business token. Resumption reuses that capability and rechecks current authority.

Publish application code independently

bijection release capture what-if
bijection release submit <release-ref>
bijection review inspect <review-reference>
bijection review approve <review-reference> --assessment-digest <inspected-digest>
bijection review apply <review-reference>

const release = await client.releases.capture({ from: branch });
const review = await release.submit({ requestId: "install-release-1" });
const inspected = await review.inspect();
// Independent approval uses the same Review handle and current policy.
await reviewerClient.reviews.open(review.ref).approve();
await review.apply();

Configure capabilities: { deployment: publishThroughReleaseOwner } once when constructing the client. The deployment capability supplies deployment authority and is reused during request resumption. An operational Change requires its captured program to be live already. Publish that program, then reassess the Change. Program approval never approves business adoption. After an interrupted application response, inspect the same Change or retry application with the same review ID. Its native receipt survives source reclamation. Local acceptance does not establish external delivery: the existing execution owner tracks provider work and confirmation separately.

Coordinate code and business adoption

A live Procedure coordinates independently governed transitions. This example first waits for the release’s independent approval and confirmed publication, then submits a fresh assessment of the already captured business Change. Code approval supplies no business approval.

import { defineLiveProcedure } from "bijection/scenarios";
import { v } from "bijection/values";

export const adoption = defineLiveProcedure({
  args: {
    release_revision_id: v.string(),
    release_review_id: v.string(),
    business_revision_id: v.string(),
    business_request_id: v.string(),
  },
  capabilities: () => ({
    controls: [
      "wait_review",
      "install_release",
      "submit_review",
      "apply_change",
      "wait_execution",
    ],
  }),
  async handler(ctx, input) {
    const release = {
      revision_id: input.release_revision_id,
      review_id: input.release_review_id,
    };
    await ctx.changes.waitReview(release, { name: "release-consent" });
    await ctx.changes.install(release, { name: "install-code" });
    await ctx.changes.waitExecution(release, { name: "publication" });
    const business = await ctx.changes.submit(
      { revision_id: input.business_revision_id },
      { requestId: input.business_request_id, name: "assess-business" },
    );
    await ctx.changes.waitReview(business, { name: "business-consent" });
    await ctx.changes.apply(business, { name: "accept-business" });
    await ctx.changes.waitExecution(business, {
      name: "external-confirmation",
    });
    return business;
  },
});

The native run owns the durable instruction and exact references. Its status may contain a typed required_action for Review submission or release installation. run.status(), run.wait() and bijection run inspect only observe it. Explicit run.resume() or bijection run resume drives that action through the existing Change/Review owner, then resumes the same native run. Human approval remains a separate explicit decision. A worker can resume the same run after approval; unknown acknowledgements retain the original action and request identity. Each accepted transition remains independently atomic. If business adoption is refused, the installed code remains installed. Compensation is another assessed Change. Cancellation stops future coordination, and cannot undo accepted work.

Inspect and resume an original request

Inspection never submits or advances work. Resumption uses only the retained body, caller and native destination; selecting another context does not change it. The same interface covers operations, branch lifecycle, Change capture, submission, approvals, source builds, scenario execution and release installation. CLI req_... locators resolve existing private custody in the current user profile. They carry no credentials and do not replace native ownership checks. Moving custody between machines is an explicit diagnostic import, not ordinary navigation.

bijection request inspect <request-ref> --format json
bijection request resume <request-ref> --format json

Mutating CLI outcomes retain request_ref before dispatch. Recovery continuations identify read, exact resumption and new-work effects. request pending discovers existing custody without dispatching it. A lost reply from a retained SDK mutation throws RequestUnconfirmed. Its request_ref opens the exact retained request; a fresh call would be a new intention:

import { RequestUnconfirmed } from "bijection/browser";

try {
  await review.apply();
} catch (error) {
  if (!(error instanceof RequestUnconfirmed)) throw error;
  const request = client.requests.open(error.requestRef);
  const observation = await request.inspect();
  await request.resume();
}

review.apply() resolves to the acceptance receipt, or reports a refused or pending application as data. Typed operation references preserve their original generated result through client.requests.open(request.request_ref). Generic inspection results identify their family with kind, so an agent can narrow the observation before reading its domain fields. Import references from JSON through the shared validator:

import { decodeRequestReference } from "bijection/browser";

const ref = decodeRequestReference(JSON.parse(saved_request));
const inspected = await client.requests.open(ref).inspect();
if (inspected.kind === "release_build") {
  console.log(inspected.observation.state);
}

Validation checks bounded, credential-free structure, generated command contracts and the original caller and destination bindings before any network request. It grants no authority. Inspection and resumption still enforce current access. Build inspection checks the same source, artifact and native owner as completion. The client’s configured deployment capability is needed when resuming release installation. Business operations need no deployment authority. A branch operation reference retains its logical branch and original generation without a personal access URL. If that generation is no longer available, recovery refuses instead of executing against its replacement. Local release acceptance and publication completion remain separate receipt observations.

What operation acceptance carries

Acceptance reruns the selected business operations against live under the caller’s current permissions. It does not copy branch documents. The reviewed ordered batch commits together or none does, and its results and effects must match the review after typed document identity remapping. Only the caller’s directly invoked eligible operations can be selected. Ordinary mutations, console edits, imports, another user’s work and scheduled work remain private. The report identifies excluded work. Administrator impersonation cannot authorize operation replay. Documents created on the branch receive different live IDs. Native replay rewrites their declared v.id(...) arguments, results and record keys through the verified correspondence. It refuses undeclared or ambiguous references, opaque values hiding created IDs, and incompatible creation counts. Ordinary strings keep their declared meaning. A report distinguishes Branch result, Proposed live result and Accepted live result. Refused or diverged operations stop the reviewed batch. Skipped operations remain unaccepted. --format json preserves exact integers, bytes, revisions and evidence when the bounded human display omits detail. Each accepted request applies at most once. Retrying a completed review recovers its receipt even after later batches have applied. Current branch access is still required. Receipt recovery does not require retained business values or claim that today’s live installation matches the historical review.

Program publication

A release captures the installed branch program and its source provenance. Local files are not evidence of the running program. Commit and push intended source and let bijection dev install it before capturing publication intent. Publication installs only the reviewed program through the release owner, including its application publication lifecycle. An operational Change cannot publish missing code. Publish a release first, then assess the original Change against the resulting live installation. Published code remains live if later operation acceptance fails.

External calls

A branch holds external calls. Simulations may assume outcomes without producing real delivery receipts. Accepting eligible operations asks live to deliver their calls through its ordinary external-effect owner. Local acceptance and external completion remain separate facts. A Change must fit one bounded local acceptance transaction. Assessment refuses a selected batch that needs an external result between its operations; it does not accept an initial part of that batch. Capture the complete prefix through the earlier operation’s receipt as a separate Change, assess and apply it, then wait for its live result before proposing the dependent work. Unknown, refused or superseded outcomes cannot become proof that a real effect completed.

Refresh from live

Refresh preserves this branch’s name while bringing in current live data. Use it to repeat the experiment on a newer starting state. Review already evaluates against current live data, so refresh is not a prerequisite for publication. An expired or invalidated review needs another review, not a refresh:

bijection branch refresh what-if

The command prepares a replacement privately, preserves the selected program, and re-evaluates your unapplied operations against the new basis. If both code histories changed, it reconciles the committed source through Git before building. Conflicting files are reported for resolution. The current branch stays active until preparation completes. Changed results describe a new experiment; they do not authorize live changes.

At most 128 remaining operations are replayed together.
Direct edits, imports and another person’s unapplied work are refused rather than silently dropped. Changed files and environment variables also require their own preservation path and currently refuse refresh.
A code-only branch with no operations can refresh.
When an operation cannot be carried, refresh names it with its own code: the operation’s refusal (such as INSUFFICIENT_STOCK), ObjectMissing, OperationContractChanged, OperationCodeChanged or EvidenceUnavailable. The SDK throws BranchRefreshConflicts with one entry per operation in conflicts; the CLI lists them under the refusal and the workspace shows the code beside each step.
Retry the same command after interruption to recover its attempt.
Use bijection branch refresh what-if --cancel to cancel preparation and keep the current generation.

Reopen the branch after refresh. Old connections close explicitly; they do not silently switch to another data basis. The prior generation is reclaimed through the normal restore window.

Observe a Change after acceptance

const execution = await change.execution();
for (const request of execution.requests) {
  if (request.status === "observed") {
    console.log(request.phase, request.calls, request.refreshes);
  }
}

bijection change execution <revision> exposes the same read. The workspace’s Observe execution button refreshes it without applying again. Acceptance and external completion are separate: unconfirmed delivery, blocked publication and source refreshes retain their native states. is_complete: false means current access or retained evidence cannot reveal every request; it does not establish completion. Observation remains available after the retained Change source ends, subject to current read and disclosure permissions. Submission allocates a durable review before assessment. Its reference remains inspectable when preparing or blocked. review.wait({ until: "assessed", timeoutMs: 30_000 }) waits for that original assessment; it starts no work. After confirmed acceptance, the accepted result contains a serializable receipt reference. Open it with client.receipts.open(applied.receipt) and use wait({ until: "settled" }) to observe execution separately. Settlement includes incomplete outcomes; needsAttention is a separate goal and does not end a settlement wait. A blocked assessment retains operation positions and statuses. When evaluation establishes native disclosure evidence, inspection.assessment.evidence also retains the failing operation’s captured receipt or authored graph key, business refusal code, message, installed program and assessment basis. The native finalizer saves this before ending the private trial, independently of response delivery. Each read rechecks current operation-read and input-data access. Participation alone grants no business disclosure. Missing, expired, oversized or inaccessible evidence is explicitly unavailable; it never turns a blocked assessment into an applicable transition. All provisional business writes remain uncommitted. CLI review wait --until assessed and receipt wait --until settled apply --timeout to sign-in, native target identity checks and the native query subscription together. A deadline or cancellation before the first answer still returns the exact review or receipt identity and its inspection continuation. It establishes no new assessment or execution fact.

Route React queries and operations together

const trial = await client.branches.resolve("what-if");

<BijectionProvider client={client} target={trial}>
  <OrderEditor />
</BijectionProvider>;

The provider opens an independent reactive client and query cache for the pinned branch generation. useQuery, operation hooks, forms and uploads use that same opening. While another target is opening, the previous target’s children are unmounted; its socket and observers close. Authentication follows the owning client. Requests already captured retain their original logical branch, generation, caller and inputs, even after the provider changes target. A refreshed generation requires explicitly reopening the branch. Without target, the provider keeps the ordinary live client behavior. Receipt observation separates is_observation_complete (coverage of the observed responsibility) from each operation’s phase and release.is_publication_complete. Complete coverage alone does not establish successful execution or confirmed deployment publication.

Get Started

Use-case atlas

Platform

Data and Operations

Guides

Client Libraries

Tools

API Reference

Refresh, review and accept

One SDK contract across execution contexts

Capture, submit and review

Explicit business intent and bounded approvals

Collaborate without changing intent

Reopen business evidence safely

Select an evaluated Plan

Coordinate Changes with a live procedure

Submit operations as durable steps

Author a Change as a typed graph

Build source or capture installed code

Publish application code independently

Coordinate code and business adoption

Inspect and resume an original request

What operation acceptance carries

Program publication

External calls

Refresh from live

Observe a Change after acceptance

Route React queries and operations together

​One SDK contract across execution contexts

​Capture, submit and review

​Explicit business intent and bounded approvals

​Collaborate without changing intent

​Reopen business evidence safely

​Select an evaluated Plan

​Coordinate Changes with a live procedure

​Submit operations as durable steps

​Author a Change as a typed graph

​Build source or capture installed code

​Publish application code independently

​Coordinate code and business adoption

​Inspect and resume an original request

​What operation acceptance carries

​Program publication

​External calls

​Refresh from live

​Observe a Change after acceptance

​Route React queries and operations together

One SDK contract across execution contexts

Capture, submit and review

Explicit business intent and bounded approvals

Collaborate without changing intent

Reopen business evidence safely

Select an evaluated Plan

Coordinate Changes with a live procedure

Submit operations as durable steps

Author a Change as a typed graph

Build source or capture installed code

Publish application code independently

Coordinate code and business adoption

Inspect and resume an original request

What operation acceptance carries

Program publication

External calls

Refresh from live

Observe a Change after acceptance

Route React queries and operations together