ARC — Verifiable answers from better questions

AI has made answers abundant. Trustworthy answers are still scarce.

A plausible response can be useful, but plausibility is not evidence. In most AI-assisted workflows, verification remains a manual afterthought: inspect the result, redo the calculation, search for another source, write a test, or ask an expert.

ARC moves verification into the artifact itself:

Typical AI workflow
question → AI → answer → manual verification

ARC workflow
question + data + logic → executable artifact → Answer + Reason + Check

This moves the most valuable human work upstream: frame the right question, identify the relevant facts and rules, and decide what would count as a convincing check. AI can then do more of the mechanical work without asking us to accept an opaque result.

ARC does not make an answer trustworthy by sounding confident. It makes the answer inspectable, repeatable, and able to prove itself wrong.

Every ARC starts with three explicit inputs:

• Question — what do we actually want to know or decide?
• Data — which facts, measurements, observations, or inputs are relevant?
• Logic — which equations, constraints, policies, algorithms, or definitions govern the result?

From those inputs, an ARC produces three outputs:

1. Answer — the direct result to the question.
2. Reason — a clear account of how the result follows from the inputs and rules.
3. Check — an independent verification that confirms the result or fails visibly.

INPUT                         OUTPUT
Question ─┐                   ┌─ Answer
Data ─────┼─→ compute ────────┼─ Reason
Logic ────┘                   └─ Check

A good ARC question is more than a prompt; it is part of the specification. It should be precise enough to distinguish a correct answer, an incorrect answer, and a correct answer to the wrong question.

The result is not trapped in a chat window. It is a self-contained program that can be run again, inspected, shared, tested, and incorporated into an automated workflow.

An explanation is not verification. A model can produce a convincing explanation for a wrong result, so the Check must be capable of disagreeing with the Answer.

Where possible, it should take a genuinely different route from the primary computation:

• a second formula or algorithm;
• an invariant or conservation law;
• a reverse calculation;
• exhaustive comparison over a bounded domain;
• a known identity, boundary condition, or dimensional constraint;
• an independent data source;
• another domain-appropriate validation.

A check that cannot fail is not much of a check.

Because the Check is executable, it can run automatically whenever the question, data, logic, or implementation changes. A passing check is visible evidence. A failing check is useful information, not something to hide.

An ARC does not have to remain an isolated calculation. Its inputs and outputs form an explicit contract, so the checked Answer from one arc can become Data for another. Several focused arcs can compose into a larger arc with its own question, reasoning, and end-to-end check.

ARC A ──┐
ARC B ──┼──→ larger ARC ──→ Answer + Reason + Check
ARC C ──┘

A concrete example: one checked lunch order

One child ARC calculates how many slices the guests need, another establishes the capacity of a pizza, and a third calculates the gluten-free demand. Their checked answers become inputs to a parent ARC that produces the smallest valid order and then verifies it against the original guest list.

Demand ARC ─────── 36 slices ──┐
Package ARC ── 8 slices/pizza ─┼─→ Order ARC ─→ 5 pizzas: 1 GF + 4 regular
Dietary ARC ───── 4 GF slices ─┘                  Checks: contracts, capacity, diet, minimality

Run the interactive composition example → Change its inputs, then inject a stale child result to see both the local and end-to-end checks fail visibly.

The larger ARC does not merely collect results. It checks whether those results compose into a correct answer to the larger question.

The discipline is recursive: at every level, make the question explicit, expose the reasoning, and include a check capable of catching a wrong result. Small checked arcs become the building blocks of larger checked arcs.

ARC makes trust testable; it does not make computation infallible.

• A check is only as strong as its independence and coverage. Two implementations can share the same mistaken assumption.
• Correct computation cannot repair incorrect, incomplete, or stale data.
• Explicit logic can still encode the wrong policy or model of the world.
• Some questions involve uncertainty or judgment rather than a single provably correct answer. Their checks should validate evidence, constraints, calibration, or process instead.

That is why ARC keeps the Question, Data, Logic, Reason, and Check visible together. It makes assumptions reviewable and failures diagnosable. Human judgment remains essential—especially in choosing the question and deciding what evidence is sufficient.

ARC is a natural fit for STEM and other rule-driven domains with explicit structure and testable correctness conditions. Typical uses include:

• recomputing a mathematical result by a second method;
• checking algebraic identities, invariants, and error bounds;
• validating conservation, dimensional, range, or boundary constraints;
• testing an algorithm against known or exhaustive cases;
• checking engineering outputs against system constraints;
• tracing a rule-based decision back to its inputs and policy rules;
• comparing numerical results with analytical or independently computed results.

The pattern also applies beyond questions with one exact answer. A planning or policy ARC can show which evidence and constraints drove a decision, test whether required rules were respected, and fail visibly when its assumptions no longer hold.

• Question first — make the real information need explicit.
• Answer directly — do not bury the result in generated prose.
• Explain the derivation — expose the relevant rules, assumptions, and steps.
• Check independently — use a path that can catch errors in the primary computation.
• Fail visibly — never let broken assumptions or edge cases disappear silently.
• Prefer executable verification — make checking automatic and repeatable.
• Keep artifacts self-contained — preserve the complete case for inspection and reruns.
• Use only what the question needs — minimize irrelevant data and unnecessary inference.
• Compose through explicit contracts — connect checked outputs to defined inputs so larger arcs remain inspectable.

ARC fits naturally with Professor Ruben Verborgh's vision in Inside the Insight Economy: derive a purpose-specific insight for a particular recipient, context, and moment instead of moving or accumulating more raw data than necessary.

A well-formed question expresses that purpose. It lets a system focus on the data and logic the question actually needs, derive an actionable answer, explain the derivation, and verify the result.

• Delfour shows the micro-economic case: sensitive household information stays local while a narrowly scoped shopping insight is derived for one retailer context, with explicit policy and checks.
• Flandor shows the macro-economic case: exporters, labour-market actors, and grid operators keep detailed evidence local while a regional ARC composes their signals into a time-bounded stabilization decision.

Together, they illustrate the principle: move the minimum useful insight, not the maximum available data.

ARC does not replace the Insight Economy architecture. It complements it with a pragmatic discipline for question-directed, explainable, verifiable computation.