knowledge-centric-ai

Institutional Capability Lineage Architecture

Institutional Capability Lineage Architecture (ICLA)

Companion repository for the paper:

Institutional Capability Lineages: A Registry-centered Reference Architecture for Governed and Evolving AI

SSRN preprint — DOI: 10.2139/ssrn.7172438

Author

Mariano Garralda-Barrio

Institutional Capability Lineage Architecture (ICLA) is a reference architecture for preserving the continuity of recurring institutional capabilities across changing people, agents, models, workflows, systems, and infrastructures.

The public paper is identified by DOI 10.2139/ssrn.7172438. Reviewer companion packages intentionally omit the manuscript; the reviewed version is supplied through the corresponding submission channel. The specification, reference trace, and executable companion track the refined conceptual model and conformance boundaries being prepared for its successor.

ICLA addresses a problem that sits above retrieval, memory, context engineering, and agent orchestration:

How can an institution keep a capability authoritative, executable, traceable, and evolvable when knowledge and execution are distributed?

The architecture separates distributed execution and knowledge production from institutional authority. Humans, AI agents, workflows, software systems, and hybrid environments may reason and act locally, while capability identity, canonical contracts, evidence disposition, and institutional evolution remain governed, traceable, and auditable.

The Missing Question

Current AI systems continue to improve at execution.

Retrieval-Augmented Generation (RAG), agent memory, context engineering, skills, multi-agent systems, and interoperability protocols all help humans and AI systems perform increasingly complex work.

Yet organizations depend on something that none of these mechanisms guarantee on their own:

Who preserves organizational capability when people, agents, models, workflows, and platforms change?

ICLA is designed to answer that institutional question. Rather than improving execution itself, it introduces an architectural layer that preserves capability identity, authoritative knowledge, governed evolution, and institutional continuity across heterogeneous execution environments.

The Missing Question in Enterprise AI

Figure 1 — Current AI stacks continuously improve execution. ICLA addresses the missing institutional layer required to preserve organizational capability over time.

Quick links: SSRN preprint · Citation · Changelog · Conformance coverage · Schemas · Reference objects · Reference traces · Reference implementation

Why ICLA Exists

Current AI stacks are increasingly effective at retrieval, context construction, memory, tool use, coordination, and execution. These mechanisms improve what a system can do at runtime, but they do not by themselves guarantee:

ICLA introduces an institutional architecture layer that connects these responsibilities without replacing the execution technologies beneath it.

Why ICLA Exists

Figure 2 — Why: the current execution stack, the institutional gap, and the architectural responsibilities introduced by ICLA.

Core Thesis

ICLA makes the institutional capability lineage the primary architectural unit of continuity.

In this repository, ICLA names the reference architecture, an institutional capability lineage is its modeled authority-preserving relational structure, and a lineage trace is one concrete retained instantiation for a capability and its executions.

A lineage connects:

Neither a Registry nor a Capability Knowledge Contract preserves this continuity in isolation. The lineage connects what must persist with what must adapt.

Distributed Knowledge Becomes Institutional Capability

Figure 2 — What: distributed organizational knowledge becomes reusable institutional capability through a governed lineage.

ICLA at a Glance

Architectural question ICLA answer
What persists across changing execution mechanisms? Institutional capability identity and its lineage.
What is authoritative? The active, versioned Capability Knowledge Contract.
What is execution-specific? The contextual assembly and local CEE state.
Who may execute? Humans, agents, workflows, services, or hybrid environments.
What may justify future institutional change? Qualified evidence may inform governance; only an authorized activation changes the active institutional state.
How does the architecture evolve? Through explicit successor activation or capability crystallization.

Architecture Overview

The main architectural flow is:

  1. Registry — resolves stable institutional capability identity, ownership, lifecycle, relations, and the active CKC.
  2. Canonical CKC — defines the authoritative, versioned, consumer-independent knowledge and evaluation contract.
  3. Contextual Assembly — records an immutable, bounded operational mandate over exact CKCs, governed sources, evidence, and evaluation contracts.
  4. CEE — executes autonomously within that mandate using local reasoning, working state, tools, coordination, and iteration.
  5. Evidence — returns only contract-selected outputs and checkpoints while preserving provenance, assembly identity, applicable contracts, and any versioned transformation used to construct the submitted report.
  6. Governance — qualifies and adjudicates candidate institutional knowledge.
  7. Successor — activates a new CKC version for future resolutions while preserving historical state.

The Institutional Capability Lineage spans the complete lifecycle rather than appearing as a final repository or isolated audit trail.

How ICLA Works

Figure 3 — How: governed organizational memory becomes a bounded mandate, the CEE executes autonomously within it, and contract-selected evidence returns through an auditable lineage.

Architectural Positioning

ICLA does not replace RAG, agent memory, context engineering, skills, multi-agent orchestration, or interoperability protocols.

Those mechanisms primarily operate at execution time:

ICLA therefore operates at the institutional architecture layer around heterogeneous human and machine execution. Retrieval, orchestration, planning, memory updates, and tool use may occur inside the assembly or CEE; ICLA is not part of their step-wise execution loop.

Key Architectural Objects

Organizational Memory

ICLA treats organizational memory as versioned knowledge distributed across documents, code, policies, decisions, data, approved interpretations, observations, and evidence.

Its contents may play overlapping functional roles:

These roles describe how governed knowledge functions for a capability. They are not storage layers, and one source may support several roles. Source owners retain content authority while CKCs govern bindings and projection into capability execution.

Institutional Capability

A recurring, outcome-oriented institutional responsibility with:

Institutional Capability Registry

A navigable institutional address book that manages:

The Registry indexes distributed knowledge through governed bindings rather than duplicating source content.

Capability Knowledge Contract

A Capability Knowledge Contract (CKC) is the canonical, versioned, consumer-independent contract for the knowledge and evaluation commitments required to perform a capability.

A CKC defines:

CKC scope and source bindings may cover semantic commitments, procedural guidance, and episodic precedents without requiring separate CKC partitions.

Canonicality is an authority property, not a storage topology.

Contextual Assembly

A contextual assembly is an immutable, intent-specific projection of active CKCs and governed sources for a particular execution context.

It records:

An assembly may combine semantic commitments from policies, procedural guidance from governed practices, and episodic knowledge from prior incidents or evidence.

The assembly correctness trace records how RequiredCovered was assessed and pins the applicable validator, model, or review-policy version. This preserves auditability without requiring every assessment method to be deterministic.

Admission turns the assembly into a bounded operational mandate. It delegates execution-scoped authority to the identified CEE while explicitly withholding institutional or canonical change authority. The mandate remains valid without repeated Registry interaction until intent, coverage, authority, freshness, risk, or assurance changes materially.

Materialization may deliver a bundle, payload, workspace, procedure, or governed access handle. Every form must preserve the assembly’s exact versions, limits, evidence contract, and lineage.

Capability Execution Environment

A Capability Execution Environment (CEE) is the situated, execution-scoped boundary that performs an admitted capability instance. Its record pins the configuration attributes needed for resolution, authorization, assurance, traceability, and evidence interpretation; stable institutional identity remains with the capability lineage.

A CEE may be:

Through a contextual assembly, a CEE consumes authorized semantic commitments, procedural guidance, and episodic precedents. Within the admitted mandate it controls reasoning, planning, working memory, local stores, tools, intermediate artifacts, coordination, and iteration without step-wise ICLA interaction.

A CEE may produce situated observations, interpretations, artifacts, practices, decisions, measurements, and execution records. Those outputs remain candidate organizational knowledge until they pass through an identified source or evidence path.

Production, recurrence, or technical success does not grant institutional authority automatically.

Governed Evidence and Evolution

Only terminal or contract-defined checkpoint outputs return through the identified evidence path, with their execution identity, assembly, applicable contracts, and provenance intact. If a versioned transformation is used to construct the submitted report, its identifier and version remain in that provenance; no transformation reference is required when none was used. Conformance does not require disclosure of internal reasoning or working state beyond the evidence contract.

A submitted evidence bundle creates an episodic lineage record and presents reusable lessons as candidate knowledge. After qualification and adjudication, governance may:

A local execution never mutates canonical institutional state directly. Schema conformity does not establish substantive correctness or evidential sufficiency. Likewise, impact propagation identifies what requires assessment; it does not invalidate a CKC or block admission unless an applicable policy or governed decision makes the affected state inadmissible.

Maintenance events may be reviewed concurrently, while canonical succession remains ordered. A successor can be appended only from the latest appended CKC; a stale predecessor is rejected without creating a canonical branch or moving the active pointer.

Capability Crystallization

Capability crystallization is the governed formation of a new institutional capability from a recurrent responsibility supported by retained history and an authorized institutional review.

Detection may yield no proposal, one proposal, or several independent proposals. Ranking can prioritize this set, but it does not discard candidates or grant institutional authority.

It is distinct from extending the CKC lineage of an existing capability:

Scientific Contribution

The primary contribution is a Registry-addressable institutional capability lineage model that makes the following jointly accountable:

Supporting contributions include:

  1. Contract–projection separation
    CKCs remain canonical and consumer-independent; contextual assemblies and local execution state remain derived.

  2. Distributed execution with governed authority
    CEEs may reason, act, and produce situated knowledge locally without gaining authority to mutate institutional state.

  3. Evidence-governed evolution
    Each decision links the predecessor, a complete immutable successor CKC, and an authorized delta containing the changed commitments, rationale, supporting evidence, authorizing decision, and rollback reference. Activation affects only future resolutions.

  4. Succession–crystallization separation
    Incremental evolution of an existing capability is distinguished from the governed emergence of a new capability.

  5. Executable architectural specification
    The paper is accompanied by schemas, reference objects, linked traces, conformance profiles, a deterministic implementation, and executable tests.

Research method and evidentiary boundary

ICLA is developed as an iterative design-science artifact. The responsibility-oriented literature synthesis examines, refines, positions, and justifies the artifact’s objectives and protected boundaries; it is not presented as a one-pass derivation from literature to implementation. The requirement-to-component mapping records traceability among the identified problem, relevant literature, architectural requirements, and the resulting artifact.

The OAuth 2.1 trace is a constructed demonstration. Schemas, linked records, deterministic replay, negative tests, and invariant checks provide formative and summative artificial evaluation of structural consistency and technical feasibility within the declared scope. The comparative longitudinal protocol is prospective, and independent organizational validation remains future work.

Repository Contents

Path Purpose
citation.bib BibTeX citation entry.
CITATION.cff GitHub-compatible citation metadata.
CHANGELOG.md Public record of companion-artifact changes.
figures/ README and publication figures.
specification/conformance-matrix.md Coverage and evidentiary mapping from ICLA-1–ICLA-11 to machine-checkable clauses, supporting artifacts, executable tests, and governed-judgment remainders.
specification/schemas/ Machine-checkable JSON Schema contracts for the principal ICLA object types.
specification/reference-objects/ Consumer-independent reference objects and schema mappings.
specification/reference-traces/ Linked reference traces for the implemented lifecycle scope and prospective governed branches.
specification/reference-traces/oauth-042/ OAuth 2.1 trace covering pre-resolution source impact, resolution, assembly, evidence, governance, activation, and historical preservation.
specification/reference-traces/auth-evolution-formation/ Submitted-proposal trace covering governed identity formation, initial CKC v1 append, inactive state, and separate initial activation.
reference-implementation/ Deterministic, schema-driven implementation of resolution, evidence governance, CKC succession, capability formation, activation, and lineage preservation.
reference-implementation/tests/ Executable checks for both governed evolution paths, negative boundaries, historical immutability, and connected lineage.

Reference Artifact Set

The companion artifact set is versioned as icla-spec 0.1.0 and includes machine-checkable contracts for:

  1. institutional capability;
  2. pre-institutional capability proposal;
  3. Capability Knowledge Contract;
  4. Registry snapshot;
  5. intent;
  6. resolution and admission;
  7. contextual assembly;
  8. evidence bundle;
  9. governance decision and activation.

The paper defines the architecture and conformance requirements. The companion artifacts serve distinct scientific roles:

The schemas, traces, and implementation do not introduce additional architectural requirements beyond the paper’s conformance invariants.

OAuth 2.1 Reference Trace

The oauth-042 trace exercises the implemented resolution-to-succession lifecycle and represents the separate crystallization proposal branch without promoting it.

It includes:

The executable suite replays the same identifiers and verifies the pre-resolution IAM impact path, conformance, activation, historical immutability, and connected lineage. OAuth intentionally does not assign CAP-AUTH-EVOL; one execution is insufficient to establish recurrence.

The separate auth-evolution-formation trace begins with a submitted proposal supported by multiple retained signals. It executes authorized formation of CAP-AUTH-EVOL and complete CKC-AUTH-EVOL v1, retains the intermediate no-pointer state, and performs initial activation separately. This validates the transition structure, not automatic discovery or the institutional quality of the proposal.

Conformance Profiles

ICLA defines three cumulative profiles:

Profile Purpose
ICLA-Core Stable capability identity, Registry navigation, CKCs, contextual projection, CEE traceability, and reproducibility.
ICLA-Governed ICLA-Core plus governed evidence, measurement conformity, successor creation, and activation.
ICLA-Evolving ICLA-Governed plus ICLA-11 and the governed capability-formation boundary. The companion executes the submitted-proposal formation path; discovery quality and institutional judgment remain outside machine assessment.

Conformance is behavioral and implementation-independent. Every conformance result must state both the named profile and its assessment scope. The conformance coverage matrix records the available machine-checkable evidence and the governed-judgment remainder without assigning a score or certification status.

Scope and Non-Goals

ICLA is designed for recurring institutional work that is:

The architecture is independent of:

An implementation may use relational databases, graphs, object storage, REST, MCP, files, messaging, or other mechanisms, provided that the conformance invariants are preserved.

This repository is not:

What This Repository Demonstrates

This repository demonstrates:

It does not yet demonstrate comparative effectiveness in production environments.

The paper defines a longitudinal evaluation protocol for measuring:

Intended Audience

This repository is intended for:

Citation

When using this work in research, architecture analysis, or implementation, please cite the current preprint:

Garralda-Barrio, M. (2026). Institutional Capability Lineages: A Registry-centered Reference Architecture for Governed and Evolving AI. SSRN preprint. https://doi.org/10.2139/ssrn.7172438

Machine-readable metadata is available in citation.bib and CITATION.cff:

# See citation.bib or use GitHub's "Cite this repository" control

License

The paper and accompanying documentation are licensed under the:

Creative Commons Attribution 4.0 International License (CC BY 4.0)

The reference implementation and executable code are licensed separately under the:

MIT License

Status

Area Status
Architecture Defined
Conformance invariants Defined
Conformance coverage matrix Available
Companion schemas Available
Reference objects and trace Available
Deterministic reference implementation Available
Executable tests Available
Governed capability-formation transition Available
Automatic discovery and organizational evaluation Future work
Comparative longitudinal evaluation Future work
This site is open source. Improve this page.