What you get
Guided local deployment, operator surfaces, evidence and receipts, and a clear commercial qualification path.
FoldEngine Offline Runtime
A governed offline engineering runtime.
FoldEngine Offline Runtime governs how AI-assisted engineering moves from research and planning through execution, review, authorized change, and accepted project state.
It is a governed engineering runtime, not a code chatbot. Every major activity produces governed evidence while preserving human authority and local-first control. It is the offline operating environment where teams shape work, trial bounded changes, and preserve evidence. Runtime keeps the final decision with the operator.
It is independent from Hosted Probes and Client Portal. Use it when a team needs Objective Discovery, Workcells, Nebula programs, review, Governed Apply, Project Checkpoints, and continuity inside its own boundary.
Local / offline
Controlled delivery
Evidence at every step
Operator authority
Not GA / not self-service SaaS
FoldEngine does not mutate source autonomously. Source changes occur only through explicit admission, authorization, bounded application, validation, and a source-state receipt. Commit, push, merge, deploy, and release remain outside autonomous authority. It does not autonomously apply source changes, commit, push, merge, deploy, release, accept organizational delivery, or promote project-local knowledge globally. It does not commit, push, merge, or release on its own. Human approval is required at consequential boundaries. Source is preserved until Governed Apply is authorized.
Product status
Controlled delivery — not GA self-service SaaS
FoldEngine Offline Runtime is delivered as a pinned local container with acceptance tests, a delivery manifest, and owner-approved deployment boundaries. “Available” below means present in that controlled-delivery product — not a public SaaS install button.
What stays outside
Self-service GA installation, autonomous scheduling, unrestricted source mutation, and automatic commit / push / merge / deploy / release.
Who holds authority
The operator. Models and agents produce proposals and evidence until a governance boundary is explicitly crossed.
Operating model
Research → Plan → Execute → Review → Ship
Objective Discovery spans Research into Plan and is the gate into Plan. It does not erase Research.
| Stage | What happens |
|---|---|
| Research | Gather project context, source state, evidence, and uncertainty. |
| Plan | Confirm the objective, scope, success criteria, Workcells, and dependencies. Objective Discovery is the gate into Plan. |
| Execute | Run bounded Workcells and Nebula programs through governed methods. |
| Review | Inspect evidence, validation, consequences, and candidate decisions. |
| Ship | Apply authorized changes, validate source state, checkpoint, continue, or close. |
Governance across every stage
Objective · Scope · Evidence · Authority · Lineage · Consequences · Continuity
The workflow says what stage comes next. FoldEngine determines whether the transition is lawful, what evidence must cross with it, who holds authority, what changed, what remains unresolved, and what is permitted next.
Objective
What was authorized — and what remains unconfirmed.
Scope
Which project, workspace, and source boundary apply.
Evidence
What was produced, checked, or left unevaluated.
Authority
Who may act; what requires operator confirmation.
Lineage
How request, Workcell, program, and checkpoint connect.
Consequences
What followed prior outcomes without silent authority.
Continuity
Whether the project can safely continue later.
Operator
Human review stays visible at every consequence crossing.
Capabilities
What FoldEngine Offline Runtime includes
These are capabilities inside one product — not separate commercial SKUs.
Objective Discovery
Turns a raw request into a bounded, reviewable objective while keeping operator statements, evidence, inferences, model proposals, ambiguities, and success criteria distinct. An inferred or model-proposed objective does not silently become authoritative. The operator must confirm it before admission. Objective Discovery is the gate into Plan.
Governed Workcells
A Workcell is a bounded package of engineering work: confirmed objective, scope, success criteria, method, roles, evidence requirements, stop conditions, and operator-review boundaries. Protected source remains protected unless a separate Governed Apply ceremony is authorized.
Method Dispatch
Execution topologies include Linear Pipe, Feedback Cycle, and Scatter-Gather. Roles include Generator, Evaluator, Router, Distiller, and Translator. Local-model invocation is available within configured governed paths. Outputs remain proposals or evidence until authorization is granted.
Nebula Programs
Nebula coordinates related Workcells as a governed program: membership, dependencies, executable frontiers, evidence handoffs, partial completion, blocked states, and human-required pauses. Nebula is not an autonomous scheduler. It returns consequential decisions to the operator.
Review and evidence
Receipts, validation, lineage, and consequence review make operator decisions inspectable. Evidence makes review possible — it is not a compliance guarantee. Formal review does not approve work by itself.
Governed Apply
A candidate does not become a source change automatically. Governed Apply runs: candidate → operator review → admission → authorization → bounded application → validation → source-state receipt. Available under explicit authorization. Not auto-deploy, commit, push, merge, or release.
Project Checkpoints
A Project Checkpoint records accepted project state at a meaningful boundary: confirmed objective, source-state identity, Workcells and Nebula status, evidence, applied changes, unresolved items, operator decisions, and continuation readiness. It is not merely a backup. It supports later continuation, comparison, recovery, or closure.
Current operator surfaces
Surfaces inside FoldEngine Offline Runtime
These are operating surfaces of the Runtime product — not separate product tiers. Organization Operations and Project Workspace live inside the Runtime. Imagery below is synthetic project data rendered from current shell contracts.
Open the full Research → Ship Runtime Preview →
Project posture, activity, and next governed action.
Structure intent, expose ambiguity, confirm before admission.
Capture intent and prepare construction handoff. No implementation begins automatically.
Observe and classify next safe move. Remote repository cloning is not performed by Runtime.
Shape blueprint and acceptance for review — not generated and applied autonomously.
Validation, continuity, and receipt summary for a governed run.
Program membership, frontier, handoffs, and blocked reasons.
Human review before a candidate crosses the next boundary. It does not approve work.
Authorized bounded application and source-state receipt.
Accepted project-state boundary and continuation readiness.
Portfolio visibility — not autonomous portfolio orchestration.
Project view of status, evidence, and next action.
Runtime, storage, models, and mounts. Does not configure environments automatically.
Evolving consolidation of operators, agents, artifacts, and continuity controls.
Two admission paths into one Runtime journey
New Project Guided Intake and Repository Takeover are alternative ways to admit work into the same Research → Plan → Execute → Review → Ship path. They are Offline Runtime surfaces — not separate products.
Admission · Research / Plan
Start a new project
Surface: New Project Guided Intake
Capture intent, discover requirements, identify unknowns, and prepare a construction candidate. No implementation begins automatically.
Admission · Research / Plan
Admit an existing repository
Surface: Repository Takeover Wizard
Preserve source, isolate the workspace, inspect the repository, and prepare a governed candidate. Remote repository cloning is not performed by Runtime.
Plan
Shape the solution
Surface: Construction Workspace
Work through problem shape, blueprint, acceptance criteria, and governed handoff. Architecture is shaped for review — not generated and applied autonomously.
Execute
Trial bounded work
Surface: Workcell
Run isolated execution, validation, evidence capture, continuity, and receipts inside a governed Workcell. Protected source remains protected.
Review
Review before crossing boundaries
Surface: Formal Review Decision
Review evidence, inspect receipts, understand risk, and determine the next governed action. FoldEngine supports review. It does not approve work.
Review
Evidence and receipts
Surfaces: evidence-backed workspaces + export boundary
Inspect provenance, receipts, continuity, and export boundaries. Evidence makes review possible — it is not a compliance guarantee.
Ship / Continuity
Manage projects
Surfaces: Project Workspace · Organization Operations Center
See projects, work status, review queue, readiness, and current next action. This is portfolio visibility — not autonomous portfolio orchestration.
Research
Environment readiness
Surface: Environment Readiness
Check runtime, storage, models, source mounts, and delivery posture before work begins. It does not configure environments automatically.
Local / offline deployment
Deployed carefully, not provisioned casually
Runtime is delivered for local use with guided setup, clear boundaries, and the artifacts a team needs to operate it responsibly.
Guided local deployment
Installed with clear operating boundaries, verification steps, and local support materials.
Not hosted SaaS
Designed for local use by teams that need more control over evidence, review, and boundaries.
Human approval stays in place
Runtime supports review and evidence. It does not silently carry work across consequential boundaries on its own.
Operating boundaries
FoldEngine does not mutate source autonomously. Commit, push, merge, deploy, and release remain outside autonomous authority.
Mac workstation
Linux workstation
Linux server / mini-PC
Docker Desktop
Docker Linux
Cloud / VPS (optional, later)
Capability status
Honest maturity matrix
“Available” means present in the controlled-delivery product, not as GA self-service SaaS.
| Capability | Public status |
|---|---|
| Offline Runtime | Controlled delivery |
| Objective Discovery | Available |
| Governed Workcells | Available |
| Method Dispatch | Available within bounded paths |
| Local-model integration | Available within configured governed paths |
| Nebula Programs | Available |
| Governed Apply | Available under explicit authorization |
| Project Checkpoints | Available |
| Organization Operations | Available / evolving |
| Runtime Administration | Evolving |
| Self-service installation / GA | Not yet available |
Why Offline Runtime is different
Governed work, not just generated output
| Traditional AI | FoldEngine Offline Runtime |
|---|---|
| Produces output | Governs work |
| Optimizes completion | Governs consequence |
| Produces code | Preserves evidence |
| Assumes approval | Preserves human authority |
Governed Repo Diagnostic
First-month walkthrough from mounted repository to review-backed handoff.
Runtime ArchitectureSubsystem map for teams inspecting internals after the buyer story.
Capability MatrixAvailability, evidence, and commercial posture by capability.
Evidence & ReviewReceipts, packages, and human-controlled apply boundaries.
Construction WorkspaceShape and acceptance before Workcell execution.
Governed EngineeringCandidates, apply boundaries, and review packages.
Governed DevelopmentImplementation lifecycle packaging under review.
Consequence IntelligenceAdvisory memory without silent authority.
Projection RuntimeGraphs and export bundles from runtime truth.
Organization MemoryCross-project patterns that remain advisory.
Commercial ProgramsQualification and controlled-delivery expansion paths.
Early access / commercial
See whether FoldEngine Offline Runtime fits your environment
Start with Evaluation Access or a Design Partner engagement. Commercial Runtime and Enterprise / Regulated paths follow qualification — not an instant install path.