A recent vendor framing sorts legal AI tools into categories by where they keep matter state, and asks which category retains enough value to survive model commoditization. That is a useful prompt and the wrong question. Value durability is one axis. Accountability is another, and it is orthogonal: a system can hold matter state durably and still have no place for a named party to certify what it produced. This dispatch takes the second axis.
The property that decides
The Attestation Boundary — Luminity’s construct for the certification event that must exist at both the deployment layer and the per-output layer — is defined and grounded in regulatory doctrine in the companion dispatch, Accountability Is Architected In, Not Delegated. This piece takes that construct as given. It has two gates: the build-time gate is skill-specification sign-off, where someone with authority approves what the system is permitted to do before it runs; the output-time gate is the attorney’s signature, where someone with a license and liability certifies the specific work product before it leaves the firm. The companion establishes that the boundary must exist and who must stand behind it. This dispatch asks the prior question that construct assumes: which architectures can host those gates at all.
Both gates require the same underlying property — an authoritative source. NIST defines one as an entity with access to accurate information “such that [a relying party] has high confidence that the source can confirm the validity of the … evidence” [1]. Records management supplies the complementary test at the artifact level: ISO 15489 holds that an authoritative record is one that is authentic, reliable, has integrity, and is usable [2]. Read together, they define what “can be certified” means. Certification is not a feeling of confidence about a model. It is a structural claim that a specific source can confirm a specific artifact’s validity.
That property is not a function of model quality. It is a function of where state lives. If the system that produced the artifact does not persist that artifact — and the reasoning behind it — in a place the enterprise controls and can replay, there is nothing for the authoritative source to confirm, and no artifact for the record test to grade. The attestation boundary does not exist. No amount of model capability builds it back.
Four architecture classes, sorted by a testable property
The useful cut is not by vendor category but by a yes/no question: can this class support both a build-time and an output-time attestation gate? The organizing vocabulary is the operational-versus-analytical plane and per-domain authoritative source that data-architecture practice already uses [3].
Ambient assistant — no persistent state. State dies with the session. Nothing to sign at build time (no durable skill spec), nothing to confirm at output time (no retained artifact or rationale). Both gates fail structurally. [Internal evidence pending migration: cite surface-routing empirical base — Cowork excluded from Audit Logs / Compliance API / Data Exports across tiers.]
Task-bound tool — session-scoped state. State persists for a task, then is discarded or held by the tool vendor. A build-time gate is possible if the skill spec is durable; the output-time gate is weak, because the retained rationale lives outside enterprise control and cannot be independently replayed. Partial.
Standalone platform — platform-owned state, outside systems of record. State is durable but owned by the platform, not the enterprise. Both gates are simulable — the platform can show you an audit view — but neither is enterprise-attestable, because the authoritative source is the vendor, not the firm. This is the class most often mistaken for defensible.
Systems-of-record-embedded — state owned by the enterprise’s own systems. State persists in the enterprise’s authoritative systems. Both gates are structurally available: the skill spec is versioned in enterprise control, and the output plus its rationale are retained where the firm’s authoritative source can confirm them. This is the only class where attestation is a property of the architecture rather than a courtesy of the vendor. [Internal evidence pending migration: Open Pro Se as worked test case for this class; Vol 3 §5.5 / §2.3 as primary internal evidence.]
Why locus, not model, is load-bearing
The systems literature has independently arrived at the same conclusion from the performance side. Work on enterprise decision agents argues that statelessness — an append-only event log plus a task-conditioned projection at decision time — is the load-bearing property for regulated domains, precisely because it delivers deterministic replay and an auditable rationale that stateful memory violates by construction [4]. The audit surface is the tell: that design logs two model calls per decision where a summarization-based memory logs eighty-plus [4]. Attestability and architecture are the same choice, not two.
The broader review of agent construction makes the mechanism explicit: capability is increasingly moved out of model weights and into an external runtime — memory, skills, protocols, and a harness that coordinates them into governed execution [5]. Where that runtime persists its state is therefore where governance can attach. A governed enterprise orchestration prototype demonstrates the positive case: tenant-scoped connectors and audit-backed, policy-bound execution produce zero governance failures against baselines that block nothing, and the separation does not reduce to task specialization [6].
Once state is retained in enterprise control, the attestation evidence becomes constructible. It can be made verifiable — audits run inside trusted execution environments let a relying party confirm the interaction without trusting the provider [7]. It can be made tamper-resistant — the formal study of evidence chain-of-custody shows both what can be protected and, importantly, the negative result that some tampering opportunities cannot be eliminated, which bounds any honest claim [8]. And it can be made a byproduct rather than a deliverable — compliance evidence emitted in a machine-readable form as the system runs, not assembled afterward [9]. None of these is reachable when state never lands in a place the enterprise owns.
Hold the spine clearly. Only the enterprise-embedded architecture and its governed-execution kin deliver structural enforcement; the verification and evidence layers are real but necessary-not-sufficient — they confirm and preserve an attestation that the locus either made possible or did not.
Who signs
Accountability is the axis the value-durability framing has no slot for. The audit-tooling landscape confirms the gap empirically: a study of 35 practitioners and hundreds of tools finds the ecosystem heavily weighted toward evaluation and thin on the infrastructure that supports actual accountability [10]. Oversight scholarship supplies the architecture of the human role — a working definition, a layered oversight architecture, and the open problem that oversight itself is under-specified [11]. And the experimental result that sharpens the stakes: when a support system narrows an overseer’s options to a single action, the overseer feels less morally responsible for the outcome, while their judgment of the AI’s responsibility does not move [12]. Design that removes meaningful choice quietly removes the signer.
This is why locus is decisive for the output-time gate specifically. The attorney’s signature is only meaningful if the attorney had genuine, evidenced choice over an artifact their authoritative source can confirm. An architecture that persists state outside enterprise control can present a signature field; it cannot supply the conditions that make the signature mean anything.
Attestation capacity is fixed by deployment locus before any model runs. Where a system persists matter state relative to the enterprise’s authoritative systems determines whether a build-time and an output-time attestation gate can structurally exist — and no model quality, vendor assurance, or feature set adds a gate that the architecture omitted. Choose the locus and you have chosen whether the system can ever be attested. Everything downstream only confirms or preserves that decision.
The applied extension of this claim is the practitioner’s version: mapping each of the four classes onto a firm’s existing systems of record, and charting the migration path from platform-owned to enterprise-embedded state. That is where the architecture decision becomes a deployment plan.
