RCS Scanner

Scanner · Step 1

Evidence-based scanner. Every claim has an explicit verification status (✓ verified, ~ inferred, ? unknown, ✗ rejected) and points to the code that supports it. No LLM in this v1 — pure ts-morph + structural inference.

strict (verify each claim)

Loading…

Reference — what RCS is, when to use it, how it differs from MCS

RCS Scan vs MCS — when to use which

Both run evidence-based claim verification on your code against the AMBER registry. They overlap in spirit but serve different moments in the lifecycle.

RCS Scan (this page)

Goal: fast claim check during dev iteration
States: 4 — verified / inferred / unknown / rejected
Verifier layers: 2 — static + optional CPF semantic (via strict checkbox)
Output: last-scan.json + run-history index
Use it for: daily dev — see whether your recent changes broke any cap-claim

MCS (/amber/mcs)

Goal: formal audit before publish
States: 5 — adds contradicted
Verifier layers: 4 — static + semantic + contradiction + negative-evidence
Output: 10 mandatory artifacts + 6 quality gates + run archive + drift
Use it for: sales decks, compliance audits, release reviews — when the output needs to be unimpeachable

Promote to AMBER lives on /amber/mcs only. RCS Scan stays a pure read view — for promoting MCS facts into the AMBER registry (body / sla / dependencies / risks), use MCS.

Think of it like: RCS Scan is the dev linter. MCS is the auditor.

4 Decision States in RCS

verifiedClaim passes static proof check (and CPF semantic check in strict mode). Publishable.

inferredStatic structural shape matches but no literal/quote proof. Strong indication, weak proof.

unknownNo evidence found either way.

rejectedClaim was generated but evidence does not support it.

RCS does NOT have contradicted. For numeric/policy contradictions against code, use MCS.

Strict mode (CPF)

When checked, every RCS claim is piped through the Claim-Proof-Fact pipeline (the same engine that powers MCS's static layer). The CPF engine adds a literal-quote check on top of the structural extractor — every cited line must contain the claimed value verbatim. Without strict, only the structural extractor runs; with strict, false-positive structural claims drop out to rejected instead of staying inferred.

Strict adds ~30-50% scan time. Worth it before any publish; skip it during refactor loops.