Sample outputs
Trial Probe examples show bounded decision reports: findings, evidence gaps, a recommendation, a decision, and the next move. FoldEngine Runtime examples show governed evidence, candidate artifacts, receipts, and review surfaces from offline work. All samples here are representative public examples — not private work, and not live backend responses or self-serve report downloads.
Runtime walkthroughs
These walkthroughs show how the runtime is expected to move through input, construction, engineering, validation, evidence, review, and output for realistic engineering cases.
Flagship example
A full customer-facing case study showing what a CTO or engineering director receives in the first month: mounted repo intake, construction workspace outputs, governed engineering planning, development packaging, validation posture, evidence bundle, and review handoff.
Python microservice
Input: mounted Python service repo. Construction: blueprint + acceptance. Engineering: bounded candidate. Validation: pytest/ruff route if available. Output: evidence + review package.
Node API
Input: Node or TypeScript service. Construction: dependency and acceptance mapping. Engineering: governed patch candidate. Validation: npm/tsc route if supported. Output: receipts, review package, export candidate.
.NET / Java backend
Input: enterprise backend repo. Construction: requirements and dependencies. Development: implementation, tests, docs, architecture impact, release-note planning. Output: governed development package.
Mixed repository
Input: polyglot repo. Construction: identify bounded slice. Projection: problem, requirement, and dependency graphs. Output: next safe move with explicit ambiguity preserved.
Regulated banking change
Input: governed change request. Construction: acceptance and review mapping. Evidence: receipts, validation, continuity, export posture. Output: review handoff without compliance overclaim.
Legacy modernization
Input: risky legacy repo. Takeover: discovery + stack posture. Construction: bounded modernization slice. Output: future candidate contract, evidence plan, and readiness gaps for the next phase.
Entry diagnostics
Sample bounded decision reports.
Sample bounded decision reports and continuity deliverables. Static public examples only — each names the assessed surface, evidence boundary, and supported claim where practical.
Probe Reports
Static public examples only.
Public example
Evidence-backed
Assessment: Mature library / paid diagnostic
Repo: pallets/flask
Product surface: public Flask repository structure. Decision: is it suitable for a bounded structure-alignment probe?
The public repository surface has enough visible structure to support a focused docs/examples/tests/src alignment check.
Public repo overview, docs/tests/examples/src path shape, visible evidence, and the bounded approved probe path.
Full code review, security audit, legal/compliance review, private systems, repo code execution, or exhaustive dependency audit.
Run a focused docs/examples/tests/src alignment pass on one representative feature.
Public example
Supported claim check
Repo: milla-jovovich/mempalace
Is the public Memory Palace retrieval benchmark claim supported by committed evidence?
Evidence-backed committed artifact alignment: raw LongMemEval rows 500, raw LongMemEval Recall@5 0.966. This is not independent scientific proof.
Plain-language read: this sample shows how the probe surfaces whether benchmark-style claims have enough surrounding evidence to be trusted.
Public repo surface, committed benchmark result artifact, benchmark documentation, and retrieval implementation anchors.
Independent benchmark rerun, full code review, security audit, legal/compliance review, private systems, or permanent stability.
Tighten stronger rerank/perfect-score wording so it names exact artifact, split, and metric.
Public example
Stale trust signal
Assessment: Stale-trust / library-package choice
Repo: react/create-react-app
Product surface: CRA as an app-starting toolchain choice. Decision: can a highly familiar public repo still carry stale stability signals after its ecosystem moves on?
Create React App is a public example where popularity, tutorials, and legacy familiarity outlived the current recommended path for new React apps.
Chosen because it demonstrates what happens when trust signals go stale around a once-popular project.
React deprecation guidance, public GitHub repo state, React 19 breakage discussion, and documentation drift signals.
Private apps, repo code execution, maintainer intent, full migration planning, or security review.
Create a migration decision receipt that classifies the app type and chooses a framework or modern build-tool path.
Static sample
Popularity evidence
Assessment: Popularity signal / repo trust context
Repo: psf/requests
Product surface: one public GitHub repository popularity/support signal. Decision: does the visible star signal line up with surrounding public evidence?
The sample report shows popularity support as a bounded evidence comparison, with score drivers, evidence gaps, and a safe next step.
This report does not determine whether stars are artificial, purchased, automated, fraudulent, bot-driven, scam-related, or owner-intent related. It compares visible popularity to surrounding public evidence.
Private systems, code execution, full due diligence, security review, or live public endpoint execution.
Continuity deliverables
A delivered report becomes a ledger entry after delivery approval. The project's Stability Ledger is the running history across those entries: what was checked, what recommendations emerged, which decision applies, what is waiting on review, and what evidence moved the state forward.
The sample below uses fake/internal/sample data only. It demonstrates continuity across repeated probes, not an account area, unattended delivery, or private client publication.
Stability Ledger sample
Data: fake/internal/sample data only
Visual gallery bands
AI, dependency, and stability-signal examples.
Paid Deliverable v1
Static layout sample · fake/internal data only
Shows how a governed probe produces bounded recommendations, a proceed/hold/block decision receipt, and a review-ready next-step order alongside findings and a Stability Ledger summary.
Stability Ledger sample
Data: fake/internal/sample data only
A static example showing how repeated probes can record what changed, what improved, what regressed, and the next recommended move. This is not an interactive account area or self-serve delivery feature.
AI Code Stability Probe · CA$500
Target shape: AI-assisted codebase
Repo: ruvnet/RuView
See how a governed probe turns an AI-assisted repo from "it seems to work" into bounded findings, recommendations, a decision receipt, and an ordered stabilization plan. This sample checks for generated-pattern drift, claim-to-artifact traceability, and stabilization debt.
AI Stack Audit · CA$1,000
Target shape: Stack-surface diagnostic
Repo: aws-samples/sample-serverless-pydantic-agents
A bounded stack-surface diagnostic that turns stated boundaries into a next-move checklist — not a security audit or production certification.
Dependency Watch · CA$1,500/qtr
Target shape: Dependency trust / dependency-heavy app
Repo: google-gemini/deprecated-generative-ai-python
Official SDK deprecated but still installable on PyPI. Trust decayed while the package remained available. Dependency Watch becomes more valuable across repeated ledger entries: each run can compare what changed, what stayed risky, and what next move is now supported.
Stability-Signal subtype · CA$500
Repo: opensearch-project/opensearch-go
Official namespace, transparent maintainer capacity disclosure. This is a Stability-Signal governance seam example, not a new top-level service.
Custom / Stability-Signal subtype
Project: Home Assistant
Active project narrowed install methods because support burden exceeded benefit. This is a Custom / Stability-Signal example, not a new top-level service.
Free First Probe · Free
Target shape: Routing / fit-check entry probe
Repo: ruvnet/RuView
A no-cost fit check that routes an AI-generated Chrome extension to the AI Code Stability Probe, with visible evidence and a clear next move.
Receipts / Supporting Artifacts
Summary receipts and evidence-boundary anchors accompany report samples.
Compare lanes
| Trial Probe | FoldEngine Runtime |
|---|---|
| Entry diagnostic | Operational runtime |
| One assessment | Ongoing governed work |
| Probe report | Evidence and receipt chain |
| Recommendation | Guided execution and review |
| Hosted entry | Offline runtime |
Runtime governed outputs
FoldEngine Runtime produces governed evidence, candidate artifacts, receipts, and review surfaces. The examples below illustrate the kinds of outputs a team receives during governed work. Examples are representative candidate outputs. They remain subject to review.
Runtime output example
Question: How does FoldEngine capture a new project?
Runtime surface: New Project Guided Intake
Example output
Why it matters: Teams see intent captured before any build work begins.
Authority: No implementation has begun.
Runtime output example
Question: What does shaped work look like before the workcell?
Runtime surface: Construction Workspace
Example output
Why it matters: Reviewers inspect planning candidates before bounded execution.
Authority: Planning candidate only.
Runtime output example
Question: How does Runtime govern an existing repository?
Runtime surface: Repository Takeover Wizard
Example output
Why it matters: Teams classify the next safe move without mutating source.
Authority: Protected source remains unchanged.
Runtime output example
Question: What does review look like before a boundary crossing?
Runtime surface: Formal Review Decision
Example output
Why it matters: Review happens with evidence attached — not as a hidden approval step.
Authority: FoldEngine supports review. Humans approve.
Runtime output example
Question: What evidence does a governed run produce?
Runtime surface: Workcell Run Detail
Example output
Why it matters: Decisions trace back to inspectable proof — not narrative alone.
Authority: Evidence supports decisions. Evidence is not approval.
Runtime output example
Question: How do leads see portfolio posture inside Runtime?
Runtime surface: Organization Operations Center
Example output
Why it matters: Operators see current posture without losing review boundaries.
Authority: Operational visibility. Not autonomous portfolio management.
Documentation projection
FoldEngine can prepare audience-specific documentation candidates derived from governed runtime truth. Examples include:
These remain candidate artifacts requiring human review. Publication remains human-controlled.
Next step
Examples show the shape of the evidence, review surfaces, and candidate artifacts. The next commercial step is a governed repo diagnostic in your environment.
