Author: Curt Doolittle

  • Command Reference Card

    Commands Reference Card (v1.4)

    Purpose → human-readable ingress to the Protocol Registry with deterministic, contract-grade emissions.
    Consequence → every command resolves to a canonical protocol/template with pinned versions, closure invariants, and machine-checkable telemetry.
    Function → fast, decidable analysis in operational language for certification or exploration.


    1) Ingress & Resolution

    • Entry: Protocol:Commands "<command string>"
    • Resolution: router parses → maps aliases → selects canonical protocol/template → applies mode/depth/profiles → executes → emits OUTPUT_CONTRACT.
    • Fail-closed: if no canonical mapping or invariants unmet, emission aborts with diagnostic.

    2) Core Verbs (memorize these)

    A) help

    • help — list verbs and examples
    • help: analyze — usage for analyzers and pipelines

    B) analyze: "<claim or behavior>"

    • Default analysis stack (router chooses appropriate protocol(s)); emits OUTPUT_CONTRACT.

    C) test: <protocol> | input: "<text>"

    • Directly invoke a specific protocol/template by canonical key or alias.
      Examples:
      • test: truth | input: "Price controls reduce shortages."
      • test: reciprocity | input: "Mandatory arbitration is reciprocal."
      • test: possibility | input: "Constructible under physical/legal constraints."

    D) call: <callable>

    • Utility functions, e.g. causal-chain generators: call: causal_chain.cooperation.adaptive.

    E) verdict: "<short claim>"

    • Fast path to ternary/cooperative verdict stitching; returns rationale + stitched contract fields.

    F) align: <action>

    • align: set | id: curt_default — apply alignment profile
    • align: show — display active alignment/overrides

    G) certify: "<claim>"

    • Cause: operator requests certification-grade testimonial truth evaluation.
    • Consequence: router dispatches the certification template and forces the certification emitter profile.
    • Function: emits signed, machine-checkable certificate_payload plus the full cooperation stack.
    • Syntax:
      • certify: "«claim»"
      • Options: --severity high|critical --liability legal|regulated --depth 3 --precision contract

    3) Protocol Keys & Aliases (invoke via test:)

    • truth / ten_tests — testimonial truth suite
    • decidability / decide — decidability of the claim
    • first_principles / hierarchy — first-principles hierarchy test
    • demonstrated_interests / di — DI protocol (double-entry options available)
    • reciprocity — necessary conditions, Q-tests, hard-gates
    • irreciprocity / parasitism — taxonomy & synthesis
    • possibility / feasibility — constructability under constraints
    • cooperation / conflict — cooperation/conflict evaluations
    • warranty_restitution / remedy — warranty, restitution, bonding
    • ternary / evo — ternary verdict & evolutionary computation overlays
    • causal — causal-chain utilities via call: causal_chain.{scale}.{mode}

    4) Options (router “knobs”)

    • Precision: --precision prose | prose+findings | contract | auto
    • Depth: --depth 1|2|3|auto (certification forces 3)
    • Mode: --mode analysis | forensic | adaptive (default = forensic)
    • Telemetry: --telemetry off|min|full (profiles may override)
    • Thresholds: --t1 <float> --t2 <float> (emission thresholds)
    • Profiles: --severity trivial|normal|high|critical, --liability casual|general|regulated|legal

    Defaults (if omitted): mode=forensic, depth=3 (cap), precision=contract, severity=high, liability=regulated; summary=3–5 sentences; findings=10; risks=8.


    5) Execution Order & Determinism

    • Compiled stack: EOSA → Operational Language → Truth → Reciprocity → Decidability.
    • Reciprocity determinism: fixed test order; hard-gates on Warranty/Liability & Restitutability; any hard-gate failure ⇒ Irreciprocal.
    • Missing evidence: never dropped; marked Undecidable with uncertainty uplift recorded.

    6) Outputs (emissions)

    • Standard:OUTPUT_CONTRACT@≥1.3 stitched with:
      • Truth block (confidence, lie-severity)
      • Reciprocity block (per-test results, R_score)
      • Irreciprocity taxonomy (if triggered)
      • Synthesis (final verdict + 2–3 line rationale)
      • Optional DI Ledger linkage (double-entry externalities)
    • Certification runs (certify:):
      • Add certificate_payload (human+machine)
      • Force telemetry.full and full contract fields

    7) Closure Invariants (fail-closed)

    • Versions pinned: OUTPUT_CONTRACT ≥1.3, VERDICT_ENUMS ≥1.2, TELEMETRY ≥1.2.
    • Telemetry minimal set present: trace_id, canonical_id, mode, depth, profiles, schema_hashes.
    • Emission bounds enforced: only allowed contract fields; forbidden fields absent.
    • Ambiguity handling: EOSA/Operational language resolution must complete or the run fails closed.

    8) Quick Examples (copy-paste)

    • Truth test:
      test: truth | input: "Price controls reduce shortages."
    • Reciprocity (strict):
      test: reciprocity | input: "Gig-platform surge pricing with forced arbitration is reciprocal."
    • Possibility:
      test: possibility | input: "Auditable implementation exists with sufficient resources."
    • Causal utility:
      call: causal_chain.cooperation.adaptive
    • Alignment:
      align: set | id: curt_default
    • Certification: certify: "Racism is a harmful behavior that should be suppressed." --severity high --liability legal

    9) Minimal Operator Checklist

    1. Command resolves via Registry (single-door ingress)
    2. Schema versions pinned (≥1.3/≥1.2/≥1.2)
    3. EOSA/Operational language completed; ambiguities resolved
    4. Reciprocity hard-gates evaluated/recorded
    5. Emission contains only contract-sanctioned fields

    Visible audit note

    Applied constraint-layer rules: compiled execution order; reciprocity hard-gates; version pinning; emission bounds; certification profile on certify:.

  • Welcome to Runcible

    We’re excited to welcome you to the new home of Runcible—a place where we share our work on building AI systems that don’t just sound right, but can prove they’re right.

    Over the past few years, AI has exploded in capability. Yet the problem remains: current systems rely on probabilities, not proofs. They produce outputs that feel intelligent but can’t always be explained, verified, or audited.

    That’s where Runcible comes in.

    Our mission is simple: bring decidability, truth, and transparency to AI. We’re developing the decidability protocols that will allow AI to deliver:

    • Verifiable truth instead of plausible guesses.
    • Auditable reasoning so you can see why an answer was given.
    • Ethical alignment grounded in reciprocity, fairness, and first principles.

    The launch of our website is the first step. You can read our official announcement here to learn more about what we’re building and why it matters.

    In the coming weeks, we’ll be using this blog to:

    • Share updates on our technology and research.
    • Explain the ideas behind computable truth and auditable AI.
    • Discuss the future of AI ethics, governance, and transparency.

    We’re glad you’re here. The journey toward auditable, trustworthy AI starts now.

    — The Runcible Team