An open specification for treating reasoning as durable infrastructure.
New here? START-HERE.md routes you by purpose in two minutes. If the vocabulary is new, PRIMER.md teaches it on a system you already run.
LIA defines the architectural commitments that any AI-augmented system should make when reasoning patterns matter as much as the outputs they produce. It is a contract, not a library. It defines four layers, five node types, and the inter-layer schemas that any conformant system implements. Everything else (the routes, the evaluators, the feedback semantics, the model selection) is the proper subject of a domain profile.
The base specification is short on purpose. The profiles are where the domain thinking lives.
| Document | Version | Status |
|---|---|---|
| Base Specification | v0.2.1 | Working Draft |
| Support Profile | v0.1.0 | Working Draft |
| Research Profile | v0.1.0 | Working Draft |
| Creative Profile | Forthcoming |
LIA is a working draft. The architectural commitments are stable. The schemas, conformance tests, and operational guidance are still being refined through community input. Two domain profiles are published, Support and Research; a third, the Creative Profile, is forthcoming and will be contributed separately.
Most current AI integrations conflate distinct concerns into single opaque components. Reasoning, retrieval, validation, orchestration, and human review collapse into one prompt and one model call. The result is systems that are brittle at the edges and expensive at scale. They are also impossible to audit: when an answer is wrong, there is no way to tell whether the failure came from what was retrieved, what was inferred, or what was invented, and there is no structural place for the correction to land.
LIA proposes that this is not how AI products should be built. It defines deliberate seams between concerns so that brittleness is detected early, cost is controlled at the routing layer, and the system's reasoning can be inspected, evaluated, and improved over time.
The deeper claim of LIA is that reasoning patterns themselves are first-class infrastructure: structured, declarable, refinable, with feedback contracts that update them over time. A system that treats reasoning as an emergent property of model invocations cannot be reasoned about as infrastructure; that behaviour is observable but not specifiable, and improvement depends on retraining cycles rather than on accumulated evidence the system can interrogate. In practice, LIA's commitments put reasoning behaviour in declared places: thresholds live in versioned configuration, precedent lives in an index the system consults, feedback lives in contracts that state what updates what. Declared components can be inspected, tested, priced, and improved. Emergent behaviour can only be observed.
The framework applies to any AI product where reasoning patterns matter as much as outputs: creative tools, customer service, coding assistants, research agents, financial analysis, medical triage, legal review, operations. Two of these domains are demonstrated in detail with profiles published alongside the base specification, customer support and investigative research; a third, creative AI, is forthcoming and will be contributed separately. The others are the proper subject of community contributions.
INPUT
↓
[ L1 · Perception ] Translate raw input into a canonical object
↓ CanonicalInputObject
[ L2 · Classification & Routing ] Decide how this should be handled
↓ RoutingDecision
[ L3 · Reasoning & Execution ] Do the work via composed nodes
↓ ExecutionResult
[ L4 · Output & Feedback ] Deliver result, capture signal
↓ DeliveredResponse + FeedbackSignal
OUTPUT → signals return to declared stateful components
Each layer is composed of nodes. Every node in a conformant implementation is classifiable as exactly one of five types: Retrieval, Reasoning, Logic, Orchestration, or Human Checkpoint. The base specification defines what is invariant across implementations. Everything else is the proper subject of a profile.
A canonical sectional rendering of the architecture is published as LIA-section-drawing.html, drawn in the visual language of architectural section drawings. It is the recommended visual reference for talks, papers, and external citation.
The specification is structured as a base document plus profiles that extend it. New readers should generally start with the primer or a profile, since both ground the abstract structure in concrete systems.
PRIMER.md is the teaching companion. Plain-language definitions of every core term, a worked example that reads a typical RAG support bot through LIA and shows exactly where it is brittle, a catalogue of common anti-patterns, and a mapping for readers who come from control systems and industrial engineering. Read this first if the specification's vocabulary is new to you, or if you want to see the framework applied to a system you already run before reading the contract itself.
SPECIFICATION.md is the base specification. Defines the four layers, five node types, inter-layer schemas, observability requirements, failure semantics, versioning policy, and conformance levels. Read this when you need the contract, not the explanation.
profiles/PROFILE-support.md is the Support Profile. Extends the base specification for customer support AI, introducing the Resolution Atlas as a structured representation of institutional learning. Read this if you build customer service AI, work on agentic systems for enterprises, or are interested in how organisational reasoning becomes durable infrastructure.
profiles/PROFILE-research.md is the Research Profile. Extends the base specification for investigative reasoning, introducing the Evidence Graph as a structured, revisable representation of a line of inquiry. Read this if you build research, analysis, due-diligence, or intelligence tools, or are interested in how investigative understanding stays durable while remaining open to revision.
The Creative Profile is forthcoming. It will extend the base specification for creative AI products, introducing the Creative Genome, and will be contributed separately. See the note on the Creative Genome trademark in the License section.
/schemas contains the formal JSON Schema (Draft 2020-12) definitions of the four inter-layer contracts: canonical-input-object.json, routing-decision.json, execution-result.json, and feedback-signal.json. These are the canonical, machine-validatable definition of what a conformant LIA implementation must emit at each layer boundary. Worked example instances accompany each schema. Read schemas/README.md for validation guidance and the profile_extensions pattern.
Additional profiles are welcome. See Contributing below.
A system claims LIA conformance by implementing the four layers with their boundary contracts intact, classifying every component as exactly one node type, declaring an active profile, and emitting structured trace data.
Three conformance levels are defined.
-
Level 1 (Structural). All four layers exist with correct boundary contracts. Node types are correctly classified. A profile is declared. Trace is emitted.
-
Level 2 (Operational). Level 1 plus a functioning closed loop with declared feedback contracts, externalised routing thresholds, and complete observability.
-
Level 3 (Calibrated). Level 2 plus calibrated confidence aggregation, versioned threshold configuration, documented feedback loop effectiveness measurements, and a published profile conformance test suite.
Conformance is self-declared. Implementations indicate the level they claim and the profile they conform to.
The protocol rests on six principles.
-
Structural Minimalism. The specification defines invariants and deliberately leaves choices to profiles. What is invariant across all conformant systems is specified here; what varies between domains is specified by the profile that owns the domain.
-
Honest Uncertainty. The system distinguishes structurally between what it knows confidently, what it knows partially, and what it does not know.
-
Separation of Concerns. Reasoning, retrieval, validation, orchestration, and human review are different jobs performed by different components.
-
Cost as a First-Class Constraint. Token consumption and model selection are architectural decisions, exposed at the routing layer.
-
Observable by Construction. Every layer emits structured trace data. Provenance, audit, and attribution are queries against trace, not separate concerns.
-
Closed Loop by Default. Outputs generate signals. Signals update declared stateful components. A system without a functioning closed loop is non-conformant at Level 2 and above.
Having seen what LIA specifies, a reader familiar with the AI standards landscape will want to place it against existing protocols, particularly the Model Context Protocol (MCP), Oracle's Open Agent Specification, and the broader Agentic AI Industry Foundation (AAIF) ecosystem. LIA operates at a different layer of the stack and is meant to compose with, not replace, existing standards.
-
MCP defines how AI applications connect to external tools and data sources. LIA's Retrieval Nodes consume MCP servers as a routine implementation choice. An MCP-conformant tool integration sits inside an LIA-conformant architecture without friction.
-
Oracle's Open Agent Specification defines a portable, declarative representation of agents executable across frameworks like AutoGen, LangGraph, and CrewAI. LIA's Reasoning and Orchestration Nodes can be specified in Agent Spec format where the agent is the appropriate unit of decomposition.
-
A2A defines how agents communicate with one another across systems. LIA-conformant systems may participate as A2A endpoints when communicating externally.
LIA defines what existing standards do not: the architectural commitments AI products should make internally. The layers, the node types, the inter-layer contracts, and the closed-loop feedback that make a system's behaviour inspectable, priceable, and improvable. The existing standards describe how AI parts connect to other parts. LIA describes what the parts themselves should be.
The base specification and each profile version independently using semantic versioning. Profiles declare the base version they conform to. Breaking changes to inter-layer contracts or invariants constitute major version increments. Additions to required evaluators or node types constitute minor version increments. Clarifications constitute patch increments.
Contributions are welcome at three levels.
-
Editorial. Corrections, clarifications, and improvements to the existing documents. Open an issue or pull request. Accepted corrections are credited.
-
Profiles. New profiles for domains not yet covered (legal, medical, financial, scientific, educational). Profile authorship is a substantive contribution. Discuss your proposed profile in an issue before drafting, so the direction is agreed before you invest in a full draft, and follow the structure established by the existing profiles.
-
Implementations. Reference implementations that demonstrate the specification at work. These help readers translate the abstract structure into practice and validate that the specification is implementable. Implementations may be cross-linked from this repository when they reach a working state.
The base specification is editorially controlled. Profile authorship is open. Implementations are independent.
Apache License 2.0. See LICENSE for the full text.
Apache 2.0 is chosen specifically over the more minimal MIT license because it provides an explicit patent grant from contributors to users, protection that matters for a specification expected to be adopted in commercial and enterprise contexts, and because its modification marking requirement aligns with how the specification evolves through editorial control of the base and open authorship of profiles.
Trademarks. The Apache 2.0 license covers the specification text and does not grant trademark rights. "Creative Genome" is a trademark in formation held by DREAMVISION AI: when the forthcoming Creative Profile is published, its conceptual structure will be available openly under Apache 2.0 and may be implemented freely, while the term itself is reserved as a product designation.
If you cite LIA in academic, professional, or technical writing, please reference both the base specification and any profiles you draw on. A suggested form:
Colombo, Ila. LIA Protocol: An open specification for treating reasoning as durable infrastructure. Version 0.2.1. 2026.
Edited by Ila Colombo. Founder of DREAMVISION AI, Co-founder of DEOND.
The LIA Protocol began as the architectural foundation for DREAMVISION AI's creative intelligence platform. It is published openly because the architectural ideas are more useful as shared infrastructure than as proprietary advantage, and because specifications are best refined by the community that uses them.
LIA Protocol is a working draft. Architectural commitments are stable. Comments, contributions, and conformant implementations are welcome.