Adapter
An interface through which a FoldEngine product communicates — for example an HTTP API, MCP, or JSON/JSONL. Adapters serve products; they are not products by themselves.
FoldEngine
Glossary
A plain-language guide to the terms FoldEngine uses for bounded probes, evidence-backed claims, and stabilization loops.
The public Trial runner uses named public examples. Free First Probe intake can also receive safe high-level private or sensitive project context, but those requests require manual scoping and do not authorize automatic execution.
Agent Governance Gateway
An in-build FoldEngine product that sits between agents and their tools and returns an evidence-backed decision without executing the action. A local HTTP API, local Docker profile, MCP server skeleton, MCP Docker profile, evaluation package, operator visibility contract, and local continuity record primitive exist. It remains non-production: no hosted service, auth/TLS, production MCP service, action execution, or Stability Ledger bridge.
AI Code Stability Probe
A reviewed false-closure check for AI-generated code. It looks for shallow tests, unwired paths, hallucinated assumptions, invalid config, unsupported dependencies, deployment gaps, and whether the code should be promoted, held, sandboxed, repaired, or quoted.
AI Stack Audit
A broader review of an AI-generated prototype or small repo. It expands AI Code Stability across dependencies, architecture, test depth, config, deploy path, top false-closure risks, and a stabilization backlog.
Anti-overclaim
The discipline of not promoting a claim beyond its evidence. If something is only partially supported, uncertain, or out of scope, the report should say so.
Bounded
A review with a clear scope. A bounded probe may look at public files, documentation, visible repo structure, a provided artifact, safe high-level context, or separately approved evidence. It does not assume access to private context, hidden intent, or unstated architecture.
Bounded Snapshot
A result tied to a specific question, evidence set, and moment in time. It can be useful for a decision, but it is not permanent proof that the system will remain stable as it changes.
Claim
Anything a project appears to be saying about itself. Examples include “this is tested,” “this is production-ready,” “this validates X,” “this is deterministic,” or “this feature exists.” A probe checks whether the claim is visible, supported, partially supported, or unsupported within the review boundary.
Containerized Product
A finished, runnable FoldEngine product with a clear user, job, interface, output, and boundary, assembled from shared internals. Distinct from an evaluator pack, which is a proof aid rather than the main product.
Continuity Node
The Evidence / Continuity Node product: a local service that ingests continuity records, indexes governed runs, persists locally, restores bundles, and applies a retention policy. It is not a Stability Ledger bridge.
Decision receipt
A proceed, hold, or block decision tied to reasons, evidence, expiry, and hold or rollback conditions. It reflects evaluated invariants and evidence gaps, then records what the reviewed probe authorizes next — not just what was found.
Dependency Watch
A quarterly scoped review of an agreed watch list. It is not continuous monitoring, incident response, a security audit, or unlimited advisory support.
Deployment Profile
A supported way to run a FoldEngine product — for example Mac or Linux workstation, Linux server / mini-PC, Raspberry Pi / edge, or Docker. A profile is claimed for a product only once validated; Raspberry Pi / edge is a deployment target, not a product.
Evaluator Pack
A proof and demonstration aid used for evaluation and sales. Useful for showing the governance loop, but secondary to the finished product line.
Evidence Boundary
The line around the evidence used for a result. A probe should not claim more than the files, artifacts, context, or approved access actually support.
Evidence gap
An invariant that could not be evaluated because the required evidence was missing, private, unavailable, or outside scope.
Evidence Packet
The visible support behind a conclusion. An evidence packet points to the files, patterns, documents, tests, or missing pieces that shaped the readout, so the reasoning can be inspected.
False Closure
A state where something appears finished because it compiles, renders, or looks plausible, while important support paths remain missing or untested.
Frame
The explicit setup for a probe: what question is being checked, what evidence counts, what is out of scope, and what would count as a useful next move.
Governed queue
The ordered set of seed candidates with unlock conditions, hold conditions, and exit criteria. It shows what should happen next in a safe order, not everything at once.
Invariant
A condition FoldEngine expects to hold, fail, or remain unevaluated based on the evidence available for a probe.
Layered invariant library
A shared set of core invariants plus probe-specific extensions. The core covers evidence availability, reproducibility signals, dependency declarations, runtime/test proof, documentation sufficiency, scope boundaries, and claim-to-artifact traceability. Probe types add their own checks.
Ledger entry
A delivered report recorded at a point in time. Each entry records what was checked, what was found, what remains open, and what next move was recommended. A delivered report becomes a ledger entry after delivery approval; later probes on the same project surface append new entries. (Internally these are also called timeline events.)
Local Reference Stack
The assembled local product stack — Agent Governance Gateway, Local Research Runtime, and Evidence / Continuity Node running together as a reference / pilot package.
Pi / Edge Profile
A Raspberry Pi or edge deployment target for a FoldEngine product. It is a deployment target, not a product, and is claimed only where validated for that product.
Probe capsule
The replayable envelope for a reviewed probe: the question, artifacts, constraints, output contract, and consent posture. On the public site this is also called the reviewed probe envelope.
Probe Matrix
The public comparison page at /probes/. It helps a buyer choose between fit checks, popularity-signal reports, stability-signal diagnostics, AI-generated code reviews, quarterly dependency watch, and custom scoping.
Product Container Shell
The standard a finished FoldEngine product declares: input contract, runtime interface, health / readiness, sample scenario, smoke / acceptance test, local state, evidence / continuity output, export bundle, operator-readable summary, deployment profiles, and boundary manifest.
Product runtime
The running surface of a finished FoldEngine product — its local interface, governed run loop, and outputs — as opposed to a loose component or SDK part.
Product / Surface Anchor
The part of a repo/project the probe is actually about: a website, API, SDK, mobile app, AI-generated prototype, internal tool, dependency choice, workflow, or legacy module. A repo may contain several surfaces, so FoldEngine asks what to focus on before reviewing.
Product vs internal component
Internals such as governance, evidence, memory, exports, and continuity are reused across products. Buyers consume finished products, not the internals directly.
Promotion
Moving something from a weaker status to a stronger status, such as idea to documented concept, prototype to test-backed feature, or test-backed feature to reusable capability. In FoldEngine, promotion should be earned through evidence.
Public Runner
The live Trial page that runs only named, allowlisted public examples. It does not process arbitrary repos, private repos, secrets, or user-provided GitHub tokens.
Receipt
A record of what was checked, what was found, and what was not checked. For paid deliverables, the primary receipt is the proceed/hold/block decision receipt above; boundary receipts still help prevent overclaiming by preserving the review scope and evidence used.
Report
The delivered product of a paid probe: a bounded decision report covering findings, evidence gaps, seed candidates, a proceed/hold/block decision receipt, and the next recommended move. The report is delivered through the approved delivery process; after delivery approval it becomes a ledger entry in the project's Stability Ledger.
Reviewed Intake
The reviewed request path for Free First Probe, Star Support Probe, Stability-Signal Probe, AI Code Stability Probe, Paid Trial Diagnostic, AI Stack Audit, Dependency Watch, and Custom / Quote. FoldEngine reviews each submission before deciding whether to run a bounded probe, ask for clarification, send a payment link, quote custom work, or decline.
Safe High-Level Context
A non-secret summary of a private or sensitive project. It can describe the decision, domain, or shape of the problem without sharing credentials, tokens, private source code, regulated personal data, or confidential client data.
Seam
A place where two parts of a system meet and where confusion, risk, or hidden assumptions often appear. Examples include a mismatch between documentation and code, a claim without enough support, or terminology used before it is clearly defined.
Seed candidate
A bounded change candidate extracted from evidence. It includes a hypothesis, value and risk, required evidence, and verification steps — not an open-ended todo list.
Stability Gate
An operational checkpoint that decides whether a claim, artifact, or next move has enough evidence to proceed. A Stability Gate should block promotion when the boundary or evidence is not strong enough.
Stability Ledger
A project's running continuity history across delivered reports. It is project/surface-scoped, not client-scoped: a client can hold several ledgers, one per product or project surface. A Stability Ledger is created or updated after delivery approval — not on intake, payment, or form submission. Each delivered report becomes a ledger entry; the ledger records governed progression across entries: what was checked, what seeds emerged, what decision receipt applied, what is queued or held, and what evidence moved the state forward. The client portal shows summary-only status in v1; the full report is delivered through the approved delivery process.
Stability-Signal Probe
A reviewed diagnostic for stale trust, maintenance seams, documentation drift, support risk, migration pressure, and the next smallest stabilizing move. It separates visible confidence from current support reality.
Stabilization Loop
A repeated check-and-improve cycle that makes a system clearer, safer, or more reliable. Instead of treating one readout as permanent, a loop compares receipts, checks drift, and asks whether the next step still holds.
Structured Diagnostic Readout
A lightweight review output that helps someone understand what is visible, what is supported, what remains uncertain, and what to inspect next. It is not a full audit, certification, or black-box score.
Technical note: QSG
Internal shorthand for a framing pattern used in technical/advisor work. Customers do not need it to use FoldEngine, and it is not presented here as a new public mathematical product.
Trial Probe
A bounded first-pass review of a project, repository, or technical claim. A Trial Probe looks at a defined surface and asks what is visible, what is claimed, what evidence supports the claim, where the gaps are, and what the next smallest useful move would be.
What a Trial Probe is not
A Trial Probe is not a full code audit, legal certification, security review, replacement for expert judgment, or a claim that the system understands everything. It is closer to a structured diagnostic readout with clear limits.