Runcible: what is built, what is not, and what capital changes
Prepared 29 July 2026 from direct inspection of the production systems and source repositories rather than from status documents. Every figure below is countable, and the underlying artifacts are available for technical diligence.
| 83 | 672 | 2 of 10 | 507,554 | 1 |
| Protocol releases compiled and schema-validated | Runcible Oversing routes live in production today | Volumes substantially complete | Words of source material compiled into the system | Working Runcible AI–Runcible Oversing deployment |
The position in four sentences
The qualification core of Runcible AI is built and running: a governed protocol runtime with 29 verdict blocks, a validating compiler, 83 released versions, and a deployed gateway that enforces the contract on every request and fails closed when it cannot.
Runcible Oversing is also built and in production: 236 tables and 672 routes of institutional structure serving live users. Runcible AI and Runcible Oversing are already joined by a working orchestrator in one deployment.
What remains incomplete is equally specific: corpus coverage beyond the first volumes, productization of the joined system, migration of Runcible Oversing to a current framework, and the operating capacity required for repeatable partner-led deployment.
The company remains founder-dependent and lacks mature release engineering, partner engineering, support, and commercial functions. Those operating constraints—not an absence of working technology—are what capital is intended to change.
Completeness percentages are our own judgment against each component’s finished-state definition, with the supporting counts shown beside them. Layer figures are unweighted means of their components; read them as shape rather than measurement.
Where the five layers stand
The pattern is the argument. The tall bar is the part that is hard to copy and already finished. The short bars are the parts that people and money buy.
Estimated completion by layer
Axes: layer (vertical) by estimated completion in percent (horizontal, 0–100). Source: direct inspection of production systems and repositories, 29 July 2026.
Layer 1 — Runcible AI, as it runs today
A governed protocol runtime, a deployed gateway, the cloud services behind it, and a controlled hosted model. This is a working system with a real release pipeline. Its weakness is not capability. It is that verification runs on demand rather than automatically, so the system currently depends on one operator.
Built and running (≥75%) Partial (45–74%) Early (20–44%) Outstanding (<20%)
| Component | State | Complete | What exists today |
|---|---|---|---|
| Protocol contract layer | Production | 90% | 11 contracts totalling 2,558 lines. The output contract runs to 1,065 lines at schema version 1.4; the verdict rules cover 29 protocol blocks and 4 scoring tracks. Four result contracts remain in draft. |
| Compiled protocol runtime | Production | 85% | 3,546 lines of authored protocol expand into a 10,392-line machine runtime across 22 canonical protocols. |
| Compiler and release pipeline | Production | 90% | Build, verify, release, diff and deploy stages with content hashes and schema gates that stop a bad release rather than warning about it. 83 releases produced to date; the current one validates with zero errors and zero warnings. |
| Gateway (AWS Lambda) | Production | 80% | 22,369 lines and roughly 100 components. Enforces the contract on every request, repairs and retries non-conforming output, and fails closed when it cannot. Monolithic, and instrumented with logs rather than metrics. |
| Hosted model layer | Production, with a manual publish step | 75% | 22 versioned knowledge packs with scripted file and index synchronisation. The final publish is still pasted into a vendor dashboard by hand, which is the single manual step in an otherwise automated pipeline. |
| Chat interface | Working, hardening in progress | 68% | 978-line plugin and 2,940-line client with streaming, telemetry and a command composer. Output sanitisation was rebuilt to fail closed on 29 July with a 9-check regression test. Responsive layout and accessibility work remain. |
| Automated verification | Strong where it exists | 70% | A 2,623-line deterministic contract verifier carrying roughly 100 assertions, currently passing 31 of 31 gates, plus 11 live smoke scripts and a five-mode live matrix. |
| Continuous integration and infrastructure as code | Not built | 15% | Verification is comprehensive but runs on demand rather than on every change, and the production environment is configured directly rather than defined in code. This is the first use of proceeds. |
Layer 2 — The corpus and industry coverage
The corpus is what gives the engine something worth adjudicating, and it is the most uneven part of the estate. Two volumes carry most of the weight.
Source material compiled into the system, by volume (thousands of words)
Axes: volume (vertical) by thousands of words of retrieval-ready text compiled into the shipping system (horizontal). Volumes 4 and 6 through 10 are scoped but unwritten.
| Component | State | Complete | What exists today |
|---|---|---|---|
| Volume 1 — Crisis of the Age | Substantially complete | 90% | 285,724 words compiled into the retrieval layer from a manuscript at its eleventh revision. |
| Volume 2 — System of Measurement | Substantially complete | 85% | 150,412 words compiled, against a manuscript of roughly 150,000 words. |
| Volume 3 — Evolutionary Computation | In progress | 55% | 49,277 words compiled against a manuscript of roughly 141,000. Two sections remain unwritten. |
| Volume 4 — Behavior | Outstanding | 5% | Not yet written. It is load-bearing under both the law and health protocols, which makes it the one dependency on this list that funding cannot shorten. |
| Volume 5 — Law | Early draft | 30% | 22,141 words compiled — the thinnest of the four volumes now shipping, while law is the lead industry. |
| Volumes 6 through 10 | Not started | 0% | Scoped and placeheld. Not required for the industries we intend to sell into first. |
| Industry protocols | Mechanism proven, coverage thin | 30% | Five industry namespaces exist. Health is deepest, with 38 files including a medical evidence adapter and four industry contracts; law carries a registry and 12 test vectors. Defense and curation are scaffolding. |
| Client protocols | Scaffolding only | 10% | One worked example client, built to prove the compile and release path end to end. Intended to be produced by integrators rather than by us. |
Volume 4 is a dependency, not an item on a list
Behavior sits underneath both law and health, so its absence caps how deep any industry protocol can go. That is why health currently stops at an evidence adapter and law stops at test vectors. Against the full ten-volume scope the corpus is about 38 percent complete; against the volumes the runtime actually loads, about 53 percent. We are naming this in the first pages because it is the one dependency on the critical path that money cannot shorten.
Layer 3 — Runcible Oversing
Runcible Oversing is the institutional platform and complex episodic memory through which Runcible AI works. It already contains 236 tables and 672 routes covering structure, workflow, finance, people, permissions, documents, and history in production today. The constraints are its end-of-life runtime and the fact that the joined product has been proven in one deployment rather than generalized.
| Component | State | Complete | What exists today |
|---|---|---|---|
| Production application | Live, on an end-of-life runtime | 85% | Serving users today. 236 database tables, 672 routes, 127 controllers, 221 models and 812 views — roughly 195,000 lines of application code. The framework and language version underneath are past end of life. |
| In-product help content | Built | 60% | 221 published help topics, plus an 8-chapter guide with 223 images. Public publication still pending. |
| Multi-tenant provisioning | Partial | 50% | Instance licensing and provisioning work. Domain and certificate automation remain open. |
| Runcible AI–Runcible Oversing integration | Working in one deployment | 45% | Nine libraries, an orchestrator and a user-facing panel, governed by permission parity and explicit authority boundaries. Proven in one production tree, not yet generalized across all three. |
| Migration to a current framework | Early harness | 10% | Test discipline is strong — 88 test files, 598 tests and 8,367 assertions passing under continuous integration. Coverage is the constraint: roughly 15 to 20 of 672 routes have been moved, or 2 to 3 percent of the surface. |
Why this matters commercially
Runcible AI can do more than advise because Runcible Oversing supplies institutional context, permissions, workflow, operating state, consequence, and memory. Human validation is the default for consequential decisions and actions. Where authority is explicitly delegated, Runcible AI can decide and act only within the defined permissions, scope, conditions, and escalation rules.
Layer 4 — Longer-term technical layers not yet built
These items are strategically valuable but are not prerequisites for the current Runcible AI and Runcible Oversing offering. The implemented semantics work today; a written language, portable corpus, proprietary model, and mature training pipeline remain future product options.
| Component | State | Complete | What exists today |
|---|---|---|---|
| Adjudication semantics | Built and enforced | 70% | Ternary logic, decidability tests, the closure ladder, burden classes, warranty and liability gates and 29 verdict blocks are implemented as validated contracts and enforced on every production request. This is the substance a language would express. |
| RDL as a written notation | Not built | 10% | Reality Description Language is how a claim is expressed so that a machine can test it. No grammar, parser or compiler exists. Writing one would formalize semantics already implemented in the runtime, but design and validation remain. |
| Proprietary foundation model | Not started; optional | 0% | Runcible AI governs hosted models today. A proprietary model could offer control or margin advantages later, but it is not required for the current product, first revenue, or model-provider distribution. |
| Training and evaluation pipeline | Not started | 0% | A proprietary-model training pipeline is not part of the current release. Product and protocol evaluation already exist in narrower forms. |
| Corpus portability | Not started | 0% | The corpus is currently bound to one hosted retrieval index. Provider abstraction and portable indexing can reduce that concentration without requiring Runcible to build a foundation model. |
| Hypothesis-engine architecture | Working prototype | 15% | The claim to ledger to obligations to verifier path is implemented across 17 modules against a simulated model, establishing the design for treating a general model as a hypothesis generator rather than an authority. |
The semantics run; the language does not exist yet
Everything RDL is meant to express is already implemented and enforced on live traffic: verdict enumerations, gate conditions, the closure ladder, burden classes and ternary outcomes. What does not exist is RDL as a notation a person writes — no grammar, no parser, no compiler.
RDL version zero would give a written surface to semantics already implemented in the runtime. That narrows the problem, but grammar, parser, compiler, and independent validation still have to be designed and built. Model-provider distribution may not require RDL first: Runcible AI could also be integrated as a qualified expert within a provider’s expert fleet.
Layer 5 — Company and go-to-market
This layer has an unusual shape. Founder-led research, working products, technical evidence, and substantial market materials exist. The thin areas are repeatable release operations, partner implementation, enablement, support, and commercial execution.
| Component | State | Complete | What exists today |
|---|---|---|---|
| Market-facing site | Live and actively maintained | 75% | 39 public pages under an enforced structural standard, edited within the last 24 hours. |
| Investor and partner portal | Built | 65% | A four-layer structure carrying 18 memo pages and four decks. Document bodies are being brought up to current. |
| End-user help content | Substantial | 55% | 221 topics plus technical and non-technical instruction sheets. |
| Controlled terminology | In progress | 35% | A term dictionary with owner-approved definitions, applied across public pages under measurement rather than impression. |
| Video and demonstration content | Production planning complete | 15% | Investor script and production direction are approved; current product captures, narration, and final production remain. |
| Pricing and coupled-product licensing | Not started | 5% | To be established with the first capable implementation partner rather than asserted in advance. |
| Partner implementation and enablement | Scaffolding only | 10% | The extension mechanism works. What does not yet exist is a capable launch partner, a repeatable implementation method, or partner enablement capacity. This is a primary use of capital. |
| Customer support function | Not started | 0% | No tooling, escalation path, or service commitments. |
| Sales and partner-development function | Not started | 0% | Materials exist. There is no repeatable pipeline or channel-development function. |
| Release engineering function | Not started | 0% | Every release currently requires the founder plus one manual publish step. This is the binding constraint on all of the above, including our ability to absorb new engineers. |
| Integrator program | Not started | 0% | No partner selection, enablement, support, or commercial structure yet exists, against a client-protocol path that already compiles. |
Sequence and use of proceeds
Ordered by how much downstream work each item releases. The column that matters is the last one, because it separates what capital solves from what it cannot.
| Gate | What it releases | How it is resolved | |
|---|---|---|---|
| 1 | Release engineering: automated verification, infrastructure as code, automated publish | Everything else. A release currently needs the founder plus a manual publish step, which caps the company at one operator and means a new engineer cannot safely ship. | One senior platform engineer. |
| 2 | Bring production governance current and clear the open live failures | A demonstration that needs no narration, and a technical diligence we pass rather than survive. | The same hire, first month. |
| 3 | Recruit and implement inside one capable consulting or systems-integration partner | Revenue evidence, internal operating proof, implementation skill, and a credible distribution channel. | Founder-led partner recruitment supported by solutions and partner engineering. |
| 4 | Generalize the Runcible AI–Runcible Oversing integration | Repeatable deployment beyond the one production tree in which the joined system currently works. | Partner implementation plus product and solutions engineering. |
| 5 | Partner enablement and reusable protocol delivery | Industry and client coverage in parallel through organizations already equipped to implement complex systems. | A primary use of proceeds; scales through partner capacity and reusable patterns. |
| 6 | Runcible Oversing onto a current runtime | Enterprise and public-sector procurement, which fails on an end-of-life runtime regardless of product quality. | Engineering hire. Scoped incrementally, not as a rewrite. |
| 7 | Volume 4, RDL formalization, portability, and model-provider integration | Deeper industry coverage and strategic distribution options beyond the initial partner motion. | Sequenced by dependency and evidence; valuable, but not all required for first revenue. |
Known engineering debt
Disclosed here because a technical diligence will find all of it, and because the cost of clearing each item is small relative to what it currently blocks.
| Item | Consequence if not cleared | Cost to clear |
|---|---|---|
| No automated verification gate or infrastructure definition | Comprehensive tests exist but run when a person remembers, and the production environment is not reproducible from source. Together these cap the company at a single operator. | Weeks, one engineer |
| Deployed governance lags current source | The live protocol store is behind the repository, so production does not yet reflect the newest protocol work. It is a publish step, not a defect, but it constrains what we demonstrate. | Hours, one release |
| Runcible Oversing runtime past end of life | Fails enterprise and government security review on sight, independent of product quality. | Months, scoped incrementally |
| One manual step in the release pipeline | The final publish to the hosted model is a dashboard paste, which is the only unautomated link in an otherwise gated chain. | Days |
| Dependency on a hosted model and its retrieval index | Concentration risk on a third party for both inference and corpus binding. Mitigated, not eliminated, by protocol-level governance that would transfer to another model. | Reduced through portability and provider diversification |
Capital converts integrated proof into repeatable execution
Runcible has crossed from theory into integrated proof. The qualification core of Runcible AI runs, Runcible Oversing operates in production, and the two work together in one deployment. Capital funds the work required to harden, generalize, implement, support, and distribute that foundation.
That distinction is the investment case: substantial technical and intellectual depth already exists, while commercial proof and repeatable execution remain to be built.
Runcible was built from source truth outward
Many AI products begin with an interface around a model and search for durable differentiation afterward. Runcible began with the underlying research, semantics, protocols, and institutional model before building the runtime and product surfaces.
We built from the source down. Twenty years of research produced the books. The books produced the protocols — the explicit rules that decide whether a claim survives testing. The protocols produced the code, which does nothing but enforce them. Every layer is a formalization of the layer above it.
This is the present source of differentiation. The system is backed by 507,554 words of source material compiled into the runtime, implemented semantics, versioned protocols, and an institutional platform. Those assets do not make competition impossible, but they make the position materially more difficult to reproduce than an interface or prompt layer alone.
How the company is built, and what remains
Depth exists. Productization and distribution remain.
Read the diagram left to right and it splits in two, and the two halves respond to money in opposite ways.
The chain: research, books, protocols, runtime
Partly sequential. Research, corpus, protocols, and runtime constrain what can be implemented next. Some founder-authored dependencies cannot be compressed simply by hiring, but substantial implemented depth already supports product and partner work now.
The fan-out: industry protocols, client protocols
Parallel and partner-led. Consulting firms and systems integrators can use the products internally, develop implementation skill, and create industry and client protocols without modifying the core. This is where partner capacity turns the implemented foundation into repeatable deployment.
What this means for the use of proceeds
Capital does not replace the founder-authored dependencies that remain. It removes the single-operator release constraint, hardens the joined products, recruits and enables capable implementation partners, and multiplies the number of organizations and matters the system can serve. The 30 percent and 10 percent figures for industry and client protocols measure that remaining coverage opportunity, not completion of the whole product.
The fan-out is not a plan. It already runs.
The usual risk with a claim like this is that the extension mechanism is a diagram rather than a product. Ours is in the build system. The compiler treats an industry or a client as a separate profile: it compiles, validates, versions and ships each one independently of the core, with its own release identity.
For example, the health protocol adds a medical evidence adapter and four industry-specific contracts without altering a single line of the core system. Of 83 validated releases to date, 56 were industry, client, or combined profiles rather than core — the extension path has been exercised more often than the thing it extends.
Validated releases by profile
Count of compiled, schema-validated releases by profile type, to 29 July 2026. Core is 27 of 83; the remaining 56 are industry, client, or combined profiles.
So the mechanism is proven and the coverage is thin, and those two facts are the whole opportunity. We are not asking a consulting firm to trust that client-specific work is possible. We can show it compiled and validated 56 times. Partners extend the system along a supported path, which means the services business does not have to be ours.
Those protocols operate through Runcible Oversing, the second product in the coupled offering. Its 236 tables and 672 routes supply organizational context, authority, workflow, operating state, consequence, and memory. Runcible Oversing is not offered without Runcible AI; together they turn qualified intelligence into accountable institutional capability.
What we are asking for
Funding to convert an integrated foundation into repeatable partner-led execution: release engineering that removes the founder from every shipment, product and security hardening, one referenceable implementation inside a capable partner, partner engineering and enablement, reusable protocols, and the support capacity required for client deployment.
The next step is a working-system walkthrough and technical diligence, where the runtime, protocol contracts, Runcible Oversing application, integration, and release record are open for inspection. From there, the commercial objective is to select a capable implementation partner and test the joined products on bounded, measurable institutional matters.
Method
How these figures were produced
Assessed 29 July 2026 by direct inspection of the production systems and their source repositories, not from internal status documents. Where a status document disagreed with the artifacts, the artifacts were taken as authoritative. Counts of files, lines, tables, routes, releases and words are machine-derived and reproducible on request.
Completeness percentages are judgment against each component’s own finished-state definition, with the supporting counts shown beside every row. Layer figures are unweighted means and are therefore sensitive to how components are divided. The corpus is the clearest example: 38 percent against the full ten-volume scope, 53 percent against the volumes the runtime actually loads. Where a single number would imply more precision than the evidence supports, a range is given.
Live pass and fail states are taken from recorded verification artifacts rather than runs performed for this document. Deterministic contract verification was re-run on 29 July and passed 31 of 31 gates.