Curt Doolittle

Form: Project Update

  • (RUNCIBLE) COMPARISON OF AI’S – MORNING TEST RUN 1. OpenAI (deep, insightful, be

    (RUNCIBLE)
    COMPARISON OF AI’S – MORNING TEST RUN
    1. OpenAI (deep, insightful, best understanding)
    2. Grok (deep, current, but a touch glossing)
    3. Gemini (shallow)
    4. Anthropic (far behind)

    What we do is very hard for LLMs. It exposes their abilities partly because we’re between novel and revolutoinary so they can’t regurgitate existing patterns.. So it has to reason quite a bit more deeply.

    We are at the stage of development where we’ve provent the Runcible governance for LLMs works, and we can just add additional protocols (tests, gates, outputs) to expand the breadth.

    Cheers

    Source date (UTC): 2026-03-21 14:03:57 UTC

    Original post: https://twitter.com/i/web/status/2035356742435889232

  • (NLI, Runcible) Brad and I are working on Volume 3 – the logic of Evolutionary C

    (NLI, Runcible)
    Brad and I are working on Volume 3 – the logic of Evolutionary Computation. And today we’re working on chapter 5, the ternary logic.
    So we’re drafting this chapter from its outline, and brad has an insight, and in his usual insidious way 😉 suggested we run down

    Source date (UTC): 2026-02-15 00:53:05 UTC

    Original post: https://twitter.com/i/web/status/2022836526657462488

  • (Runcible) UPDATE: Ok. So despite all my efforts at trying to keep Runcible Inte

    (Runcible)
    UPDATE: Ok. So despite all my efforts at trying to keep Runcible Intelligence (Runcible Governance Layer) a minimum package applicable to any LLM, with the intention of licensing the tech to the major foundation model producers, I’ve discovered we essentially have to produce the same technology stack as every other Lab, with the only difference that we govern an LLM rather than train one. Which is a heck of a different objective and a lot less work. Otherwise it’s exactly the same architecture and division of labor.
    The immediate benefits of the extra scale are:
    1. We can modify the code of the LLM we use as a router and mixture of experts.
    2. We can (eventually) modify the attention nodes for even greater precision.
    3. We can reach out and touch every foundation model and constrain it indirectly instead of locally (we send a package of protocols).
    4. We can produce the protocols for a vertical market in hours (yes really) because the core (epistemic layer) can process literally anything.
    5. So we can cover the entire set of markets in trivial time.
    6. We have better control over our IP which is the ‘secret’ to the velocity of production and the universalism of the core’s application.
    And that’s just the beginning.
    I was struggling to try to ‘keep it simple’. But without having to wait for approval from someone’s partnership program, and jump through hoops, asking them for special dispensation, and in addition waiting on their partnership decision cycle, and their adoption decision cycle, we can go to market immediately.
    We already have our first customers.
    And we can see the radical ramp up for an LLM that doesn’t hallucinate and produces warrantable and lability defensible outputs.
    Cheers
    CD

    Source date (UTC): 2026-01-31 19:15:47 UTC

    Original post: https://twitter.com/i/web/status/2017678214609748178

  • RUNCIBLE GOVERNANCE – MODEL CURRENCY K2 apparently just came out with a killer m

    RUNCIBLE GOVERNANCE – MODEL CURRENCY
    K2 apparently just came out with a killer model that’s open source and with a hella-lot of parameters. I won’t have time to play with it any time soon, but I think we might be getting closer to exiting the proprietary model issue.

    But one warning: models must stay current. There is an absurd cost to keeping models current. It is hard to see open source without some sort of funding (state?) keeping current if they effectively deprive the for-profit firms of moat and revenue.
    Now

    One pitch we might make is that our work almost guarantees curation of information that can be added to models to keep them current.

    Source date (UTC): 2026-01-27 18:26:50 UTC

    Original post: https://twitter.com/i/web/status/2016216342555459965

  • Preparing Runcible for Diffusion Models as well as LLMs @werrellbradley, @lukewe

    Preparing Runcible for Diffusion Models as well as LLMs

    @werrellbradley

    ,

    @lukeweinhagen

    ,

    @autistocratms

    ,

    @noahrevoy

    ,

    @SaitouHajime00

    @RobertRoe01

    @Claffertysh

    @ThruTheHayes

    @bryanbrey
    PROMPT
    I understand functional programming, I understand object oriented programming, I understand state machines with dynamic execution and self modifying systems, I understand expert systems, I understand machine learning, I understand LLMs, I understand diffusion models. I see applications for each, although, the LLM technology appears to allow me to produce more dynamic outputs than the previous architectures.
    Of late there is a lot of interest in diffusion models as an alternative to LLMs, even for text. But (a) IMO diffusion models gravitate toward existing representations and often disappointingly so, and (b) I am having trouble understanding whether diffusion models for textual content can be governed with something akin to our Runcible Governance Layer. Can you help me with this?
    RESPONSE
    You can govern text-diffusion with a Runcible-like layer, but you must separate     (i) governance as an external procedure (model-agnostic) from (ii) governance as an internal control signal (model-specific). Diffusion is not a blocker; it just changes where you can intervene and what you can log.1)
    Text diffusion is not one thing; it is at least two families:
    1. Discrete diffusion over tokens
      Forward process: progressively corrupt tokens (often independently per position) via categorical transitions; reverse process: iteratively denoise back to a token sequence. ACL 2025 summarizes this “tokens as discrete random variables” approach and its common independence assumptions per token.
      A useful mental bridge:       masked language modeling is a degenerate diffusion case; D3PM work explicitly notes “BERT is a one-step diffusion model” under an absorbing-[MASK] transition choice.

    2. Continuous diffusion over latent/embedding representations
      Forward process: add continuous noise in a continuous space (often sentence-level or latent-level); reverse: denoise continuous vectors, then decode to tokens. ACL 2025 also calls out a common limitation: sentence-level continuous diffusion often imposes       uniform noise levels across all tokens, restricting token-wise contextual recovery.
    A third adjacent category—often conflated in “diffusion for sequences”—is masked generative / iterative refinement (MaskGIT-style predict–mask–resample). Conceptually it behaves like a discrete diffusion schedule even when the authors don’t brand it as diffusion.
    Diffusion training is, in effect, “learn to invert corruption by predicting what a typical in-distribution completion looks like given a partially destroyed sample.” That objective has two predictable consequences:
    Imputation bias (regression-to-the-manifold): denoising steps preferentially move toward high-density regions of the training distribution. Unless you add a strong conditioning signal (prompt, retrieval, structured constraints, guidance), the sampler will converge to the “most normal” completion compatible with the partial evidence.
    Independence and coarse corruption create blandness pressure: in the common discrete setup, tokens are corrupted independently with categorical distributions; this makes the reverse model’s job closer to denoising a bag of locally plausible tokens than constructing a globally novel plan. ACL 2025 flags the limitations of these discrete/continuous paradigms and motivates hybrids specifically because the naïve versions leave benefits on the table.
    Conditional long-text is where naïve noising breaks first: Findings NAACL 2025 reports prior discrete diffusion models “completely fail” on long abstractive summarization due to “incompatibility between the backbone architectures and the random noising process,” and they introduce semantic-aware noising to address it.
    This is the same phenomenon in your language: the corruption process can destroy the very structure you need to preserve to avoid falling back to generic manifold solutions.
    So: your disappointment is not a mystery; it is a predictable interaction between corruption design and conditioning strength.
    Yes—if you treat governance as a procedure over artifacts (inputs → outputs → certificates), not as a property of the generator.Runcible governance (as you’ve described it elsewhere) is essentially:
    • Contract-first (what must be produced, with what scope/limits),
    • Gate execution (decidability → truth/testifiability → judgment),
    • Certificate output (what was checked, what evidence supports it, what remains uncertain).
    None of that depends on autoregressive decoding. It depends on:
    • the ability to parse the output,
    • the ability to run validators (deterministic and/or adversarial),
    • the ability to loop/repair when validators fail,
    • the ability to log enough to audit.Diffusion changes the intervention surface, not the viability.
    You can govern diffusion in two non-exclusive ways:
    A) Post-hoc governance (model-agnostic; simplest; strongest auditability)
    • Generate candidate(s).
    • Validate against contracts (schemas, citations, invariants, consistency).
    • If fail: regenerate/repair with explicit failure reports.
    This works identically for AR LLMs, diffusion text models, expert systems, whatever.
    B) In-process governance (model-specific; higher leverage; harder to engineer)
    Diffusion gives you a natural iterative loop where you can inject constraints during denoising:
    • classifier(-free) guidance analogs exist for discrete diffusion, explicitly derived and evaluated in recent work.
    • “editability” is often easier: you can selectively re-noise/resample only the offending positions rather than rewriting an entire suffix (an AR pathology).
    In practice: implement A first (because it is architecture-invariant), then selectively add B for cost/latency and higher constraint satisfaction.
    This is one workable decomposition that preserves your decidability→truth→judgment hierarchy while respecting diffusion’s mechanics:
    Step 0 — Output Contract (Decidability precondition)
    Define an explicit contract that is checkable:
    • Structure: JSON/YAML schema, required fields, allowed enums.
    • Scope limits: what claims are allowed vs forbidden without evidence.
    • Evidence protocol: citation slots, data provenance requirements.
    • Invariants: e.g., “all numeric claims must be derivable from supplied sources or computations”; “no normative conclusion without stated trade-offs.”
    (If the contract is not checkable, governance is performative.)
    Run the diffusion model to produce k candidates:
    vary seed / temperature / guidance scale,
    optionally do constrained-token vocab for certain fields (dates, IDs, enums).
    Run validators that do not require “interpretation”:
    schema validation,
    forbidden-string / forbidden-claim patterns,
    internal consistency checks (references resolve, IDs consistent, units consistent),
    structural completeness.If diffusion is being used, you can add an     iterative structural repair mechanism: mask invalid spans and resample only those spans (diffusion-native edit loop).
    • retrieval verification (claims must map to retrieved passages),
    • citation coverage checks (every nontrivial empirical claim is cited),
    • contradiction checks (within document + against retrieved facts),
    • arithmetic checks.
    This is where you can use any model (including an AR verifier) without giving it authorship authority; it is simply an adversarial tool in the gate.
    If something cannot be decided mechanically:
    • force explicit uncertainty,
    • force explicit trade-offs,
    • output a bounded set of alternative actions and the costs of each.
    Emit a structured certificate:
    • which gates ran,
    • pass/fail per gate,
    • residual uncertainties,
    • provenance hashes (inputs, retrieval set, seeds, model version).
    This certificate is where “governability” becomes operational rather than reputational.
    Diffusion’s iterative refinement gives you a clean primitive:
    • Localized resampling: “these 12 tokens violate schema / contradict evidence; re-noise and resample only them.”
      AR decoding often forces suffix regeneration with cascading effects.
    • Constraint shaping via guidance: discrete diffusion has explicit guidance mechanisms analogous to classifier-free guidance.
    • Planning vs drift: AR methods can degrade via accumulated errors (“sampling drift”); diffusion is explicitly positioned as a non-autoregressive iterative denoising alternative to mitigate such error accumulation in some settings.
    So, if your governance layer is built around repair and adversarial testing, diffusion can be a more cooperative substrate than it first appears.
    • Conditioning brittleness: if the noising process destroys semantic anchors, the reverse process will “snap back” to generic manifold text. This is documented in long-text conditional generation failures under naïve noising/backbone choices.
    • Trace interpretability: intermediate denoising states are less semantically interpretable than AR token streams. You can log them, but they are not “reasons.” This pushes you toward “certificate-first” governance (external evidence + checks) rather than “introspective” governance.
    • Discrete/continuous mismatch: continuous latent diffusion requires a decoder; governance over tokens becomes indirect unless you add token-level constraints

      downstream.Net

      : diffusion is governable, but you should bias toward external procedural governance and treat in-process guidance as an optimization.

    1. Are you using diffusion primarily for (i) de novo long-form generation, (ii) constrained structured outputs, or (iii) editing/rewriting/infilling? (Diffusion tends to shine most in iii, sometimes ii, least reliably in i.)
    2. Does your governance require hard guarantees (schema correctness, citation coverage, bounded uncertainty), or is “best effort with audit trail” sufficient?
    3. Do you want the generator to also be the certifier, or are you comfortable with a split: diffusion proposes, separate verifier(s) certify?If you answer those, you can pick a clean pattern (pure post-hoc, hybrid proposer/verifier, or guided diffusion with constraint critics) and avoid the common trap: “try to make diffusion behave like an AR reasoner.”
    URLs (sources cited)

    https://papers.neurips.cc/paper/2021/file/958c530554f78bcd8e97125b70e6973d-Paper.pdf


    https://aclanthology.org/2025.acl-long.565.pdf


    https://aclanthology.org/2025.findings-naacl.352.pdf


    https://openreview.net/forum?id=i5MrJ6g5G1


    https://arxiv.org/html/2508.10995v1
    PROMPT:
    We’re a certifier. That’s our market position.
    RESPONSE
    If     certifier is the product, then the correct stance is:
    Generators are interchangeable, fallible proposers. Runcible is the certifying procedure and signature.
    Diffusion does not threaten that position; it reinforces it, because diffusion makes it more obvious that “generation” and “certification” are separable functions.
    If you sell certification, then you are selling three things, in order:
    • A contract language: what counts as “passes” is specified in machine-checkable terms.
    • A gate procedure: a deterministic + adversarial test pipeline that produces a verdict.
    • A certificate: an auditable artifact (hashes, provenance, checks performed, failures, uncertainty bounds) that can be relied upon downstream.
    Everything else is implementation detail.
    This implies a non-negotiable separation:
    • Proposer: any model/system that emits candidate text (LLM, diffusion, expert system, human, template, tool).
    • Certifier: Runcible pipeline that accepts/rejects/repairs and emits certificates.
    So diffusion-text governance becomes: How do we adapt the proposer interface and the repair loop? Not: Can diffusion “be governed”?
    You can keep your market position clean by defining three integration tiers:
    Inputs: prompt + contract + evidence bundle
    Outputs: candidate(s)Runcible does:
    validate structure,
    extract claims,
    map claims to evidence,
    run checks,
    accept/reject,
    request regeneration/repair.
    Diffusion fits here perfectly. You do not need internal access to steps, logits, or denoising states to certify.
    Adds: confidence metadata, token-level marginals (if available), or “which spans were most uncertain.”
    Runcible uses metadata to target repairs and reduce resampling volume.
    Some diffusion implementations can expose per-position uncertainty; some cannot. If they can, you harvest it; if not, remain Tier A.
    Adds: in-process constraints (guided sampling, constrained decoding, partial resampling)
    This is where diffusion’s iterative nature can help, but it is optional. Your certifier identity should not depend on it.
    Below is a certifier loop that treats any generator—including diffusion—as replaceable.
    You already do this. The key is to force checkability:
    • schema (JSON/YAML), required fields, enums, formats
    • scope limits and allowed claim types
    • evidence requirements per claim type (citation slots, provenance class)
    • invariants (numeracy, unit consistency, no orphan claims, etc.)
    If something cannot be checked, it must be forced into an explicit “undecidable/unknown” channel.
    Step 1 — Generate k candidates (parallel, architecture-agnostic)
    For diffusion, “k” matters more because variance can be higher under weak conditioning.
    Runcible selects candidates for downstream gating, not “the model’s favorite.”
    Step 2 — Deterministic gates (Decidability)
    These gates should be as non-interpretive as possible:
    • schema validation, formatting, completeness
    • forbidden constructs (unsupported claims, missing scopes)
    • internal consistency checks (IDs, references, units)
    • computable arithmetic checks where applicable
    Fail ⇒ trigger targeted repair request (see Step 5).
    Step 3 — Claim graph extraction (Truth precondition)
    Transform candidate text into a claim graph:
    • atomic claims (subject–predicate–object, numeric assertions, causal assertions)
    • dependency edges (claim A relies on claim B; conclusion relies on premises)
    • citation hooks (which evidence supports which claim)
    This is where certifier strength compounds: you are not “grading an essay”; you are certifying a structured set of commitments.
    Step 4 — Adversarial truth gates (Truth/testifiability)
    Run verification against provided and retrieved evidence:
    • citation coverage: every empirical claim has support
    • entailment/contradiction against evidence
    • cross-consistency with other claims in the output
    • adversarial query generation: “what evidence would refute this?” then check whether the system would have found it
    • boundary enforcement: anything beyond scope becomes “unknown” or “hypothesis”
    Important: if you use models here, they are tools inside the procedure, not the authority. The certificate must report what was checked and with what limits.
    Step 5 — Repair loop (diffusion is often strong here)
    Instead of “regenerate everything,” certify-driven repair works as:
    • locate failing spans / failing claims
    • request patches that satisfy specific failed gates
    • re-run gates only for affected regions + dependent claims
    • iterate until pass or declared undecidable
    Diffusion’s iterative/infilling nature can be an advantage: you can resample only the failing spans (when the proposer supports partial resampling). If not, you still do patching by prompting the proposer to rewrite only specified fields/spans.
    Step 6 — Certificate emission (the product)
    The certificate should contain:
    • contract version + hash
    • inputs + evidence bundle hashes
    • proposer identity (model, version, settings, seed(s) if available)
    • gate results: pass/fail + diagnostics
    • unresolved uncertainties: explicitly bounded
    • final verdict class: Certified / Certified-with-Exceptions / Not-Certifiable
    • signature (your key), timestamp, replay token
    This is the differentiator: customers integrate the certificate into workflow and liability, not “the model output.”
    Diffusion mostly changes three operational parameters:
    • Sampling strategy: you will often want more parallel candidates (k) at lower per-sample cost.
    • Repair granularity: diffusion-friendly proposers can patch localized spans efficiently; design your certifier to exploit that when available.
    • Conditioning discipline: diffusion-text can drift toward “manifold typicality” when conditioning is weak. Countermeasure is not philosophical; it is procedural: increase evidence conditioning, increase constraint strength, and tighten scope.
    None of these change your certifier identity. They change throughput economics.
    Your strongest market posture is:
    • “We certify outputs under contracts, independent of generator architecture.”
    • “We can certify diffusion, LLMs, tool-augmented systems, and humans—because certification is a procedure.”
    That implies a commercial packaging:
    • Runcible Certified Output API: input (task + contract + evidence) → output + certificate
    • Certificate Verification API: certificate → valid/invalid + audit trail
    • Governance Ledger: store certificates for downstream dispute resolution / warrantyThis turns “certifier” into an infrastructure primitive rather than a model feature.
    • Certificate semantics: Is “Certified” a binary, or do you sell tiers (e.g., Structural Certified, Factual Certified, Decision Certified)?
      My recommendation: tier it, because it maps to cost and to liability.
    • Undecidability handling: Do you force abstention, or allow certified outputs with explicit uncertainty bounds?
      My recommendation: allow certification with exceptions, but require the exceptions to be machine-readable and signed.
    When you say “certifier,” which domain is your first high-value wedge: (i) legal/compliance, (ii) medical/clinical, (iii) finance/accounting, or (iv) enterprise internal controls?
    The reason this is necessary: the contract primitives (what is decidable, what evidence counts, what exceptions are allowed) are domain-shaped, even if the certification procedure is universal.
    PROMPT
    Well, we do all of them. We create domain specific protocols. In fact, we have almost 40 markets defined. This is why we prefer very large parameter models – so we have the most data to work with. And you’re able to produce the protocols if you have our books (volumes) and our existing code base. You just need us to help you incrementally expand your abilities.
    RESPONSE
    If you are certifier-first across ~40 verticals, then the correct scaling move is to treat “domain protocols” as overlays on a small, stable kernel, and treat “large parameter models” as proposal engines whose only job is to reduce authoring cost—not to supply warrant.
    In causal terms:
    • Multi-domain coverage is contingent upon a universal certification grammar (kernel) that is necessary for commensurability across domains.
    • Large parameter models are useful insofar as they are sufficient to draft plausible candidates quickly, but they are neither necessary nor sufficient for certification; certification is contingent upon evidence discipline + gates + certificates.
    Kernel (immutable-ish):
    • Output Contract primitives (schema, scope, claim taxonomy hooks)
    • Gate semantics (Decidability → Truth → Judgment)
    • Certificate schema + signing + ledger semantics
    • Generic validators (schema, numeracy, internal consistency, provenance, citation coverage, contradiction detection, uncertainty bounding)
    • Repair loop semantics (patch targeting, dependency re-check)
    Domain overlay (mutable; many):
    • Claim types and subtypes (what counts as a “claim” in that domain)
    • Evidence registry (acceptable sources, hierarchy, provenance classes)
    • Gate mapping (which claims require which evidence / which checks)
    • Risk tiers (severity × population × time horizon) → required infallibility demand
    • Domain-specific calculi (e.g., dosage rules, accounting identities, legal elements tests)
    This decomposition is what prevents “40 markets” from becoming “40 bespoke systems.”
    Your certifier layer should define a single proposer interface:
    • propose(contract, evidence_bundle, context) -> candidates[]
    • optional: patch(contract, evidence_bundle, failing_spans, failing_claims) -> patches[]
    An autoregressive LLM, a discrete text diffusion model, an expert system, or a human can all satisfy that interface. Your certification kernel remains identical; only proposer adapters differ.
    Diffusion can become advantageous specifically in the patch mode (localized resampling), but you should treat that as an optimization, not a dependency.
    Your stated preference—“very large parameter models so we have the most data to work with”—is directionally correct for drafting breadth, but certification strength does not come from “more priors,” it comes from binding outputs to evidence under procedure.
    A high-leverage posture is:
    • Use large models to draft: contracts, candidate outputs, candidate claim graphs, candidate gate mappings, candidate test cases.
    • Use Runcible to bind: every nontrivial claim to evidence or to an explicit uncertainty bucket, with logged checks.
    This makes your product resilient to model churn: when the underlying model changes, your certificates do not become epistemically invalid; at worst your authoring efficiency fluctuates.
    To industrialize domain protocol creation, you want a repeatable pipeline that produces three artifacts per domain: (a) overlay spec, (b) test vectors, (c) certificate exemplars.
    A workable factory loop:
    • Domain charter (1 page)
      Purpose, actors, decision surfaces, harm surfaces, “what must never be asserted without evidence,” risk tiering.
    • Claim taxonomy (tight)
      Enumerate claim types that matter (diagnostic, prognostic, causal, legal-element, compliance, financial-statement, valuation, etc.).
      Each claim type gets: required fields, allowed modalities (fact/hypothesis/plan), allowed scope.
    • Evidence hierarchy + admissibility rules
      What sources count, in what order, with what staleness limits, with what jurisdiction/time constraints.
    • Gate mapping table
      For each claim type: which validators run, what constitutes pass/fail/undecidable, what is the required restitution path.
    • Repair strategies
      For each failure signature: “patch this span,” “downgrade modality,” “add evidence,” “narrow scope,” “abstain.”
    • Test suite generation
      golden-pass cases
      golden-fail cases (missing evidence, contradictions, out-of-scope claims)
      adversarial cases (prompt injection, citation laundering, numeracy traps)
    • Certificate exemplars
      “Certified,” “Certified-with-Exceptions,” “Not-Certifiable,” with realistic diagnostics.
    • Regression harness + lint
      Every protocol change must re-run domain tests and cross-domain invariants (so one vertical can’t quietly break kernel semantics).
    This is how you avoid bespoke drift and keep protocol authoring “incrementally teachable.”
    Given your constraint environment (file-count limits, S3-backed store, etc.), the minimal “ability expansion” package is not the whole corpus; it is the indices and exemplars that anchor the grammar.
    High-yield inputs:
    • Kernel protocol registry + current kernel gate definitions (the canonical source of truth)
    • Two mature domain overlays (one legal/compliance, one quantitative like finance/medical)
    • One end-to-end certificate per overlay (pass + fail)
    • Your canonical claim taxonomy (even if incomplete)
    • A short excerpt from the books that defines: decidability, truth/testifiability dimensions, liability tiering, and “demonstrated interests” mapping into certification
    With those, I can produce:
    • new overlay drafts for additional markets,
    • consistent gate mappings,
    • test suites,
    • and diffs that remain commensurable with your kernel.
    Adopt a strict rule:
    No domain protocol may introduce new gate semantics.
    Domains may only (a) select gates, (b) parameterize thresholds, (c) define admissible evidence, (d) define claim types and schemas.
    This is the necessary constraint that keeps 40 markets from becoming 40 incompatible “certifiers.

    Source date (UTC): 2026-01-12 21:18:43 UTC

    Original post: https://x.com/i/articles/2010823782605496609

  • (Runcible) –“We can not only save the truth verdicts that runcible issues, but

    (Runcible)
    –“We can not only save the truth verdicts that runcible issues, but we can save the false verdicts and train the AI to identify and explain the error that the user is making.” — Luke Wienhagen (
    @LukeWeinhagen
    )

    Source date (UTC): 2026-01-06 19:24:31 UTC

    Original post: https://twitter.com/i/web/status/2008620716120236370

  • (RUNCIBLE UPDATE – RDL CONTINUED) We created the first pass at Runcible Reality

    (RUNCIBLE UPDATE – RDL CONTINUED)
    We created the first pass at Runcible Reality Description Language (RDL). But what does that mean?

    Think of the evolutionary sequences of:

    … 1) Transduction: Receptor state changes > Neural Signals., change in chemical composition, deformation, pressure, temperature, harm, movement, sound, light, smell, taste, etc.
    … 2) Vibration (intensity): Frequency and Duration in time: All nerves and neurons, meaning all senses, detect vibration of somethig whether a single pulse or many pulses in time.
    … 2) Disambiguation (Difference): Identity, category, (sense perception reduction)
    … 3) Stabilization (consistency): Identity. Category.
    … 4) Indexing: Ordering. Humans rely on natural indexing both experientially and verbally. Ordinal and cardinal indices compensate for the limit of natural indexing (usual five to seven states).
    … 5) Dimension: an axis of variation enabling ordering/equivalence – by reference. A dimension can consist of a single causal axis or multiple causal axis that vary by the same order.
    … 6) Reference: (name, term, label). The name of an identity, category, dimension or a position on a dimension.
    … 7) Measure (operationalization): procedures mapping observations to values on dimensions
    … 8) Commensurability: Subjectivity and Intersubjectivity: internal and external commensurability both personal and interpersonal by use of names (symbols, words, language)
    … 9) Paradigm: A set of dimensions sufficient for measurement of multiple dimensions of causality in some subset of experience whether direct by senses or instrumental by measurements.
    … 10) Grammar: The rules of continuous recursive disambiguation, comparison and judgement within a paradigm, consisting of the sequence embodiment > narration > mythology > philosophy > empiricism > science > operationalism
    … 11) Measurement Systems: counting, accounting, bayesian accounting, neural network accounting
    … 12) Reducibility: (expressibility) of Complexity: Mathematical Reducibility > Programmatic Reducibility > Operational Reducibility > Verbal Reducibility > Artificial Neural Network Reducibility
    … 14) Proceduralization: Recording > Writing > Recipes > Instructions > Protocols > Formulae > Sequential Programming > Functional Programming > Object Oriented Programming > Reality Description Language (RDL)
    … 15) Closure: Intuitive/Embodied Closure: Basic survival-based instincts or heuristics (e.g., immediate sensory feedback or trial-and-error in pre-literate societies), providing rudimentary decidability without formal structure. > Logical Closure: Affirmative justification through internal consistency (aligning with early philosophy or positiva tests), but vulnerable to unfalsifiable assumptions. > Empirical Closure: Falsification via external correspondence (e.g., scientific method), adding verifiability but still limited to observable phenomena. > Operational Closure: Constructive procedures that demand actionable, repeatable steps (e.g., operationalism), ensuring computability but potentially ignoring ethics or reciprocity. > Reciprocal/Adversarial Closure: Full integration of necessity, sufficiency, reciprocity/symmetry, and coherence under adversarial testing, yielding auditable, ethical, and liability-enforcing decisions (as in RDL and Runcible’s “closure layer”).
    … 16) Tests: Justification (Positiva) > Falsification (Negativa) > Adversarialism (constructive logic positiva and empirical correspondence negativa): the recognition that all logic is falsificationary: Darwinian survival of negative testing. Why? …

    –“RDL is an operational grammar, reliant on adversarial survival, by both operational construction and empirical correspondence, for testing the computability, ethics, and testifiability of any statement in human language.”–

    RDL Formalized our work in a way that closed the gaps in LLM computability due to its tendency to drift. This is revolutionary in no small part because until we solved the method and the grammars it was thought not possible.

    Cheers

    Source date (UTC): 2025-12-24 01:44:51 UTC

    Original post: https://twitter.com/i/web/status/2003642997460881675

  • (Runcible Update) Today we created the first pass at Runcible Reality Descriptio

    (Runcible Update)
    Today we created the first pass at Runcible Reality Description Language (RDL). But what does that mean?

    Think of the evolutionary sequences of:

    … 0) Grammars of Paradigms: embodiment > narration > mythology > philosophy > empiricism > science > operationalism

    … 1) Reduction (expressibility): Mathematical Reducibility > Programmatic Reducibility > Operational Reducibility > Verbal Reducibility > Artificial Neural Network Reducibility

    … 2) Closure: Intuitive/Embodied Closure: Basic survival-based instincts or heuristics (e.g., immediate sensory feedback or trial-and-error in pre-literate societies), providing rudimentary decidability without formal structure. > Logical Closure: Affirmative justification through internal consistency (aligning with early philosophy or positiva tests), but vulnerable to unfalsifiable assumptions. > Empirical Closure: Falsification via external correspondence (e.g., scientific method), adding verifiability but still limited to observable phenomena. > Operational Closure: Constructive procedures that demand actionable, repeatable steps (e.g., operationalism), ensuring computability but potentially ignoring ethics or reciprocity. > Reciprocal/Adversarial Closure: Full integration of necessity, sufficiency, reciprocity/symmetry, and coherence under adversarial testing, yielding auditable, ethical, and liability-enforcing decisions (as in RDL and Runcible’s “closure layer”).

    … 3) Tests: Justification (Positiva) > Falsification (Negativa) > Adversarialism (constructive logic and empirical correspondence)

    … 4) Programming: Sequential Programming > Functional Programming > Object Oriented Programming > Reality Description Language (RDL)

    “RDL is an operational grammar, reliant on adversarial survival, by both operational construction and empirical correspondence, for testing the computability, ethics, and testifiability of any statement in human language.”–
    RDL Formalized our work in a way that closed the gaps in LLM computability due to it’s tendency to drift.
    This is revolutionary in no small part because until we solved the method and the grammars it was thought not possible.

    Cheers

    Source date (UTC): 2025-12-21 23:29:27 UTC

    Original post: https://twitter.com/i/web/status/2002884149854752989

  • (Runcible Update) Today we created the first pass at Runcible Reality Descriptio

    (Runcible Update)
    Today we created the first pass at Runcible Reality Description Language (RDL). But what does that mean?

    Think of the evolutionary sequences of:

    … 0) Grammars: embodiment > narration > mythology > philosophy > empiricism > science > operationalism

    … 2) Reduction (expressability): Mathematical Reducibility > Programmatic Reducibility > Operational Reducibility > Verbal Reducibility > Artificial Neural Network Reducibility

    … 1) Tests: Justification (Positiva) > Falsification (Negativa) > Adversarialism (constructive logic and empirical correspondence)

    … 3) Programming: Sequential Programming > Functional Programming > Object Oriented Programming > Reality Description Language (RDL)

    –“RDL is an operational grammar, reliant on adversarial survival, by both operational construction and empirical correspondence, for testing the computability, ethics, and testifiability of any statement in human language.”–

    RDL Formalized our work in a way that closed the gaps in LLM computability due to it’s tendency to drift.

    This is revolutionary in no small part because until we solved the method and the grammars it was thought not possible.

    Cheers

    Source date (UTC): 2025-12-21 22:15:09 UTC

    Original post: https://twitter.com/i/web/status/2002865449474859158

  • (RUNCIBLE) Had a wonderful conversation with a DC insider this morning about Run

    (RUNCIBLE)
    Had a wonderful conversation with a DC insider this morning about Runcible, thanks to our own Josh Reider.

    I used a different story to explain why our Runcible governance layer works so absurdly well. I didn’t think the story would work, but apparently it’s intuitive enough for those at least vaguely familiar with the industry to understand.

    |Reducibility|: Mathematical < Programmatic < Verbal < Neural(bayesian).

    This framework allows me to explain why neural reducibility is so much larger than verbal, programmatic, and mathematical, without information loss. It also allows me to explain why neural reducibility is so much more powerful than what is accessible to humans. We humans simply can’t do it.

    If only humans were taught category theory in high school … (sarcasm). 😉

    Source date (UTC): 2025-12-15 20:53:32 UTC

    Original post: https://twitter.com/i/web/status/2000670583110164532