Trace relationships

Axiom Inspector models your application as facts connected by typed relationships. Start from one fact, pick the question you want answered, and read the result together with its evidence and completeness.

Truth layers

Every fact and relationship belongs to one truth layer. The layers answer different questions and are not interchangeable.

An allowed limit is not observed usage. An operation reachable from a button is not proof that anyone pressed it. A package's maximum permission request is not an application grant.

Facts and semantic IDs

A fact is one normalized semantic node: a page such as Home, a state value such as Home.apiKey, an operation, a backend endpoint, an extension, one requested or effective permission, a style rule, or one runtime invocation. Each fact carries:

• a stable semantic ID, such as state:beb6895899277ccd1fbb36b3;
• a display label, kind and target list;
• a truth layer and a verification state (verified, declared, unverified or unavailable);
• attributes and evidence references, where available.

Commands accept a label when it resolves to exactly one fact. Semantic IDs are the durable choice for automation.

axiom inspect node Home.apiKey .
axiom inspect node state:beb6895899277ccd1fbb36b3 .

If a label is ambiguous, the command fails with selector ... is ambiguous; use a semantic ID. Copy the ID from inspect node, inspect graph or the dashboard drawer.

Relationships

A relationship is a directed, typed edge between two facts, produced by the compiler, resolver, verifier or runtime. JSON output uses these kebab-case names; human output capitalizes them.

The dashboard graph lays out these edges; it is not an inferred architecture diagram.

Evidence references

An evidence reference explains why a fact or relationship exists. Depending on the producer it points to an Acore source span, a verified .axiom artifact and digest, a lock entry, an extension module, interface, request, grant or policy digest, a compiler source map, or a normalized runtime session and trace.

axiom inspect evidence Home.apiKey .

The dashboard renders a source snippet only after it validates the referenced path and digest. Binary or out-of-workspace paths fail closed.

Choose a command

All commands take [PATH] (default .) and --format human|json|jsonl.

Trace upstream or downstream

axiom inspect trace Home.apiKey . --direction upstream
axiom inspect trace action:bc32bddfdfcab1ed7da14f57 . --direction both --max-depth 6

The examples use the task app from Inspect an application; action:bc32bddfdfcab1ed7da14f57 is its Home.connect action. Upstream asks what establishes, calls, writes or authorizes a fact. Downstream asks what it can call, render, mutate, return or affect. In the task app, the upstream trace of Home.apiKey reaches a button that triggers the Home.connect action, which contains the step that writes the state.

Apply member price button
        -> action
        -> pricing extension export
        -> effective write authority
        -> Home.total_label

Every arrow is a typed relationship, never label similarity. Direction follows the edge, not time, unless the evidence is an observed runtime trace. Traversals are bounded: increase --max-depth and --max-results deliberately and check Truncated in the result. If the selector is not a fact but matches a recorded runtime trace ID, trace prints the observed events for that trace instead.

Cache declarations and invalidation references describe dependencies. Static inspection never reads a live cache; use runtime evidence for cache hits and fills.

Ask why and inspect access

axiom inspect why Home.apiKey .
axiom inspect access Home.apiKey .

why returns the authoritative adjacent facts that establish the selected fact. For a permission this can include its request, application grant, target policy, effective authorization and declaration evidence. access separates who requests authority, what the application grants, what a target policy enables, which exact state, store, service or resource is authorized, and whether matching observed evidence exists.

Prove reachability and follow lineage

axiom inspect reachability action:bc32bddfdfcab1ed7da14f57 Home.apiKey .
axiom inspect lineage Task.title .

reachability returns a deterministic shortest downstream path within the depth. No path means none was found in the available bounded graph; it does not prove that unavailable external code has no path. lineage answers data questions: where a rendered value originates, which projection exposes a field, which operation returns it, which UI consumes it and what a change could affect.

Query a neighborhood

axiom inspect graph . --root Home.apiKey --direction both --max-depth 4 --max-results 200
axiom inspect query question.json . --format json

Use graph for a broad neighborhood rather than complete paths. For repeatable agent queries, write an axiom-query/v1 document:

{
  "format": "axiom-query/v1",
  "operation": { "kind": "trace", "root": "state:beb6895899277ccd1fbb36b3", "direction": "upstream" },
  "maxDepth": 4,
  "maxResults": 100
}

Operation kinds are overview, node, search, graph, trace, why, access and reachability. maxDepth defaults to 8 (maximum 64) and maxResults to 500 (1 to 10,000). Malformed, unknown or over-budget documents fail validation.

Compare targets

axiom inspect target-compare Home.apiKey . --targets web,ios,android

The result keeps facts that apply to the listed targets, and its JSON summary adds comparedTargets, factsByTarget and divergentFactCount. Use it for target availability, lowering differences and target-effective authority. It does not compare screenshots or claim pixel-identical rendering. target-diff is an alias.

Review contracts and dependencies

An imported contract can bring packages and executable extensions whose authority depends on the consuming application. These examples use a shopping application with a shop contract alias and a pricing extension.

axiom inspect dependencies .
axiom inspect contract shop . --closure
axiom inspect executable-closure shop . --target web
axiom inspect provenance pricing .

• dependencies lists direct and transitive contracts, packages and executable extensions found in the workspace and its verified locks. It does not scan other package managers.
• contract ALIAS shows one imported contract by its manifest alias. --closure adds reachable dependency facts: artifact and lock identity, audiences, operations, inputs, outputs, errors, projections, policies, cache and streaming declarations, and verification state.
• executable-closure ALIAS shows sandboxed code reachable from a dependency and its authority, optionally for one --target.
• provenance SELECTOR connects source and digest, package and module identity, interface and SDK, signature or unsigned state, lock origin, authority documents and the including release.

Inspector keeps each authority stage separate:

package maximum request
        ∩ application grant
        ∩ target policy
        ∩ runtime limits
        = target-effective authority

A valid digest or signature proves integrity, not correctness, and not that every requested permission should be granted. If extension source is unavailable, Inspector says so; it never reconstructs it or calls it audited.

Before you accept a third-party contract:

1. Run inspect contract ALIAS --closure.
2. Run inspect executable-closure ALIAS for each target you ship.
3. Review inspect provenance for reachable packages and extensions.
4. Review requested, granted and effective permissions with inspect access and inspect authority.
5. Trace important operations into your application.
6. Save a snapshot for review, and compare it whenever the lock changes.

Where verified identities match, a trace can connect a UI query to an imported contract operation, a backend endpoint, a response projection and domain fields. That is static reachability; use runtime evidence to show a call happened.

Graph revision and completeness

A graph revision identifies one complete evidence snapshot. Queries, live targets, runtime sessions and diffs carry it so facts from different builds are never mixed. A live target on an older revision stays visible as partial evidence, but Inspector will not correlate it as current until you reload it.

Treat completeness as part of the answer:

• a complete static trace does not prove execution;
• an empty runtime session does not prove an operation is unreachable;
• an unavailable source body stays opaque;
• a truncated graph cannot prove that no other path exists.

Use the dashboard

In the local dashboard, select any fact and choose Trace upstream, Trace downstream, Trace both or Why?. The Graph view uses the same semantic IDs, relationships, bounds and graph revision as the CLI.

The Graph view for the documentation task app, tracing contains edges from the application fact.

Next steps

• Changes and impact
• Runtime evidence, security and audits
• Ask questions