Glossary

Workspace Intelligence

The shared, evidence-backed understanding layer for software systems. See What Is Workspace Intelligence?.

Software System Understanding

The broader goal of representing structure, semantics, relationships, intent, evolution, trust, and reasoning for a software system.

Workspace Model

The structured representation of projects, runtimes, frameworks, commands, policies, contracts, reports, and evidence.

Workspace Graph

A graph of the software system: projects, services, modules, APIs, runtime, ownership, changes, evidence, and agent surfaces.

Evidence

Machine-readable reports, contracts, test results, doctor output, release gates, and generated artifacts that support or weaken a claim.

Freshness

The status that tells whether a fact is current enough to use. Facts may be fresh, stale, inferred, observed, verified, or unknown depending on the source.

Live-input fingerprint

A deterministic signature binding a persisted graph to current project inputs. Workspai uses Git-aware, content-Merkle, or hybrid strategies depending on the registered project scopes.

Portable proof path

A workspace-relative evidence location that does not expose the user's absolute machine path. Linked projects use the external/<project>/... namespace.

Omission budget

The limits and explicit counts attached to a bounded agent graph projection. It records what was left out so truncation cannot be mistaken for absence.

Agent Grounding

The process of giving AI tools scoped, current, evidence-backed context before they act.

Agent Customization Pack

A versioned inventory of generated agent-facing artifacts such as context, AGENTS.md, IDE files, skills, indexes, and MCP design.

Native Create

A project creation path where Workspai owns the scaffold contract, marker, registry, doctor, bootstrap, and workspace model path.

Official Create

A project creation path where Workspai uses an ecosystem generator, then registers the result in Workspace Intelligence. Some official paths are available today; others are planned handoffs.

Adopt

The path for bringing an existing project into a workspace without changing its source layout.

Existing Runtime Signals

Examples used by the create planner to recognize likely existing-project requests. They are not an allowlist; adopt/import remains open-ended for readable projects that can be registered and modeled.

Verify

The Workspace Intelligence gate that evaluates graph integrity, policies, freshness, affected projects, and evidence readiness.

Explain / Trace

Human-readable reasoning over blockers, projects, or diff-to-impact-to-gate flows.

Doctor Diagnosis

The versioned, runtime-neutral diagnosis containing stable findings, causal groups, confidence, proofs, unknowns, contradictions, and repair disposition.

Causal Group

A set of related findings with a shared likely cause. Consumers use the group to avoid proposing several disconnected fixes for one underlying problem.

Runtime Unit

A bounded lifecycle surface inside a project, such as an npm package, Cargo crate, Go module, or CMake/Meson build root, with its own manifest and commands.

Repair Transaction

A CLI-owned, durable sequence binding plan, approval, checkpoint, mutation, reconciliation, validation, verification, rollback, and terminal status.

Decision-required

A non-success repair state used when human intent, missing capability, policy, unsupported tooling, or an unsafe ambiguity prevents deterministic closure.

Exact evidence producer

The sourceCommand that refreshes a required sourceArtifact. Verify exposes this binding so IDEs and agents do not guess which command closes a blocker.