Arxo: a general computational model for knowledge with explicit grounds

From source material to reusable, inspectable reasoning

Conceptual whitepaper · 5 October 2026

A rule is implemented in a spreadsheet, a service, an internal procedure, and an AI assistant. Each implementation makes choices: which edition applies, which exception matters, what counts as evidence, and what to do when information is missing. Those choices often disappear inside the application. A later developer inherits an answer or a formula without inheriting the reasoning needed to assess it.

Arxo treats a formalized knowledge model as a separate, versioned artifact that applications can use as a dependency. The central proposition of this paper is that the reusable unit should include the way a conclusion is obtained, the conditions under which it applies, and the grounds on which it rests. This is a proposed architectural contract, grounded in documented Arxo mechanisms. It is not a claim that every integration already preserves every part of that contract.

The paper is for developers integrating models into applications, authors formalizing sources, and researchers examining how models can compose across disciplines. It distinguishes documented capabilities, architectural requirements proposed here, and the longer-term ambition of cumulative executable knowledge.

1. Begin at the boundary between a measurement and a decision

Imagine a laboratory checking a manufactured component. A report contains a measurement of 9.8 mm with an uncertainty interval of ±0.4 mm. An illustrative specification sets an upper limit of 10.0 mm. Comparing the reported central value with the limit gives one answer. Requiring the entire stated interval to lie below the limit gives another. The arithmetic cannot choose the applicable decision rule.

This is a fictional teaching example, not a metrological recommendation or an executed Arxo package. Its purpose is to expose the decisions hidden by a simple “pass” indicator.

A useful model would keep at least four questions distinct:

Question	Required grounds
What was measured?	The value, unit, method, uncertainty description, and record of the observation
Which criterion applies?	The component classification, specification edition, and selected decision rule
Does the case satisfy that criterion?	Accepted inputs and the explicit calculation or inference
Has an authorized conclusion been issued?	The actor’s authority, the act of issuing it, and the procedure’s validity conditions

Missing calibration information is not evidence that the instrument was uncalibrated. Conflicting records do not become consistent because one file arrived later. A simulated assumption about calibration remains an assumption. A favorable technical result does not itself establish that an authorized person issued a certificate.

The result worth preserving is therefore more than a boolean. It identifies the question answered, the applicable model, the accepted observations, the chosen reading, and anything still unresolved. When an application displays that result, it should make clear whether the next step is another measurement, a choice between readings, or a human decision.

This boundary is where a general computational model becomes useful: it connects specialist work while preserving what each contribution can justify.

2. The object: a knowledge model with an application contract

For this discussion, represent a model as:

K = (S, V, R, A, D)

S names sources and their editions. V defines the vocabulary and types. R contains rules, calculations, and constraints. A states applicability conditions and how open questions are handled. D pins dependencies on other models. This is conceptual notation, not an Arxo file schema or a complete formal semantics.

The operation is:

Eval(engine, profile, K, context, question) → result

The context contains case inputs, relevant times, evidence, interpretation selections, and execution mode. Naming the engine and profile matters because the same artifact may be supported differently by different execution environments.

Arxo documents source, edition, publication, and fragment objects; anchors connect model elements to source material. Packages bring together a manifest, dependencies, scenarios, and provenance. These are concrete building blocks for an independently addressable model. A source anchor identifies a claimed relationship to text; it does not certify that the formalization expresses the text correctly. Sources, package tutorial.

The SDK exposes evaluation status and, where the query produces them, support status, values, proof, sources, hashes, and issues. The available result artifact depends on the integration: the documented local answer carries canonical document bytes, while a TypeScript remote answer carries a host projection and has document: null. An application can preserve only what its execution path actually returns. SDK, results and errors.

The architectural shift is to make the model and its conditions first-class dependencies. A spreadsheet, service, and agent can then use the same named reading and inspect where their inputs diverge. They need not independently bury that reading inside three implementations.

3. What can be shared across disciplines

Normative knowledge includes requirements, permissions, prohibitions, and rules that constitute institutional effects. A general infrastructure must also accommodate calculation rules, procedural transitions, and consistency constraints without assigning them the same meaning.

A duty addresses an actor who can fail to perform it. A constraint on a chemical model checks whether a representation is consistent with that model. A theorem rests on mathematical premises and a proof. An experimental conclusion depends on observations and methods. These distinctions remain necessary even when the surrounding machinery for naming, versioning, querying, and tracing is shared.

Arxo’s documentation includes scientific and methodological examples as well as legal ones: chemical constraints, a reproducibility criterion, and explicit units in calculation models. Their value here is as examples of different kinds of modeled content, not evidence of complete coverage or independent production adoption. The source bibliography retains the relevant corpus-form pages for inspection.

The proposed common structure is modest in one sense and demanding in another. Domains retain their own concepts and standards of justification. Every transition between them must state what is being transferred and what the receiving model is entitled to infer from it.

In the laboratory example, a measurement module may supply an interval; a technical module applies a decision rule; an institutional module represents the act of issuing a conclusion. A common interface is useful only if it preserves those differences.

4. An answer has more than one status

Arxo separates the presence of support for a claim from the presence of support for its negation:

Status	Reading
TRUE_ONLY	Positive support, without negative support
FALSE_ONLY	Negative support, without positive support
BOTH	Support for both sides
NEITHER	Support for neither side

These are states of support in a particular evaluation. They are not probabilities, confidence scores, or statements of unrestricted truth. In particular, lack of positive support does not by itself establish a negative claim. Negation and truth statuses.

Evaluation status answers a separate question: could the requested evaluation be completed under its contract? A computed query may return NEITHER. A query requiring a selected interpretation or an external judgment may instead carry a status explaining that dependency. Applications must read these dimensions together rather than turn every non-positive outcome into “no.”

Normative positions add another dimension. Whether a duty exists, is active, or has been fulfilled is different from whether an arbitrary predicate has positive support. The product interface should preserve whichever distinctions the query and model actually provide.

This matters for action. “No record supplied,” “opposing records supplied,” and “the responsible authority has not decided” call for different next steps. Collapsing them into a single empty or red field discards the information the model was built to retain.

5. Evidence, interpretation, and human judgment have separate jobs

A document, an assertion extracted from that document, and a premise admitted for inference are different objects. Extraction proposes what the document says. Admission determines whether that assertion may support this question under the applicable policy. Neither operation automatically establishes authenticity or the truth of the real-world event.

Arxo documents an evidence-policy stage for admitting support. It also distinguishes admission from burden of proof: deciding what supplied material can support is a different operation from deciding who had to supply it and the consequence of failing to do so. Evidence tutorial.

Fact origins distinguish case input, source assertions, external snapshots, derived assertions, adjudicated assertions, and simulation assumptions. That vocabulary is useful because a result based on an assumption should remain recognizable as conditional. But an origin label is not a signature or a credential check. A system still needs suitable procedures for identity, authority, and record integrity. Facts and evidence.

Interpretation addresses another question: which reading of a source is being applied? Arxo provides named readings and explicit selection policies. A descriptive status on a reading does not itself select it. Nor is disagreement between readings the same as conflicting support inside a selected reading. Interpretations.

Human judgment addresses an unresolved application of an evaluative criterion. Where a rule requires a competent actor to decide proportionality or reasonableness, silently inventing a numeric threshold would change the rule. The judgment channel can identify the required decision and its authority, with REQUIRES_JUDGMENT recording the unresolved dependency. Judgment channel.

These distinctions make review actionable. A reviewer can challenge the extraction, the admission policy, the interpretation, or the judgment without treating all four as an unexplained disagreement with a final answer.

6. Composition must preserve the strength and scope of grounds

A shared computational model does not require a single vocabulary for every discipline. Local models can expose interfaces and pin dependencies. But compatible types are insufficient: a “day” may be a calendar or business day, a “resident” may belong to different legal categories, and “confirmed” may refer to observation or adjudication.

A mapping between models is itself a modeling decision. It needs an explicit meaning and checks of the cases in which the mapping is valid. The following are proposed architectural invariants, not claims about universal automatic enforcement in current Arxo integrations:

1. Identity and scope travel with a conclusion. Preserve what entity, period, jurisdiction, or model domain the conclusion concerns.
2. Grounds do not silently gain force. An assumption does not become an observation; an observation does not become an authorized finding merely by crossing an API.
3. Conditions remain attached. Preserve units, selected readings, material dependencies, and other conditions needed for valid reuse.
4. Open questions remain open. A receiving model must handle missing support, conflict, and required judgment explicitly.
5. A new act of acceptance is visible. If a process adopts a result in a new capacity, record the rule or responsible decision that permits that transition.

The second invariant does not prevent new conclusions. A sound inference can produce a consequence its individual premises did not state. It prevents reclassifying the provenance or authority of a premise without justification.

In the laboratory example, a downstream certificate process may accept a technical assessment under an explicit procedure. That institutional transition adds a new ground: the valid exercise of authority. It does not rewrite the measurement as an administrative fact or erase its uncertainty.

7. Time and change belong to the meaning of an answer

Reproducing a prior result requires more than a package name. It requires the model artifacts and dependencies, the engine and profile, the question, the inputs, and the context that affected evaluation. Reproduction also depends on retaining any external material needed by that path.

Conceptually, distinguish the time of an event, the period in which a rule applies, the time information became available, and the time of evaluation. Current behavior must be described more narrowly than this ideal: Arxo’s documented observed and recorded metadata do not implement complete bitemporal evaluation. The fact validity window is evaluated against legal_time; the metadata fields do not justify promising historical knowledge reconstruction on their own. Fact boundaries.

A model upgrade should be examined against a stable set of cases. The useful difference may be a changed value, a newly applicable exception, a different chain of grounds, or an open question that was previously hidden. A dependency graph identifies candidates for review; executing the relevant cases shows which recorded answers actually change.

Byte identity is a separate claim from equivalent values and statuses. The SDK pattern documentation distinguishes those properties across execution paths. A publication should state which comparison was performed rather than advertise unqualified reproducibility. Application patterns.

8. The AI agent’s role becomes more precise

An agent can help locate a source, propose a formalization, extract candidate inputs, formulate questions, and explain returned results. That work benefits from explicit boundaries between proposing information, accepting it, and applying a model.

Arxo’s MCP interface documents operations for recording proposed facts with an author and external trace without changing the case or running inference. This establishes a useful integration boundary: extracted material can be reviewed before it becomes an input that affects a conclusion. MCP tool reference.

A responsible agent integration must retain evaluation status, support status, and the relevant grounds when explaining an answer. It should report an unresolved question as unresolved, identify a conflict, and preserve the dependency on a human decision. Where the model does not cover the question, any additional analysis should be identified separately from the model’s result.

The same care is needed during authoring. An AI-generated rule can compile and still express the wrong reading. Execution provides a place to inspect and test the proposed formalization; it does not make source interpretation automatic or error-free.

9. What would count as evidence that this works

Several claims often hide behind the word “verified.” They need separate evidence:

Claim	Relevant evidence
Execution follows the declared semantics	Independent execution checks, or a proof with stated scope
The model faithfully expresses a reading	Source reconciliation and domain review, including omissions and exceptions
Inputs are suitable grounds	Acquisition records, admission rules, and the relevant identity or authority checks
A result can be reproduced	Retained artifacts and context, followed by an actual replay
Composition preserves meaning	Tests at module boundaries, including assumptions, conflicts, units, and scope

For the laboratory example, a useful test bank changes one condition at a time: remove calibration support, introduce an opposing assertion, change the decision rule, switch the specification edition, and omit the act of issuing the conclusion. Expected outcomes must be defined before the cases can demonstrate anything. These are proposed tests; this paper does not report an executed laboratory model.

Practical evaluation should also measure maintenance: the expert work needed to review a source fragment, diagnose a changed answer, and update downstream consumers. A growing package count measures activity and breadth. It does not by itself measure fidelity, composition quality, or independent usefulness.

10. The contribution and the work still ahead

The ingredients have precedents. W3C PROV provides a framework for representing provenance. W3C RIF addresses rule interchange. A general model should be assessed in relation to this work and to specialist systems, rather than through a claim that executable rules or provenance are newly invented. PROV Overview, RIF Overview.

Arxo’s proposed contribution is the combined application contract: sources, explicit readings, support, time, rules, normative positions where relevant, and inspectable results. Algebra systems, proof assistants, and numerical solvers can remain specialist participants. Their outputs retain the particular kind of justification they provide; a numerical solution does not become a formal proof through integration.

Documented Arxo mechanisms provide material for investigating this contract. The laboratory example, the tuple notation, and the composition invariants are proposals developed in this paper. The longer-term ambition is a body of maintained models whose useful life extends beyond any one application.

A developer can begin with one bounded question, a pinned model, and an interface that preserves the answer’s statuses and grounds. A model author can begin with one source fragment, explicit interpretation choices, and tests for the ordinary case, missing support, exceptions, and conflict. A researcher can examine whether those properties survive composition and change.

The shared abstraction is a traceable transition from grounds to conclusion. Its value is measured by how much understanding another person or system can safely carry forward.

Basis and references

This is a conceptual publication dated 5 October 2026, not a language specification, an independent audit, or a claim of full corpus compatibility. Key semantic claims were checked against the repository documentation and selected official pages. No engine tests or corpus replay were run for this editorial revision. Some corpus-form pages could not be retrieved by the web reader; they remain references to project documentation, not independently verified findings. The full bibliography of the source manuscript is retained below as sources and further reading; inclusion is not a statement that every page was revalidated.

1. Arxo. Executable knowledge infrastructure.
2. Arxo. About Arxo — the idea behind executable knowledge.
3. Arxo Documentation. Comparisons.
4. Arxo Documentation. Constraints: corpus forms.
5. Arxo Documentation. Boundaries of power.
6. Arxo Documentation. Definitions: corpus forms.
7. Arxo Documentation. Facts and evidence: corpus forms.
8. Arxo Documentation. Vocabulary: corpus forms.
9. Arxo Documentation. Expressions and quantities: corpus forms.
10. Arxo Documentation. Sources: source, edition, publication, fragment, @source, label.
11. Arxo Documentation. A package in the corpus: manifest, scenarios, provenance, and checks.
12. Arxo Documentation. SDK reference.
13. Arxo Documentation. Negation and truth statuses.
14. Arxo Documentation. Your first rule.
15. Arxo Documentation. Facts and questions.
16. Arxo Documentation. From case material to admitted support.
17. Arxo Documentation. Facts and evidence: pitfalls.
18. Arxo Documentation. Judgment channel.
19. Arxo Documentation. Sources and legal time.
20. Arxo Documentation. Facts and evidence: boundaries.
21. Arxo Documentation. Readings: interpretation, group, selection and pin.
22. Arxo Documentation. Cheat sheet: packages and imports.
23. Arxo Documentation. Facts and evidence.
24. Arxo Documentation. The structural layer, form by form.
25. Arxo Documentation. A test on silence and a test on dispute.
26. Arxo Documentation. Power: exercise, validity, effect, immunity counterweight.
27. Arxo. MCP server — add executable knowledge to your AI agent.
28. Arxo Documentation. MCP tool reference.
29. Arxo Documentation. Patterns on the deadline example.
30. W3C. PROV-Overview.
31. W3C. RIF Overview (Second Edition).

Continue with a working model

Run your first question, inspect the SDK contract, or model a source. The Arxo Manifesto describes the commitments behind this work.