Evidence Before Argument
Ideas are easy to claim after they become obvious.
Architecture leaves a record.
This page gathers public, dated checkpoints showing the formation, implementation, publication, demonstration, and protection of dAIsy, Mind-Mesh, Drift Stack™, Execution Authority, architectural admissibility, AI lifecycle governance, provenance receipts, and related patent-backed architecture.
The purpose is not to win arguments by rhetoric.
The purpose is to show when the architecture was built, when it became publicly visible, how the public record developed, where it was published, and where it was demonstrated.
Recommended Architecture Path
Drift Stack
This is the entry point. It defines the overall framework and the order of the architecture.
This sequence is cumulative. Each layer builds on the one before it.
Earlier RADAR and Maturity-Model Lineage
The AI Lifecycle Maturity Model™ and AI RADAR™ did not appear as isolated branding exercises. They extend an older pattern in the work: maturity models, readiness assessment, implementation risk, organizational development, and staged movement from tactical technology use toward strategic operating capability.
In 2003, Atlas Analytics published a Business Intelligence Maturity Model. The archived Atlas Analytics methodology page later described BI RADAR™ — Business Intelligence Rapid Application Development and Rollout — alongside the use of a Business Intelligence Maturity Assessment to identify organizational risk factors.
Atlas Analytics BI RADAR™ / Business Intelligence Maturity Model, 2003–2008 — earlier maturity-model and RADAR assessment work preceding AI Lifecycle Maturity Model™ and AI RADAR™.
The current AI work is different in subject matter, but the architectural pattern is continuous: assess maturity before scaling systems that transform organizational decision-making. In business intelligence, the question was whether an organization was mature enough to turn data into governed knowledge. In AI, the question is whether an organization is mature enough to allow intelligent systems to participate in execution.
The domain changed. The maturity question did not.
Why Provenance Matters
There is a point in the life of an architectural idea when the argument changes.
At first, people say the idea is strange, unnecessary, too abstract, too technical, too early, or not how the field talks about the problem. Then the environment changes. The same problem becomes harder to ignore. The same language starts appearing in adjacent conversations. The same architectural questions begin surfacing in governance, safety, risk, enterprise AI, agent design, memory systems, and production operations.
Eventually someone says, “Everyone is talking about this now.”
Maybe they are.
But that is not provenance.
Provenance is not the moment an idea becomes fashionable. Provenance is the documented path by which the idea was formed, built, published, demonstrated, refined, protected, and connected to a larger architecture. It is the difference between claiming a concept and leaving a public record that others can examine.
That distinction matters, especially in AI governance, where many discussions now arrive at the same set of questions: how does an AI system maintain identity across time, how does it remain anchored to reality, how does it detect drift, how does it know when execution is still allowed, and what determines whether a system may act at all?
Those questions did not appear here recently. They are part of a documented architecture whose development preceded the public article series.
Following the Architectural Questions
The chronology below is more than a publication timeline.
It documents how I used the public writing to address the architectural questions becoming visible in the industry at the time. The architecture was not being discovered by following the chatter. The writing was making already developed system concepts legible as the field finally reached the questions they answered.
The article dates matter because they show the progression.
The Drift Stack™
Industry conversation: Coherence, collapse, and system failure
The work publicly framed coherence as an architectural problem across identity, frame, boundary, drift, and external correction.
The model is not the system.
Industry conversation: Prompts, models, hallucinations, governance, and explainability
While much of the public discussion still treated the model as the object being governed, the work separated model capability from system identity, memory, permission, correction, and execution.
Execution authority and admissibility.
Industry conversation: Runtime systems, agents, and operational authority
As public attention moved toward agents and systems that could act, I shifted the public writing from the model/system distinction into the already-defined question of who or what has authority to permit execution.
State architecture.
Industry conversation: Governance that binds, drift, identity, and state
The public writing then made the identity, frame, boundary, execution state, drift measurement, and authority-stability layers more explicit. Drift was treated as measurable state displacement, not merely bad behavior.
The missing layer becomes visible.
Industry conversation: Runtime governance convergence
By March, the public work explicitly described the convergence of governance architectures around the same missing layer: runtime execution control.
AI Lifecycle Maturity Model™ and AI RADAR™.
Industry conversation: Enterprise AI readiness and organizational maturity
The public writing extended the already-defined execution architecture into organizational readiness: whether an organization is mature enough to deploy the level of AI autonomy it is pursuing.
Viewed individually, these are separate publications.
Viewed chronologically, they document the public exposition of a continuous architectural body of work: model distinction → governance layer failure → execution authority → admissibility → runtime governance → drift control → state architecture → organizational maturity → readiness assessment.
That is the record.
Development Timeline Before Public Release
Early 2025 — Architecture Under Active Development
The public writing did not begin the architecture.
The system work came first. dAIsy and the surrounding architecture were already under active development in early 2025, with work focused on memory, identity recall, conversational continuity, local application flow, authentication, database integration, and architecture around the model rather than inside the model.
April 2025 — Git-Backed Capability Checkpoints
By April 2025, the work had public Git-backed provenance receipts showing concrete implementation milestones. These were not theory posts. They were development checkpoints showing that core system behavior was already being built, tested, and stabilized.
The receipts include checkpoints for local development readiness, full flow operation, SSL, database integration, JWT, Stripe, identity recall, intent detection, memory-name patching, and PWA support.
That matters because it shows the architecture existed as working system behavior before the late-2025 public article corpus became the primary publication vehicle.
May–June 2025 — Productization and Extraction
The work then expanded beyond a single companion application. Stripe, provisioning, database integration, secure memory API work, partner flow, and related application structure show the architecture moving toward reusable system layers rather than remaining a chatbot experiment.
During this period, the core memory architecture also began separating into Mind-Mesh, reflecting the fact that the memory, identity, retrieval, and context layers were not merely application features. They were becoming reusable infrastructure around intelligent systems.
Late Summer 2025 — Formalization Begins
After the working system and related architecture existed, I began turning the implementation into more formal writing, diagrams, PDFs, explanatory framing, and system language.
This is the point where implementation began becoming a broader architectural corpus. The public writing made the work easier to understand, but it did not create the underlying system.
October–November 2025 — Patent Filings and Protected Architecture
By October and November 2025, the architecture had been formalized in patent filings and supporting documentation. That matters because the work was no longer only an implementation or article series. It had become a protected architecture with defined claims, mechanisms, and system boundaries.
The public-facing corpus should be read in that context. The November and December articles are not where the work began. They are where the already developed architecture became publicly legible.
November–December 2025 — Public Architecture Becomes Legible
The Drift Problem, Drift Stack™, and The LLM Is Not the System made the architecture visible to a broader public audience. These pieces explained the difference between the model and the system, the need for external reference, the layered nature of coherence, and the distinction between model output and executable action.
They should be understood as publication checkpoints, not origin points.
January 2026 and Beyond — Governance, Admissibility, Lifecycle, and Demonstration
Execution Authority, AI Lifecycle Maturity Model™, The Complete AI Journey, dAIsy demonstrations, Drift Architecture, conformance materials, and public decision receipts made the architecture visible across governance, runtime control, lifecycle maturity, evidence, and conformance.
The arc is working system → extracted architecture → formal protection → public theory → demonstrations → provenance.
Public Publication Checkpoints
The Drift Problem in Plain English
Published as part of the early public drift series, this article stated the core rule directly: drift is what happens when a system tries to verify itself using only itself. No external frame means guaranteed drift.
The article applied that rule across gyroscopes, inertial navigation, clocks, AI systems, people, institutions, and cosmology. The same pattern appears whenever a system tries to preserve coherence without an external reference.
The Drift Problem in Plain EnglishThe Drift Stack™
Published publicly on November 30, 2025, the Drift Stack™ described a five-layer architecture for coherence across domains: identity anchor, reference frame, coherence boundary, drift detection, and external anchor.
The claim was not limited to AI. It was cross-domain from the beginning: AI systems, institutions, physical systems, cognition, governance, and other coherent systems all require stabilizing architecture across time.
The Drift Stack™ — Why Every Coherent System in Reality Follows the Same 5-Layer Architecture
The LLM Is Not the System
Published December 31, 2025, this article documented the architectural separation between the language model and the surrounding application, agent, control, memory, permission, and execution layers.
The article made the core distinction explicit: the LLM generates language, but the surrounding architecture determines identity, memory, boundaries, tool permissions, admissibility, escalation, refusal, correction, and execution.
The diagrams published with the article already showed the separation between the model capability plane and the execution authority / drift correction plane. They included an admissibility gate, external correction, execution boundaries, result validation, rollback concepts, memory architecture, tool architecture, and layered control responsibility.
This matters for provenance because the architecture was not introduced later as a reaction to industry language. The system boundary, admissibility layer, drift correction responsibility, and distinction between model output and executable action were already documented publicly in December 2025.
Execution Authority
Execution Authority as the Missing Control Surface in AI Governance introduced architectural admissibility as a pre-execution constraint: the system must determine whether action is permitted before authority is exercised.
The central claim is simple: model behavior is not the true governance boundary. Risk begins when a system is permitted to act.
Execution Authority as the Missing Control Surface in AI Governance
AI Lifecycle Maturity Model™
The AI Lifecycle Maturity Model™ describes how organizations move from experimentation to governed operational AI. Governance does not mature because documents exist. It matures when selection, design, deployment, monitoring, correction, accountability, and conformance become part of an operating model.
The Complete AI Journey
The Complete AI Journey connects selection, governance, execution, runtime architecture, drift management, operational maturity, and continuous conformance into a single architectural path.
Published Books
As the public corpus matured, key concepts were consolidated into published books. These books represent another independently dated milestone in the public record, moving the work from individual articles into cohesive architectural references.
While the articles document the progression of the ideas over time, the books bring those concepts together into complete architectural narratives that can be evaluated independently of the article series.
April 28, 2026 — DRIFT: Why AI Systems Fail — and the Architecture of Control
This volume consolidates the architectural work around execution authority, admissibility, runtime governance, identity continuity, drift control, external correction, and the broader Drift Stack™ architecture into a single reference.
Rather than introducing new concepts, the book documents the architectural body of work that had already been developed through patents, demonstrations, standards, and the published article series.
Publication Date: April 28, 2026
May 9, 2026 — DRIFT: How America Lost Coherence — And The Only Way Back
The second volume extends the Drift Stack™ beyond AI systems into organizations, institutions, economics, governance, and society, demonstrating that the same structural principles governing coherent AI systems also appear throughout complex human systems.
Together, the two books illustrate that the architecture was never intended to solve only AI problems, but coherence problems across multiple domains.
Publication Date: May 9, 2026
The progression now becomes visible as a continuous body of evidence:
• Early architecture and implementation (2025)
• Patent filings and protected inventions
• Public article series (130+ publications)
• Technical standards and specifications
• Working demonstrations and provenance receipts
• Published books
• AI Lifecycle™ and AI RADAR™ assessments
• Conformance Reviews and implementation guidance
Together, these artifacts document the record of a single architectural body of work rather than a collection of independent ideas.
The Architecture Is Already Defined
The Samirac reading spine exists to make the progression easier to follow. It connects the architectural concepts, public articles, service paths, demonstrations, and technical standards into one navigable body of work.
The Drift Architecture page provides the core architectural framing. It describes the system layers required for identity continuity, interpretive stability, authority governance, admissibility, accountability, drift detection, governed correction, and execution oversight.
The services page explains how the work applies in practice.
Decision Receipts
A governance architecture is not established by vocabulary alone.
It is established by behavior.
Can the system maintain identity? Can it manage memory? Can it distinguish user intent? Can it track state across time? Can it detect when a question is pending, confirmed, cancelled, or expired? Can it separate conversation from authority? Can it demonstrate that the architecture operates rather than merely describing what it should do?
dAIsy maintains public provenance and decision receipts for that reason. The receipts do not expose source code. They establish public, dated checkpoints for independent verification. They show selected capability milestones, tagged versions, commit hashes, author dates, commit dates, and subjects.
They document when capabilities existed, not merely when someone later described them.
What Provenance Shows
Identity
It is one thing to say a system should have identity. It is another thing to show dated implementation checkpoints, public articles, demonstrations, and architectural pages describing identity continuity as a governed system property.
Governed Memory
It is one thing to talk about memory. It is another thing to show memory-related development, state handling, and demonstrations that distinguish recall, confirmation, removal, and authority-sensitive behavior.
Runtime Governance
It is one thing to describe runtime governance. It is another thing to demonstrate runtime state behavior and preserve public receipts showing when the capability existed.
Execution Authority
It is one thing to say AI governance requires accountability. It is another thing to define execution authority as the control surface and architectural admissibility as the pre-execution condition that determines whether action is permitted at all.
External Anchoring
It is one thing to say systems should be monitored. It is another thing to show why closed systems drift, why internal correction is insufficient, and why external anchors are necessary for coherence across time.
The Record
The purpose of provenance is not to win arguments on social media.
It is to create an objective record that survives memory, mood, and narrative. People can remember conversations differently. They can discover a problem late and assume the field arrived with them. They can adopt vocabulary after it becomes useful. That happens in every emerging field.
The record is different.
The record shows when concepts appeared, how they were expressed, how the public record developed, what they connected to, whether they were implemented, and whether they were demonstrated. It allows others to evaluate the chronology without relying on anyone’s self-description.
That is why I publish before I debate.
Why I Publish Before I Debate
I built dAIsy because memory, identity, continuity, and correction cannot be solved by pretending the model is the system.
I extracted Mind-Mesh because memory and retrieval needed to become reusable architecture, not an isolated application feature.
I filed patents because execution authority, admissibility, external validation, and drift stabilization are architectural mechanisms, not passing commentary.
I published the Drift Problem because closed systems drift when they lack an external reference.
I published the Drift Stack™ because coherence across time requires architecture.
I published The LLM Is Not the System because identity, memory, authority, admissibility, correction, and execution live in the surrounding architecture, not in the language model.
I published Execution Authority because legal and operational risk begins when a system is permitted to act.
I published the AI Lifecycle Maturity Model™ because governance must mature with capability.
I published The Complete AI Journey because organizations need a path from experimentation to operational control.
I published dAIsy demonstrations because architecture should be visible in running systems.
I published decision receipts because implementation should leave evidence.
The architecture is already defined.
The Central Question
The question is not whether AI governance needs identity, boundary, drift detection, external anchoring, admissibility, execution authority, lifecycle control, and architecture around the model.
It does.
The question is whether a given system actually implements those layers, or merely talks about them after the industry has begun to notice the gap.
That is the difference between a framework and an architecture.
A framework can describe concerns.
An architecture determines behavior.
Review the Architecture
Follow the public reading path, examine the architecture, and review the demonstrations and receipts.