LARI — Local Autonomous Recursive Intelligence

LARI architecture · How it works

A different kind of AI model architecture.

LARI explores an alternative to AI systems whose capabilities come mainly from scaling a neural network or attaching external tools. The research idea is to represent executable learned capabilities within the model architecture so they can be constructed, composed, inspected, and deliberately changed. Today’s implementation combines structured model state, a unified task kernel, typed procedures and learned records, bounded execution, persistent user-scoped state, and a guarded model registry. User-scoped persistence is currently separate from the active base model; it is not evidence of broad self-learning. The diagram links to plain-language explanations below. Selected approved results appear in Lari Live; unapproved candidates remain private.

Request to governed behavior

LARI system architectureA request enters through a user surface, reaches the unified task kernel, which consults structured model state and dispatches procedures, retrieval, or bounded execution. Eligible state is persisted separately; model candidates pass verification and explicit registry promotion.Request surfacesWorkbench · CLI · APIUnified task kernelroute · select · executeStructured model statetyped records · programsProcedures & executionretrieval · bounded searchPersistent user statescoped · checkpointedVerification & registrycandidate · promote · rollback

Select a diagram component to jump to its explanation. The complete explanations follow in reading order.

01 · Input

Requests converge on a shared kernel.

The documented flow begins at Workbench, CLI, an OpenAI-compatible API, or an autonomous request. sendMessageToLari passes the request into runLariUnifiedTaskKernel, which classifies the task and dispatches an available route. Ordinary production requests are not silently delegated to an external model.

IMPLEMENTED · SOURCE-DOCUMENTED

02 · Routing

The kernel selects a bounded operation.

Depending on the request, the current system can use a deterministic procedure, retrieve relevant structured knowledge, execute a bounded operator or coding workflow, or refuse. Optional research/source acquisition is a separate path; its quality and verification depend on the specific task and evidence.

IMPLEMENTED · ROUTES ARE SCOPE-DEPENDENT

03 · Representation

Model state contains typed, executable structures.

The accessible source represents skills, procedures, knowledge, preferences, operators, repairs, and failures as structured records. Program-synthesis modules represent executable behavior with typed structures and compile selected programs into supported execution paths. This is not a claim that every record is newly learned or independently useful.

IMPLEMENTED · COMPOSITION VARIES BY RECORD

04 · Execution

Behavior runs through constrained contracts.

For bounded coding tasks, LARI can search and execute candidate repairs against explicit workspaces and test contracts. The source report identifies five bounded coding lanes, with reuse-only evidence; this does not establish arbitrary repository mastery. The general chat surface is more limited and uses deterministic procedures, retrieval, and refusal.

BOUNDED CAPABILITIES · NOT GENERAL AUTONOMY

05 · Learning & memory

Eligible knowledge can persist outside the active model.

A persistent worker keeps user-scoped state separately from the base model and can checkpoint eligible typed research knowledge. Changes to that state and changes to the active model follow different paths. Whether a particular learned record can be retained, reused, or rolled back must be evaluated for the relevant user scope and entry point.

MECHANISM DOCUMENTED · PUBLIC RESULT AWAITS REVIEW

06 · Qualification & change control

Candidates and active models have separate paths.

The candidate-retention path checks visible examples, hidden transfer, semantic faithfulness, reload, ablation, zero regressions, and zero external-model calls before retention. The registry blocks direct writes to the active model, records promotion transactions, and supports rollback to an available verified history point. These controls govern defined model operations; they do not reverse every user-state change or guarantee correctness.

GOVERNANCE PATH IMPLEMENTED · EACH CLAIM NEEDS ITS OWN EVIDENCE

Current boundary

LARI is best described as a local executable rule-and-program-synthesis research system under active development. It does not yet have a broad native text generator; general chat is more limited than bounded coding work. Specific research results are presented in Lari Live only after publication approval.

How the research evaluates results → · Approved public evidence →

Architecture ↔ evidence

Approved experiments by component

Only reviewed public records appear here. No relationship is inferred from a report heading.