Evaluate the added information.
- Useful findings beyond the existing CI and review process.
- False or unnecessary warnings and unclassified failures.
- Setup effort, maintenance and repeat-check cost.
FOR TEAMS REVIEWING AI CHANGES
Review AI changes against your team’s checks.
Connect change records, executed checks and open review items in an environment agreed for your repositories. Start with observation and reporting, not automatic merging.
A private execution path is separate from a hosted subscription. Repository access, isolation, costs and evidence transfer are agreed before execution.
Agree what a useful result would look like.
A discussion can start with 1–3 repositories, 30–100 candidate changes and a 2–4 week evaluation. These are planning ranges, not a promised schedule or an included hosted entitlement.
Keep the evidence types separate.
A log records an execution. A rule classifies available evidence. An AI explanation interprets it. None silently substitutes for the others; an unrun check remains unrun.
Review the current capability boundaries →How the PoC proceeds.
- 01
PoC enquiry
Tell us the review problem and your execution constraints. Do not send source code or API keys.
- 02
Feasibility check
Identify repository access, supported commands, isolation and data handling.
- 03
Agree scope and price
Document deliverables, responsibilities, limits and evaluation criteria.
- 04
Execute and review
Review case-level evidence and decide whether continued use is worthwhile.
Choose the capacity your review workflow needs.
All three plans below are hosted service plans. Start with records, then choose the run allowance and workspace-user capacity you need.
Bring your own key (BYOK) is required on every plan for model execution. Your subscription covers the listed service allowance; your provider bills model usage separately. An AdaptOrch key authenticates the service, not the model provider.
Optional ensemble fan-out calls 2–5 of your own models in a configured run. One admitted run uses one call from your plan quota; your provider bills the tokens for every member. Provider cost depends on the models, tokens and attempts. Workspace users are people, not ensemble model members. Agreement is not an accuracy guarantee.
Model outputs and AI-written explanations are AI-generated and require human review. They are not the same evidence as execution logs or results from checks that actually ran.
PLAN
POSITIONING
MONTHLY
INCLUDES
ACTION
01STARTER
Connect and inspect your first records
$0/month
Hosted API access; your provider key
50 admitted runs/month · 1 workspace user
Run records and available artifacts
Start free →
02PROREPEATED REVIEW WORK
Repeat reviews with room to grow
$39/month
500 admitted runs/month · 5 workspace users
Available reports and export controls
Retained run and check records when supplied
Advanced dashboard access
Choose Pro →
03TEAM
Review records in a shared workspace
$149/month
2,500 admitted runs/month · 15 workspace users
Shared workspace capacity
Configured dashboard access
Discuss a separate repository-validation scope
Choose Team →
04PRIVATE RUNNER / POC
Repository validation / private environment
Directcontract
Evaluation period agreed after feasibility review
Starting discussion: 1–3 repositories · 30–100 candidates
Case-level reports and unclassified failures
Compare useful findings and operating effort
Discuss PoC →
Hosted plans do not automatically apply or merge repository changes. Separately configured checks may apply a candidate in an agreed workspace. Human review and the recorded execution boundaries remain explicit.
What counts as a run?
The monthly allowance counts admitted runs, not status or artifact reads. It is used at admission rather than at SUCCEEDED. Internal attempts remain in that run; a separately admitted rerun counts again. Provider billing is independent.
What needs separate setup?
Repository command checks need a separately configured execution environment. A Pro or Team upgrade does not turn hosted command verification on; setup and execution-environment costs are agreed separately.
CEK technical context and research
CEK is the technical evidence layer used by configured validation paths. Applicability checks, realized diffs, rule findings and replay metadata depend on that path. Research results are not a hosted feature guarantee or general correctness proof.
correctness_claim=false
Research archive · measured work and projectionsNot customer performance or a hosted feature guarantee
One measured run.
paired_confirmatory_ledger: 30 synthetic ledger tasks, one paired session. Baseline 86.7%, verified 100.0%, difference +13.3pp (95% CI +3.3 to +26.7). The aggregate paired verdict did not reach significance and the family gate did not pass: directional, not proven. This is separate from the A/C ledger comparison. Plates 01–02 are scenario projections, not measured AdaptOrch benchmark results.
Discuss a repository-validation PoC
What do you need to verify?
Start with the problem. We will first establish whether the requested execution path is feasible; scope, cost and timing are agreed separately.
Do not include source code, credentials, customer data or API keys. This form is an enquiry, not an execution request.