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, Scout, 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, deployed, reused, externally exercised, protected, published, and demonstrated.
Citation and discussion are always welcome. All I ask is clear attribution to the original work and its documented chronology.
Attribution does not grant implementation, commercialization, or licensing rights to protected architecture.
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.
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.
Implementation and Deployment Before the Public Architecture Series
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.
Dated Implementation and Deployment Record
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–September 2025 — Reuse, External Use, and Continued Deployment
The work expanded beyond a single companion application. Mind-Mesh separated memory, identity, retrieval, context, provisioning, and secure API capabilities into reusable infrastructure built from the same underlying architecture.
By June 4, 2025, dAIsy was not only a working internal build. An independent external user had created accounts, accessed the live system, interacted directly with dAIsy, and provided contemporaneous feedback through the functioning account and subscription environment.
ScoutApp / Winery and other demos — June 10, 2025. Voice intro, styled chat, MP3 assets, and a deployable business-specific AI experience.
Scout was implemented as a third application built from the same underlying architecture and built as a configurable, data-driven SaaS agent platform rather than a single-purpose application. The same underlying system supported multiple branded agent experiences—including a winery agent, Susan Realty, and Samirac AI—through data, configuration, content, voice assets, and branding rather than separate codebases and all used the dAIsy brain. Its June deployments and continued demo-ready status through September 1, 2025 show that the architecture was being reused across distinct working applications before the patent filings and before the public article corpus.
This was not one isolated prototype. It was a reusable architecture operating across dAIsy, Mind-Mesh, and Scout.
Mind-Mesh and Scout were previously deployed working applications. They are no longer accepting users because development, productization, and licensing efforts were consolidated around dAIsy and the broader SAMIRAC architecture. Their inactive status does not alter the dated deployment record.
Late Summer 2025 — Continued Deployment and Formalization
While Scout remained deployed and demo-ready through September 1, I began turning the working 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–December 2025 — Patent Filings and Protected Architecture
Patent filings began on October 30, 2025, followed by additional filings on November 18, November 23, and December 5.
The filing sequence followed the working systems, multi-application reuse, external use, and continued deployment. It formalized mechanisms for external validation, coherence stabilization, drift correction, identity, trust, admissibility, and controlled execution.
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 implemented and protected architecture became publicly legible.
November–December 2025 — Public Architecture Becomes Legible
Beginning with the original LinkedIn publication of The Drift Problem on November 25, followed by Drift Stack™, The Reality Stack Manifesto, and The LLM Is Not the System, the architecture became visible to a broader public audience.
These publications explained the need for external reference, the layered nature of coherence, the difference between the model and the surrounding system, and the distinction between model output and executable action.
The Reality Stack Manifesto also made the cross-domain nature of the work explicit. It showed that identity, boundary, ledger, drift, collapse, and external correction appear across AI, manufacturing, organizations, institutions, cognition, human systems, and physical systems.
The domain changes. The architecture does not.
These 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 → reusable architecture → multi-application deployment → external use → formal protection → public exposition → continued demonstration and provenance.
Before the Vocabulary Converged
When Samirac began publishing this architecture, much of the visible AI conversation remained centered on prompts, prompt engineering, models, outputs, and model-level behavior. The distinction between the model and the operational system around it was still frequently misunderstood.
Contemporaneous LinkedIn correspondence with Mark Menard (VaultMind) on December 1, 2025 records Christopher Ciappa distinguishing substrate-level enforcement from the higher-order architecture required to identify the correct invariants, boundaries, reference frames, and external validation mechanisms before enforcement can preserve coherence.
“I wasn’t solving a ‘model problem.’ I was solving a cross-domain coherence problem.”
“The boundary only holds if it’s the right boundary.”
“Invariants precede enforcement. Enforcement implements invariants.”
The exchange matters because it captures the architecture in its original context: identity, reference frame, boundaries, drift detection, external validation, and the separation of model capability from system authority were already being articulated as connected system requirements.
By 2026, many of those same questions had moved toward the center of public discussion around enterprise agents, runtime governance, execution control, identity, authority, state, evidence, and admissibility.
Convergence does not by itself establish derivation. It is precisely why dated correspondence, implementation records, publications, filings, and source lineage matter.
Following the Architectural Questions
The chronology below documents the public progression of the architecture.
The writing made already-developed system concepts legible as the field moved toward the questions they addressed. The architecture was not being discovered by following the public conversation; the publications exposed a body of work already under implementation and protection.
The article dates matter because they show the progression.
The Drift Problem.
Industry conversation: Closed-system drift and external anchoring
Originally published on LinkedIn, the work stated the core rule directly: a system that attempts to verify itself using only itself will drift. External reference is therefore structural, not optional.
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 Reality Stack Manifesto.
Industry conversation: Cross-domain drift, collapse, and external correction
The work made the cross-domain claim explicit: the same structural sequence of identity, boundary, ledger, drift, collapse, and external correction appears across AI, manufacturing, organizations, institutions, cognition, human systems, and physical systems.
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, the public writing shifted from the model/system distinction to 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 and checkpoints.
Viewed chronologically, they document the public exposition of a continuous architectural body of work: coherence architecture → cross-domain drift → model distinction → governance layer failure → execution authority → admissibility → runtime governance → drift control → state architecture → organizational maturity → readiness assessment.
Together, they form a dated public progression.
Independent Third-Party Submission Records
Public publication dates are not the only dated evidence in the record. Two separate legal manuscripts were submitted through Scholastica in January 2026, creating independent third-party timestamps for the architecture as it was being formalized.
These are two different articles, submitted in two different Scholastica submission rounds.
January 6, 2026 — Liability Is Being Argued Too Late
Liability Is Being Argued Too Late: Why AI Accountability Begins at Architecture, Not Explanation was submitted through Scholastica to seven technology and law journals.
The manuscript stated the architectural liability rule directly: harm is the consequence of architectural permission, liability attaches upstream, and the relevant failure is an admissibility failure — a failure to constrain what actions were possible before execution.
Scholastica submission record — January 6, 2026. Seven journals, three rejections, four no-publication-offer dispositions.
January 6–8, 2026 — Direct Editorial Circulation
During the same January period, Architectural Admissibility as a National Security Risk was also submitted directly to Lawfare and Just Security.
Contemporaneous dated correspondence from both publications confirms receipt and editorial response, providing additional independent evidence that the manuscript existed in formal circulation outside Samirac during the first week of January 2026.
The evidentiary point is the dated external receipt and response: the work had entered multiple independent editorial channels before the later public execution-authority publication checkpoints.
January 21, 2026 — Execution Authority as the Missing Control Surface in AI Governance
A separate manuscript, Execution Authority as the Missing Control Surface in AI Governance, was submitted through Scholastica to ten journals.
This manuscript formalized execution authority as the relevant governance control surface and architectural admissibility as the pre-execution constraint that determines whether a system is permitted to act at all.
Scholastica submission record — January 21, 2026. Ten journals, three rejections, seven no-publication-offer dispositions.
The January 21 submission predates the January 25 public publication checkpoint shown above, creating a third-party dated record of the execution-authority and architectural-admissibility formulation before that later public article date.
These records matter differently from self-published timestamps. Scholastica is an external submission system recording the manuscript, submission round, journal recipients, and date.
They do not prove that a journal accepted the argument. They prove that the manuscripts and their architectural claims existed and were submitted to independent third parties on those dates.
Publication Date Note
Some articles in the current Substack corpus were originally published on LinkedIn and later republished or archived on Substack. Where an earlier original-publication date is independently documented, that date represents the first public checkpoint.
The Substack timestamp represents republication, migration, or archival publication and should not be mistaken for the date the underlying work originated.
More importantly, the public article corpus followed the working architecture. The later publications made the implemented and protected architecture publicly legible; they did not create it.
Public Publication Checkpoints
The Drift Problem in Plain English
Originally published on LinkedIn on November 25, 2025, and later republished or archived on Substack on February 26, 2026, 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 Reality Stack Manifesto
Published December 9, 2025, The Reality Stack Manifesto made the cross-domain nature of the architecture explicit.
It described the same structural sequence across people, companies, institutions, nations, AI systems, manufacturing, cognition, governance, and physical systems: identity and boundary establish coherence, the ledger preserves state and consequence, drift displaces the system, and external correction restores it.
The publication stated the principle directly:
Same architecture. Different domains.
It also documented the collapse sequence as identity drift, frame drift, boundary drift, ledger corruption, and drift overload, along with the reverse correction path through external correction, ledger repair, boundary restoration, frame re-anchoring, and identity recovery.
This matters for provenance because the cross-domain application of the architecture was not added later in response to emerging AI governance conversations. It was already publicly documented in December 2025.
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
Identity Verification and External Reference in Practice
Later real-world articles continued applying the already-defined architecture. A Kidney Stone, Seven Identity Checks, and the Architecture of Trust used healthcare identity verification to show why internal assertion is not enough: identity and state must be checked against an authoritative external reference.
A Kidney Stone, Seven Identity Checks, and the Architecture of Trust
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)
• Multi-application reuse and deployment
• Documented external use
• 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.
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.
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.
Operational Evidence and Decision Receipts
A governance architecture is not established by vocabulary alone. It is established by behavior.
dAIsy and Mind-Mesh maintain public provenance and decision receipts for that reason, while Scout is represented through dated deployment records. The receipts do not expose source code. They preserve 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.
Identity and Governed Memory
The record includes implementation checkpoints and demonstrations around identity continuity, memory handling, intent detection, recall, confirmation, removal, and authority-sensitive behavior.
Runtime State and Execution Authority
The record extends beyond model output into runtime state, pending and completed decisions, authority boundaries, admissibility, refusal, escalation, and execution control.
External Anchoring and Correction
The architecture also documents why closed systems drift, why internal state cannot be the sole basis for correction, and why external reference, validation, and correction are required to preserve coherence over time.
Demonstration Rather Than Description
Working applications, external use, deployment records, public demonstrations, decision receipts, and conformance materials provide separate evidence that the architecture operates as system behavior rather than existing only as a written framework.
The Record
The purpose of provenance is to create an objective record that survives memory, mood, narrative, and later convergence.
The record here spans working applications, multi-application reuse, documented external use, patent filings, public architecture publications, independent Scholastica submissions, direct editorial circulation, demonstrations, decision receipts, books, maturity models, assessments, and conformance materials.
It shows when concepts appeared, how they were expressed, what they connected to, whether they were implemented, and whether they were demonstrated.
It also separates evidence from inference. Similar language appearing later elsewhere does not by itself prove derivation. That is why dated source artifacts, third-party submission records, implementation checkpoints, and public publications matter.
The sequence is the evidence: working system → reusable architecture → external use → formal protection → public exposition → independent submission records and external editorial receipt → continued demonstration and conformance.
The architecture is already defined. The record shows how it got here.
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.