CAPAS compiles supplied evidence into a claim admissibility decision.
A claim and its evidence fields go in. ACCEPT, REWRITE, REJECT, or HOLD comes out. CAPAS does not certify scientific truth; it decides whether declared evidence licenses controlled reuse.
CAPAS workflow
mode → evidence → gateCAPAS deterministic claim gate
Run sends this payload to /api/decide on capas.krenniq.com (Azure, East US). It is processed in memory, not written to disk and not used for training. For confidential evidence, run CAPAS locally: pip install capas-claim-gate.
Candidate extraction aid
human confirmation required- the verdict and the rule that fired
- the licensed reuse boundary: what the evidence permits
- blockers and open proof obligations
- the next operational action and fine-tune readiness
- the re-derivable JSON and audit hash
Full output JSON
Audit trail
CAPAS shortcuts and pipeline modes
Shortcuts
Cmd/Ctrl + Enter: runs the gate on one claim.?: opens or closes this help.EnterorSpaceon a history item: restores it.
Batch mode
Paste a JSON array, an object with items or claims, or one payload. Every item meets the same rules; the output is a summary. Missing evidence is not inferred.
Pipeline surfaces
The CLI and API support decide, batch, and retrieve → extract → align → reason → pipeline. Retrieval and parsing prepare candidate evidence; the gate returns the verdict.
Paper/text ingestion
The ingestion panel accepts pasted text, abstracts, theorem notes, local text, Markdown or JSON files, and PDF provenance metadata. It proposes candidate claims with source spans; a reviewer clicks Confirm & build payload before any candidate is decided. The panel extracts explicit spans only.
For richer ingestion, use the CLI commands retrieve, extract, align, and pipeline. Local corpus adapters replace Semantic Scholar, PubMed, Elicit, or internal metadata exports.
Guided claim builder
The no-code builder redraws required evidence fields whenever the claim type changes. It emits a schema v3 payload with the minimum fields for that type plus a training_evidence scaffold.
Fine-tune readiness
fine_tune_ready is a downstream training-data gate; the browser cannot set it. 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. The gate decides claims; it does not silently certify training data.
State of each criterion: Declared (the user asserts it; not verified): source_backed_evidence, external_review, semantic_alignment, witness_independence. Computed (the engine recomputes it): verdict_accept, schema_clean, provenance_sources, review_id_present, witness_id_present. Verified (against a hash or a registry): review_hash_verified. Not available on this site (needs library mode with local registries or CAPAS_VERIFY_REMOTE_SOURCES=1): source_urls_recoverable_hashable, witness_registry_resolved, ro_crate_validated, reviewer_attestation_verified. On this site the maximum reachable is 10 of 14, so fine_tune_ready cannot be true here.
The static browser UI previews these criteria; it performs no provenance I/O. The five provenance gates require capas.py CLI/API verification.
Admissibility certificate
Every decision includes an admissibility_certificate over five ordered axes: contract, evidence, boundary, provenance, and defeaters. It records the licensed reuse boundary, open proof obligations, defeaters, and the next operational action: repair_schema, edit_and_resubmit, or verify_provenance_for_training.
Batch mode aggregates these certificates into an admissibility_summary and an exception_queue; review work routes by boundary, not by verdict alone.
Schema
Current schema: capas-claim-payload-v3. Outputs include schema_version.
Supported claim types and minimum evidence fields:
claim_transition:upgrade_evidence_presentexact_model_solution:abs_error,toleranceinterval_band_claim:estimate,ci_low,ci_high,ci_level,band{low, high},band_pre_registered(ACCEPT only if the whole interval lies inside the pre-registered band)financial_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 in [0, 1]; abs_error, tolerance, and empirical_tolerance at or above 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.
Only absolute_anchor can license a universal-anchor ACCEPT. relative_anchor, empirical_anchor, and benchmark_anchor are versioned contracts; they can yield a bounded REWRITE, never universal correctness.