What this probe helps you decide
Whether a repo, dependency, framework, SDK, or technical choice is still supported enough to adopt, keep, or migrate from. Stability-Signal detects the gap between how stable something looks (stars, tutorials, familiarity) and how stable it actually is (maintenance activity, governance, documentation drift, migration pressure).
Best lifecycle moment
Before adopting a dependency whose trust signals may be stale. Before renewing commitment to a framework under migration pressure. After a Free First Probe routes you here.
What you submit
One public repo, dependency, framework, SDK, project surface, or technical choice — plus the decision you need to make and any boundary notes (what to avoid, what is sensitive). Do not submit secrets, credentials, or private source code through intake.
What product or surface this targets
Tell us the product, service, feature, SDK, app, workflow, dependency choice, or legacy module inside the repo/project that the probe should focus on. The repo is evidence; it is not automatically the whole target.
What evidence we use
The automated layer reads repo-surface stability-shape evidence (structure, tests, readiness posture, incompleteness). The governed layer adds operator interpretation of public signals only — we do not execute code or access private systems. Historical cadence and drift compound through repeated probes and Stability Ledger entries rather than continuous monitoring. Evidence includes:
- Maintenance cadence: commit activity, release frequency, issue/PR triage
- Governance signals: maintainer capacity, ownership changes, call-for-maintainers
- Documentation drift: whether docs match current recommended paths
- Migration pressure: deprecation notices, ecosystem guidance, successor projects
- Trust-signal mismatch: star count, tutorial prevalence, vs. actual support reality
What you receive
A governed stability-signal package with five parts:
- Verdict — is the target stable enough for the submitted decision, or not
- Signal map — what looked stable vs. what is actually stable, with evidence for each
- Drift and gap findings — specific observations where trust signals diverge from reality
- Boundary of claim — what was and was not checked, and why
- Next stabilizing move — one concrete recommended action
How this differs from other probes
- Free First Probe tells you which probe fits. Stability-Signal delivers the governed findings package.
- Paid Trial Diagnostic is a broader scoped diagnostic for general project questions. Stability-Signal is narrower: it focuses specifically on whether trust signals match support reality.
- AI Code Stability checks whether AI-generated code is actually complete and working. Stability-Signal checks whether a project, dependency, or claim is still supported — regardless of how it was built.
Sample reports
See delivered Stability-Signal samples: Create React App (stale trust after ecosystem migration) and OpenSearch Go (governance seam with transparent maintainer capacity disclosure). Each shows the full report shape: verdict, signal map, drift findings, boundary, next move.
After delivery
Reports are delivered as owner-review-pending. You review the findings privately before any content is shared. After review you may: accept and act on recommendations, request clarification on specific findings, or optionally approve a public testimonial. FoldEngine does not publish findings without explicit client approval.
What this does not include
- Takedown, blame, or condemnation report
- Security audit or penetration testing
- Full code review or implementation work
- Guarantee of current or future stability
- Unbounded private-repo access
Boundary of claim
This probe separates visible confidence from current support reality. It does not certify a project, condemn a project, prove long-term safety, or authorize ongoing monitoring. If the question requires deeper or recurring coverage, the report will recommend a specific next probe or Custom / Quote engagement.
Best-fit examples
- A dependency with high popularity but unclear maintenance direction.
- A framework or SDK with migration pressure or deprecation signals.
- A repo whose documentation memory differs from current ecosystem guidance.
- A technical choice where the team needs to decide: adopt, keep, migrate, or replace.