Glossary

May 9, 2026 · View on GitHub

Standalone glossary of Foundry terminology, mirrored from spec.md §2. For readers who want only the vocabulary.

If this glossary disagrees with spec.md, the spec wins; this file is updated.

A condensed quick-card version (one row per term, fewer terms) is at docs/reference/terminology-quick-card.md.

TermDefinition
TargetThe software under evaluation: its source code, and optionally a running deployment of it (the testbed).
TestbedA running instance of the target that agents may probe and exploit. May be absent.
OperatorThe human who configures, starts, steers, and stops an evaluation.
Evaluation goalsThe operator's written statement of what outcomes matter (e.g. "authentication bypass", "RCE on the control plane") and what is in scope to test.
AgentAn LLM-backed worker with a defined role, running in a loop, coordinating with peers via the shared substrate.
RoleA named agent specialization (Detector, Triager, etc.). One role may have many concurrent instances.
FleetAll agent instances currently running for one evaluation.
FindingA claimed vulnerability at any lifecycle stage, from "candidate" through "confirmed and reported".
CandidateA finding that has been detected but not yet investigated.
VerdictThe Triager's classification of a candidate: true-positive, false-positive, needs-review, not-applicable, or code-quality.
Evidence gateThe structural requirement a finding must satisfy before it may be classified true-positive. See spec.md §7.3.
ExploitedA true-positive finding whose headline impact has been independently reproduced against the testbed by a clean-room check. See spec.md §7.4.
FingerprintA stable identifier for a finding, used for deduplication across runs. See spec.md §7.5.
Finding reportThe human-readable writeup of a confirmed finding: description, impact, reproduction, severity, classification.
Security mapThe Cartographer's output: architecture overview, attack-surface enumeration, trust-boundary map, data-flow description, threat model.
Detection ruleA reusable, versioned check for one vulnerability class, applied by the Detector to each function in scope. The rule corpus is an artifact independent of the agent code.
Rule-gapA record that an exploratory finding was confirmed true-positive and no detection rule would have produced it; the input to growing the rule corpus. See FR-042.
CoverageThe degree to which the evaluation goals have been credibly attempted.
YieldSeverity-weighted confirmed findings per unit of spend, measured over a trailing window.
Work queueThe shared, ordered list of tasks agents claim from. See spec.md §8.
Finding storeThe durable, fingerprint-indexed record of every finding at every lifecycle stage; internal, queryable by every role. Distinct from the issue tracker.
Coverage logThe append-only record of which (area × technique) pairs the fleet has attempted; an audit trail, not a stop-list. See FR-046.
Budget governorThe substrate component that tracks spend, runtime, and trailing yield against operator caps and signals the Orchestrator to halt. See spec.md §9.3–§9.4.
Help requestAn operator-filed issue asking the fleet to perform a specific action; resolved by the Orchestrator's conversational facet. See FR-015.
Operator messageAn agent-authored, asynchronous, one-way note to the operator (blocker, request, feedback, or informational), deduplicated across the fleet. The agent→operator counterpart of a help request. See FR-102a.
Proof-of-concept (PoC)A self-contained, runnable artifact that demonstrates a finding's headline impact against the testbed. See FR-063.
ClaimAn agent's exclusive, crash-safe hold on a unit of work (a task, a finding, a target file).
SubstrateThe non-agent machinery every role depends on: work queue, finding store, sandbox, budget tracker, dashboard.
IndexThe structured representation of the target's source: symbols, call graph, cross-references, embeddings.
SandboxThe isolation boundary around the agent fleet that constrains what it can reach and modify.

See also