Ten weighted domains
Security, code quality, testing, reliability, performance, DevOps, operations, compliance, product, and business readiness. Each is scored from collected evidence and weighted into one overall score.
Methodology · a primer
How an assessment is actually produced.
Investors are right to be sceptical of AI-generated readiness scores. This page lays out exactly how a run is constructed, what we measure with confidence, what we measure as advisory, and what we don't touch at all. Read it before you read the report.
Pipeline
Four phases. Auditable end-to-end.
- Phase 01
Collect
A read-only GitHub connector (Personal Access Token, scoped to read) collects the evidence an assessment needs: code, configuration, and repository metadata. Connector credentials are encrypted at rest, zeroed on revoke, and never returned in API responses.
Read-only. Revocable. Never cloned. - Phase 02
Evaluate
500+ deterministic rules across four frameworks and 44 modular packs evaluate the collected evidence. Pass / fail / unknown. Never a hallucination. Same evidence in, same findings out, every run.
Reproducible. Auditable. Pure functions. - Phase 03
Reason
Up to 30 AI agents, 29 specialists plus an orchestrator (selection depends on what the codebase contains), read the evidence and produce qualitative findings: architecture critique, IP provenance, ops maturity, support readiness. Every agent output is validated before it can become a finding; anything questionable is flagged for human review, never silently accepted.
Schema-validated. Bounded. Human-flagged. - Phase 04
Report
Findings are deduplicated across runs, scored, and assembled into the report suite. Every finding cites a control code and an evidence trail; code-pattern findings additionally cite a file location, with a line range when the analysis can pinpoint it precisely. Resolutions persist across runs, so you don't re-resolve the same issue every quarter.
Deduplicated. Cited. Sticky-resolved.
Release Readiness Index
How the score works, and why it can't flatter you.
The RRI is the scoring overlay behind the signed certificate. It is built so an honest 62 means more than an inflated 95.
Gates cap the tier
Must-pass gates (no unremediated criticals, no live leaked secrets, DR tested, clean OSS licences, and more) cap the certified tier regardless of the average. A 91% score with one live critical still certifies Not Release Ready.
Verified vs attested
Every control is marked machine-verified, human-attested, or unassessed. Controls machines can't check (pen tests, DR rehearsals, IP assignments) pass only via a recorded attestation, and the certificate shows the split.
Unassessed is a gap, not a pass
Anything we couldn't collect evidence for is excluded from the score and reported as a coverage gap. Nothing silently passes.
Evidence goes stale
Each domain has a freshness policy: old evidence decays in weight over time, so a certificate reflects the codebase now, not the codebase last year.
Tiers, not vibes
95+ Enterprise Ready · 90 Investor Ready · 80 Production Ready · 70 Pilot Ready · below 70 Not Release Ready. The certificate names the tier, the gates that bound it, and the path to the next one.
Coverage
What we measure. What we don't.
Inside scope
What we measure
- Software supply chain: bill of materials, build provenance, release signing, dependency pinning
- Where change concentrates, who owns it, and whether it is tested
- Engineering process: review enforcement, approval integrity, ownership, review capacity
- The runtime AI dependency: declaration, version stability, prompt trust boundary, cost bounds
- Architecture quality, separation of concerns, technical debt signals
- Security baseline, auth, authorization, secrets, dependency provenance
- Operational maturity, monitoring, alerting, rollback, release governance
- Documentation completeness, runbooks, API contracts
- Testing maturity, coverage signals, test categories, CI integration
- Multi-tenant isolation and tenancy model fitness
- IP / licensing, dependency audit, SPDX provenance
- Code quality, linting, structure, complexity heuristics
Outside scope
What we don't
- Certification conformance itself. We assess readiness against a framework's controls; we do not audit, and we hold no certifications
- Model behaviour testing for AI-bearing systems, which static evidence cannot reach
- Customer references, churn, NPS, or revenue concentration
- Live penetration testing, exploit chaining, runtime fuzzing
- Financial DD, books, runway, cap table, options pool
- Legal review of customer contracts, MSAs, NDAs, employment IP
- Patent / trademark / IP search beyond connected source
- Operational runtime, production incidents, observability, on-call
- Founder background checks or reference calls
- The judgement of an experienced operator at the table
Reproducibility
What you can re-run. What you can't.
The platform mixes deterministic measurement with AI reasoning. We label each layer so you know what to weight.
Assurance level
Published per control
Every control carries one of three levels. Verified means the configuration or measured history was read directly, so absence is a real finding. Indicative means a strong signal in source, flagged for review rather than asserted, at reduced confidence. Declared means a document references the control, which evidences the subject was considered and nothing more, and is excluded from the automated score. Coverage is reported split by these levels rather than as a single number.
Rule layer
Fully deterministic
Same evidence in, same findings out, every run. The 500+ rules are pure functions over collected evidence. Re-run an assessment and diff the results to see exactly what changed in the codebase.
AI agent layer
Advisory, schema-validated
Agent outputs are reasoning, not measurement. Two runs against the same SHA can produce different finding text and small score deltas. We validate every output against a schema before persisting, and flag low-confidence runs for human review. Treat agent findings as expert hints, not verdicts.
Cross-source dedup
Probabilistic
When a rule and an agent surface what looks like the same issue, we collapse them via concept overlap. This is heuristic, it can over-suppress generic findings or under-suppress different phrasings of the same issue. We err on the side of showing more, not less.
Human loop
“The platform replaces the prep work for the meeting. Not the meeting itself.”
, On where you take the wheel
- 01
Resolve findings deliberately
Mark each finding with a resolution category, FIXED, ACCEPTED_RISK, FALSE_POSITIVE, NOT_APPLICABLE, or WON'T_FIX. Sticky resolutions persist across re-runs so you don't re-resolve the same issue every quarter. A richer reviewer UI (agree / dispute / not relevant) is on the roadmap.
- 02
Re-run on the same SHA
The first sanity check on any AI-driven assessment: re-run it. Rules will be identical. Agent findings should overlap heavily. A wide delta is a signal, not a feature.
- 03
Pair with a human DD lead
Treat the report as the brief for a 60-minute conversation with the target's CTO. Use the findings as your agenda. The platform replaces the prep work, not the meeting.
Let's talk
Still have a methodology question?
We'd rather field your hardest question now than have you discover it three weeks into a deal.