How Runcible Works

From AI Output to Institutional Action

Runcible does not begin with a prompt and end with an answer.

It begins with institutional work and ends with an action state.

A request, document, claim, recommendation, policy question, case file, contract, or proposed action enters the system. Runcible converts it into operational form, generates or receives candidate hypotheses, tests them against explicit constraints, emits diagnostics, assigns an action state, and preserves the result in a Decidability Record.

Foundation models generate candidate language.
Runcible determines whether that language can become institutional action.

Oversing provides the governed work surface where that action can be assigned, reviewed, escalated, recorded, and reused.

The model proposes. Runcible tests. Oversing routes. The Decidability Record preserves.

Figure 1:
The Runcible runtime workflow: institutional work enters the system; foundation models generate candidate hypotheses; Runcible applies RDL, ontology, protocols, evidence, authority, and liability constraints; the result becomes a certified, repaired, escalated, blocked, or undecidable action state preserved in a Decidability Record.

The Workflow at a Glance

Runcible works by moving institutional language through a sequence of qualification steps.

Intake the matter.
Define the role and scope.
Translate ordinary language into operational prose.
Generate or receive candidate hypotheses.
Bind the candidates to RDL, ontology, evidence, authority, and protocol constraints.
Test identity, consistency, evidence, possibility, reciprocity, authority, liability, and decidability.
Emit diagnostics.
Assign an action state.
Produce a Decidability Record.
Route the result into Oversing or the institution’s system of record.

This sequence turns AI from a conversational assistant into a governed participant in institutional work.

1. Intake the Matter

Runcible begins with work, not with a prompt.

The input may be a question, document, recommendation, policy, case file, contract, regulation, workflow state, proposed action, or institutional decision. In ordinary AI systems, this input would usually be treated as conversational context. In Runcible, it is treated as candidate institutional work.

That distinction matters.

A conversation may tolerate uncertainty, ambiguity, inference, and style. Institutional action cannot. Institutions must know what was asked, who had authority, what evidence applied, what rule governed the matter, what liability was created, and whether the result can be defended.

Runcible therefore begins by asking:

What kind of work is this?

Who or what role is performing it?

What authority governs it?

What evidence is available?

What rule, policy, law, contract, or protocol applies?

What action may follow?

What must be escalated?

What remains undecidable?

2. Define the Role and Scope

Runcible does not allow AI to act as an unbounded assistant.

Every governed workflow begins by defining role and scope. The system identifies what the AI is allowed to do, what it may examine, what it may infer, what it may recommend, what it may certify, what it must refuse, and what it must escalate.

A role may include:

permitted tasks,
prohibited tasks,
evidence boundaries,
authority limits,
jurisdictional limits,
review requirements,
escalation paths,
liability boundaries,
and recordkeeping obligations.

This prevents the AI from silently moving between functions: analyst, advocate, advisor, reviewer, approver, agent, or authority.

Runcible treats these as different institutional roles because each role carries different permissions, duties, and liabilities.

3. Translate Language Into Operational Prose

Ordinary language is powerful because it compresses meaning.

Institutional language is dangerous for the same reason.

A sentence may sound clear while hiding ambiguity in its actor, action, object, referent, authority, evidence, consequence, or liability. A fluent answer may conceal missing evidence, undefined terms, unsupported causality, impossible operations, unauthorized action, or unbounded risk.

Runcible therefore translates ordinary language into operational prose.

Operational prose identifies:

actors,
actions,
objects,
claims,
terms,
referents,
evidence,
rules,
conditions,
exceptions,
authorities,
dependencies,
consequences,
and liabilities.

This is the compiler analogy.

Software cannot run merely because it is elegant. It must compile.

Institutional language cannot become action merely because it is plausible. It must satisfy the tests required for action.

Runcible treats prose as source material. It reduces that prose into operational structures that can be tested.

4. Generate or Receive Candidate Hypotheses

Runcible does not replace foundation models.

It uses them correctly.

Foundation models are extremely useful hypothesis engines. They can summarize, classify, compare, infer, draft, explain, translate, retrieve, and propose. They generate semantic abundance.

But semantic abundance is not institutional authority.

A model-generated answer is a candidate. A candidate may be useful, false, incomplete, ambiguous, unauthorized, impossible, non-warrantable, or correct only under unstated assumptions.

Runcible therefore treats foundation model output as hypothesis, not as decision.

The model may propose:

a summary,
a classification,
a recommendation,
a legal or policy interpretation,
a workflow action,
a missing-evidence request,
a comparison,
a risk analysis,
a draft response,
or a proposed decision.

Runcible then tests whether that candidate can survive institutional scrutiny.

5. Bind the Candidate to RDL, Ontology, and Protocols

Before Runcible can adjudicate a candidate, the candidate must be bound to the domain.

RDL defines the domain language.

The ontology defines the relevant entities, relations, roles, claim types, and institutional objects.

Protocols define the tests that must be applied in a given context.

Together, these determine what the candidate means, what it depends on, and what it must satisfy before it can become actionable.

At this stage, Runcible asks:

What terms require definition?

What entities are involved?

What claim type is being made?

What evidence does this claim require?

What rule or policy governs the matter?

What authority is required?

What external systems or records must be checked?

What protocol applies?

What liability would follow from action?

The candidate is no longer treated as free-form language. It is now treated as a structured institutional claim or proposed action.

6. Adjudicate the Candidate

Runcible applies tests.

The exact tests vary by domain and protocol, but the general categories remain stable.

A candidate may be tested for:

identity,
clarity,
internal consistency,
external correspondence,
evidence sufficiency,
operational possibility,
causal support,
policy compliance,
legal compatibility,
authority,
reciprocity,
liability,
warrantability,
and decidability.

The purpose is not to make the output sound better.

The purpose is to determine whether the institution can act on it.

A candidate survives only to the degree that it can be stated, tested, reviewed, bounded, authorized, and defended.

Where closure is possible, Runcible may certify the result.

Where closure is not possible, Runcible identifies why.

7. Emit Diagnostics

Runcible does not merely accept or reject outputs.

It diagnoses them.

A failed candidate may fail for many different reasons. Those reasons matter because different failures require different repairs.

Examples include:

ambiguous term,
missing actor,
undefined object,
unsupported claim,
insufficient evidence,
contradictory evidence,
unsupported causal inference,
impossible operation,
missing authority,
policy conflict,
legal conflict,
externalized cost,
unresolved liability,
excess scope,
missing consent,
missing review,
or undecidability under current conditions.

This is one of the main differences between Runcible and ordinary AI guardrails.

A guardrail may block an output.

Runcible explains what failed, why it failed, what would be required to repair it, and whether the matter should be revised, escalated, restricted, blocked, certified, or left undecidable.

8. Assign an Action State

The result of a Runcible workflow is not merely an answer.

It is an action state.

A candidate may be assigned one of several states:

Certified
The candidate satisfies the relevant tests within the stated scope.

Repairable
The candidate may become certifiable if missing evidence, authority, definition, or clarification is supplied.

Requires Evidence
The claim cannot proceed without additional evidence.

Requires Authority
The proposed action is outside the current role, permission, delegation, or approval boundary.

Requires Review
The matter must be routed to a human, legal, compliance, policy, medical, financial, or managerial reviewer.

Restricted Use
The output may be used for analysis, exploration, or internal review, but not for final institutional action.

Blocked
The candidate fails a non-overridable constraint.

Non-Warrantable
The claim may be meaningful or useful, but cannot be warranted under the current protocol.

Undecidable
The matter cannot be resolved under the available evidence, authority, rules, or scope.

This action-state model is central to Runcible.

It prevents the false binary of “answer” versus “refusal.” Institutions need more than answers. They need status, boundary, reason, and record.

9. Produce the Decidability Record

Every governed workflow produces a Decidability Record.

The Decidability Record preserves what happened, what was tested, what passed, what failed, what was repaired, what remains unresolved, and what the institution may defensibly do next.

A Decidability Record may include:

the original matter,
assigned role,
scope of authority,
relevant inputs,
extracted claims,
evidence considered,
evidence missing,
rules and protocols applied,
tests performed,
diagnostics emitted,
action state,
certification status,
escalation requirement,
unresolved dependencies,
authority boundary,
liability boundary,
and audit trail.

This is not a chat transcript.

It is not a model explanation.

It is not a confidence score.

It is the institutional artifact that records why a claim or action was certified, repaired, restricted, escalated, blocked, or left undecidable.

The Decidability Record is the difference between AI assistance and institutional AI.

10. Route the Result Into Institutional Work

Once Runcible assigns an action state, the result must go somewhere.

That is where Oversing enters.

Oversing provides the work surface where Runcible-governed roles operate inside institutional workflows. It connects people, AI roles, tasks, documents, approvals, responsibilities, evidence, records, schedules, accounts, teams, and review states.

Runcible determines whether AI-mediated work qualifies.

Oversing gives the institution a place to assign, review, supervise, escalate, certify, record, and reuse that work.

The result may become:

a completed workflow step,
a task for another role,
an escalation,
a review packet,
an audit artifact,
a case record,
a certified claim,
a training example,
or part of the institution’s accumulating memory.

This is how AI work becomes institutional work.

What the Foundation Model Does

Foundation models generate candidate language.

They supply semantic variation, interpretation, comparison, drafting, summarization, classification, translation, and possible action.

They are useful because they can produce hypotheses quickly across large bodies of language.

But Runcible does not treat the model as an authority.

The model does not decide what is true.

The model does not decide what is legal.

The model does not decide what is authorized.

The model does not decide what is warrantable.

The model proposes candidates.

Runcible tests them.

What Runcible Does

Runcible performs adjudication.

It converts ordinary language into operational form, binds that language to domain terms, applies protocols, tests claims, identifies failures, assigns action states, and produces Decidability Records.

It answers the institutional question:

Can this output become action?

And if not:

Why not?

What failed?

What evidence is missing?

What authority is missing?

What liability remains unresolved?

What must be revised?

What must be escalated?

What remains undecidable?

This is the missing function in ordinary AI systems.

What Oversing Does

Oversing turns governed AI output into governed organizational work.

It is not merely a chat interface.

It is an institutional work surface.

Oversing gives Runcible-governed AI roles a place to operate inside real workflows: roles, permissions, documents, responsibilities, reviews, approvals, escalations, records, and institutional memory.

Assistants help individuals perform tasks.

Runcible governs institutional AI work.

Oversing provides the institutional environment where that work can be assigned, supervised, reviewed, recorded, and reused.

Figure 2:
Oversing provides the institutional work surface for Runcible-governed AI: roles, workflows, evidence, documents, approvals, records, teams, responsibilities, and Decidability Records operating together as governed organizational infrastructure.

Technical Architecture

At the public level, Runcible can be understood as a layered architecture.

1. Work Surface

The user, institution, or workflow submits a matter for governed AI work.

This may occur through Oversing, a Runcible plugin, an enterprise application, a document workflow, a compliance process, a case file, or an external system.

2. Runtime Orchestration

The runtime determines what work is being requested, which role applies, which domain is involved, which evidence is available, which protocols must be loaded, and which model or tool calls may be useful.

This layer coordinates the work without giving the foundation model unrestricted authority.

3. Hypothesis Generation

Foundation models and tools generate candidate outputs.

These may include summaries, classifications, interpretations, recommendations, proposed actions, missing-evidence requests, or alternative formulations.

The foundation model remains a hypothesis engine.

4. RDL and Protocol Context

RDL, ontology, and protocols supply the domain-specific constraints needed for adjudication.

They define the terms, claim types, evidence requirements, authority boundaries, permissible operations, and action-state rules for the matter at hand.

5. Adjudication

Runcible tests the candidate outputs against applicable constraints.

The tests determine whether the candidate is clear, operational, evidenced, possible, authorized, reciprocal, legally and institutionally compatible, liability-bounded, warrantable, and decidable.

6. Diagnostics and Repair

When a candidate fails, Runcible emits typed diagnostics.

Those diagnostics identify what must be supplied, revised, narrowed, escalated, or abandoned before the matter can proceed.

7. Certification and Records

When a candidate survives the relevant tests, Runcible assigns the appropriate action state and produces a Decidability Record.

The record preserves the institutional basis for action or non-action.

8. Institutional Memory

Certified claims, diagnostics, adjudication traces, and Decidability Records accumulate into institutional memory.

Over time, the institution develops a reusable corpus of governed work: not merely conversations, but certified and reviewable precedent.

The Durable Asset

Foundation models will change.

Interfaces will change.

Deployment environments will change.

The durable asset is the adjudication layer: the methodology, RDL, ontology, protocols, Decidability Records, certified claims, diagnostics, and accumulating institutional memory.

Runcible therefore does not compete with foundation models by trying to become a larger model.

It complements them by supplying the missing qualification layer.

The model produces language.

Runcible determines whether the language can survive institutional tests.

Oversing places the surviving result into governed work.

Where the Method Comes From

Runcible is not a prompt library, wrapper, or guardrail.

It is the runtime expression of a research program in measurement, operational language, testimony, reciprocity, law, institutional order, and decidability.

The research produces first principles.

First principles produce methodology.

Methodology produces RDL, ontology, and protocols.

Protocols produce executable adjudication.

Adjudication produces certified claims.

Certified claims accumulate into a corpus that can retrieve, audit, compare, and train future adjudication.

That is the research-to-runtime path.

Figure 3:
The Research-to-Runtime Stack shows how Runcible evolves from a scientific research program into executable institutional AI infrastructure: research produces first principles; first principles produce methodology; methodology produces RDL, ontology, and protocols; protocols produce adjudication; adjudication produces certified claims; certified claims accumulate into institutional memory and future training material.

How Runcible Differs From Ordinary AI Systems

Ordinary AI systems optimize for useful answers.

Runcible optimizes for qualified action.

Ordinary AI systems ask:

Did the model answer?

Runcible asks:

Can the institution act on this answer?

Ordinary AI systems rely on prompts, retrieval, tool calls, guardrails, and human review.

Runcible uses models, retrieval, and tools, but places them inside an adjudication process that tests whether the output can be stated, evidenced, authorized, bounded, warranted, and recorded.

The difference is not cosmetic.

It is structural.

AI assistance helps a person think or write.

Institutional AI must help an organization act without losing accountability.

Runcible supplies that missing layer.

Why the Decidability Record Matters

Institutions do not merely need better answers.

They need defensible records.

They need to know:

What was decided?

What was not decided?

What evidence was used?

What evidence was missing?

What rules applied?

What authority was present?

What liability was created?

What must be escalated?

What remains unresolved?

The Decidability Record answers these questions.

It turns AI output into reviewable institutional memory.

This is how AI work becomes auditable, repeatable, improvable, and governable.

From Conversation to Governance

The first phase of AI was conversational.

The second phase is institutional.

In the conversational phase, success means producing a helpful answer.

In the institutional phase, success means producing a qualified action state, with evidence, authority, liability boundaries, and a defensible record.

Runcible exists for that second phase.

It gives institutions a way to use foundation models without pretending that fluency is truth, confidence is authority, or output is action.

Foundation models generate candidate language.

Runcible adjudicates whether that language can become institutional action.

Oversing provides the work surface where qualified action is assigned, reviewed, recorded, and governed.

The Decidability Record preserves what the institution can defend.

Closing Call to Action

The fastest way to understand Runcible is to compare an ordinary AI answer with a Decidability Record.

An answer tells you what the model said.

A Decidability Record tells you what the institution can do.