CAPAS compiles supplied evidence into a claim admissibility decision.
Claim plus evidence goes in; ACCEPT, REWRITE, REJECT, or HOLD comes out. CAPAS does not certify scientific truth. It decides whether supplied evidence licenses a claim for controlled reuse in reports, datasets, or fine-tuning.
CAPAS workflow
mode → evidence → gateCAPAS deterministic claim gate
Candidate extraction aid
human confirmation required- the verdict (ACCEPT / REWRITE / REJECT / HOLD) and the rule that fired
- the licensed reuse boundary — exactly what the evidence permits
- blockers and open proof obligations
- the next operational action and fine-tune readiness
- the raw, re-derivable JSON + audit hash
Full output JSON
Audit trail
CAPAS shortcuts and pipeline modes
Shortcuts
Cmd/Ctrl + Enter: run Decide on one claim.?: open or close this help modal.EnterorSpaceon a history item: restore it.
Batch mode
Paste a JSON array, an object with items or claims, or one claim/evidence payload. Batch applies the same deterministic rule to every item and returns a summary. It does not infer missing evidence.
Pipeline surfaces
The CLI/API support decide, batch, and standalone retrieve → extract → align → reason → pipeline. Retrieval and parsing prepare candidate evidence; the final CAPAS verdict still comes from the deterministic gate.
Paper/text ingestion
The browser ingestion panel accepts pasted paper text, abstracts, theorem notes, local text/Markdown/JSON files, and PDF provenance metadata. It proposes candidate claims with source spans, but a human must click Confirm & build payload before the candidate can be decided. This is an explicit extraction aid, not broad paper understanding or theorem proving.
For richer ingestion, use the CLI retrieve, extract, align, and pipeline commands. Local corpus adapters can stand in for Semantic Scholar, PubMed, Elicit, or internal metadata exports before CAPAS applies the deterministic final gate.
Guided claim builder
The no-code builder redraws required evidence fields whenever the claim type changes. It creates a schema v3 payload with the minimum evidence fields for that type plus a training_evidence scaffold, so paper or theorem candidates can be promoted into editable CAPAS payloads without hand-writing JSON.
Fine-tune readiness
fine_tune_ready is a downstream training-data gate, not a browser promise. It becomes true only after an ACCEPT verdict plus source-backed evidence, semantic alignment, witness independence, a hash-verified external review packet, recoverable/hashable source URLs, a resolvable witness registry entry, a valid RO-Crate provenance packet, and a verifiable reviewer attestation. CAPAS gates claims; it does not silently certify training data.
The static browser UI previews these criteria but cannot perform active provenance I/O. The five provenance gates require capas.py CLI/API verification to resolve registries, hash sources, and validate RO-Crate packets.
Admissibility certificate
Every decision includes an admissibility_certificate: a deterministic compiler-style certificate over five ordered axes (contract, evidence, boundary, provenance, and defeaters). The certificate records the licensed reuse boundary, open proof obligations, dialectical undercutters/rebuttals, and the next operational action such as repair_schema, edit_and_resubmit, or verify_provenance_for_training.
Batch mode aggregates these certificates into an admissibility_summary and exception_queue, so review work is routed by formal boundary rather than by raw verdict alone.
Schema
Current payload schema: capas-claim-payload-v3. Outputs include schema_version for audit trails.
Supported claim types and minimum evidence fields:
claim_transition:upgrade_evidence_presentexact_model_solution:abs_error,tolerancefinancial_metric_claim:reported_value,reference_value,tolerance,metric_period_matchphysical_accuracy:within_chemical_accuracyreproducibility_check:artifact_available,independent_reproduction_passstatistical_confidence:p_value,alpha,effect_direction_confirmeduniversal_anchor_claim:anchor_mode,local_property_tests_pass, plus the selected anchor contract (absolute_anchor,relative_anchor,empirical_anchor, orbenchmark_anchor)causal_mechanism_claim:intervention_or_natural_experiment,temporal_order_established,confounders_controlled,mechanism_evidence_presentsystematic_review_claim:protocol_registered,inclusion_criteria_declared,risk_of_bias_assessed,effect_consistencyevidence_conflict_claim:supporting_sources,contradicting_sources,conflict_resolution_method,resolution_pre_registeredmultimodal_evidence_claim:modality,source_hashes_verified,cross_modal_alignment,extraction_method_declaredprogramming_language_behavior_claim:language,language_version,claim_api,code_snippet,expected_output,observed_output,execution_observed,runtime_environment_declared
Numeric validation ranges: p_value and alpha must be between 0 and 1; abs_error, tolerance, and empirical_tolerance must be greater than or equal to 0.
training_evidence.source_backed_evidence, external_review, semantic_alignment, and witness_independence must be booleans and must live at the payload root. Nesting training_evidence inside evidence is a schema error.
absolute_anchor is the only anchor mode that can license a universal-anchor ACCEPT. relative_anchor, empirical_anchor, and benchmark_anchor are versioned contracts that can produce bounded REWRITE decisions but not universal correctness.