Resource inspection and health

The generated workspace client exposes inspect, lineage, health and explain. All four use your verified business session and the application’s current authorization. The Resources page and customer CLI use the same queries.

import { createWorkspace } from "./bijection/_generated/client";

const workspace = createWorkspace({
  url: deploymentUrl,
  token: async () => businessSessionToken,
});
const orders = workspace.collections.orders;
const inspection = await workspace.inspect(orders.ref);
const lineage = await workspace.lineage(orders.field("total"), {
  direction: "upstream",
  limit: 50,
  context: inspection.context,
});
const explanation = await workspace.explain(orders.field("total"));
const health = await workspace.health(orders.ref);

A resource reference is an address such as collection:orders, operation:orders/approve:run, function:reports:summary, producer:daily_orders or capability:automations. A reference grants no permission. A field reference pairs it with a typed field path. An inspection context contains a digest of the currently authorized definitions. Pass it to a later inspection or lineage call to detect changes. It does not pin data or establish an external snapshot. A lineage cursor also binds its resource, direction and selected field; if definitions or access change, start a new traversal.

Lineage and field explanations

Resource lineage identifies dependencies, publication, operation inputs and explicitly declared consumers. Every edge says what evidence supports it. Declared usage describes what a consumer depends on; it does not prove a runtime read. Hidden resource names and counts are omitted. Field explanations separate value dependencies from row-membership dependencies such as filters and join keys. They follow exposed views and report where the trace stops. They do not identify which input rows contributed to an output row. Native producer mappings are currently a boundary. Pages contain at most 100 resources. A field trace visits at most 100 fields and 800 edges. Always check is_complete, the trace stops and next_cursor.

Health and exact evidence

Health assessments have a dimension, outcome, coverage and original evidence time. Missing objectives are unmonitored; missing or incomplete evidence is unknown. A successful connection check does not prove freshness or quality. Reading health performs no repair and never resolves an alert. The source owner retains at most 64 observations per source. The ordinary health query returns a bounded window shared across its source page. Exact int64 sequence and generation values are JavaScript bigint; preserve them as such.

const source = health.sources?.items[0];
const observation = source?.health?.observations.at(-1);
if (source && observation) {
  const evidence = await workspace.explain(orders.ref, {
    kind: "health_observation",
    source: source.source,
    sequence: observation.sequence,
    generation: observation.generation,
    contract_revision: observation.contract_revision,
  });
}

An expired observation, changed source identity or withdrawn access produces an unavailable error. It never falls back to the newest observation. In Resources, observation links keep selected evidence separate from current health.

CLI

bijection inspect collection:orders
bijection lineage collection:orders --field total --direction upstream
bijection explain collection:orders --field total
bijection health collection:orders --watch

Use --format json for structured results and --context <digest> to require the same authorized definitions. Exact observation selection is available through bijection explain. Watching health submits no work.

Get Started

Use-case atlas

Platform

Data and Operations

Guides

Client Libraries

Tools

API Reference

Resource inspection and health

Lineage and field explanations

Health and exact evidence

CLI

​Lineage and field explanations

​Health and exact evidence

​CLI

Lineage and field explanations

Health and exact evidence

CLI