Legal AI, built around what matters

FlowCounsel™ is built around matter state, approval-gated workflow, and firm-scoped intelligence designed to compound from approved work and reviewed attorney corrections over time.

Patent Pending·Architecture-first·Approval-gated·Firm-scoped

Thesis

Legal AI should be built around the matter, not the prompt.

Most legal AI products still treat work as a sequence of isolated tasks: summarize this document, draft this response, answer this question, produce this chart. That can be useful, but it is not how legal work actually lives inside a firm.

Legal work lives inside matters. A matter has documents, deadlines, communications, people, review history, approved work product, and consequences. If the system does not understand that record, then every new output starts from a shallower place than it should.

FlowCounsel™ is built around a different center of gravity.

The matter is not a folder. It is the execution layer.

System Design

Matter-centric execution means the workflow has state.

This is the difference between a legal drafting surface and a legal operating system. The operating system knows what happened, what changed, what was approved, and what still requires judgment.

  • Uploaded documents become structured, reviewable matter state rather than detached file inputs.
  • Deadlines are extracted into explicit review states instead of disappearing into a black box.
  • Communications are tied to the matter record and can land in a Needs Review lane when classification is uncertain.
  • Generated work product is staged as draft, review-ready, approved, rejected, or superseded rather than treated as finished on generation.
  • Timeline, status, next actions, and provenance all update against the same matter record.

Diagram · Matter as execution layer

State surfaces feed the matter. Review states gate what becomes externally effective.

DocumentsStructured matter stateDeadlinesExplicit review statesCommunicationsRouted to lanesWork productVersioned draftsMatterExecution layerState · provenance · approvalsDraftGeneratedReview-readyAwaiting attorneyApprovedExternally effectiveRejectedOff the recordSupersededReplaced cleanlyProvenanceWhat the system used · what changed · who approved · what was retrieved · whenAudit-as-product
Documents, deadlines, communications, and work product become structured state on the matter, not detached file inputs. Externally-effective work moves only by review-state transition, never by silent generation.
Public Layer

Public discovery and private matter execution should share one operating layer.

Most legal AI systems are private case management OR public directory. Neither has the other half. Public-side directories collect prospects then hand them off. Private-side case management receives intake then asks the firm to re-enter context that already existed upstream.

FlowCounsel™ is built around a different conviction: the public discovery layer and the private matter execution layer should run on one operating layer so the source, intake structure, and attribution travel with the matter from origin through resolution.

The front door and the matter file should run on the same system. Otherwise the firm rebuilds context the moment a prospect becomes a client.

  • Source attribution travels with the prospect from the public surface into the matter record.
  • Intake captured on FlowLawyers (the public-facing directory) becomes structured matter data without re-entry.
  • Public AI intake follows the same structured schema the firm sees inside Matters — one record from public origin to retention.
  • Public surfaces are platform-branded by design; firm-branded campaign surfaces are paywalled to maintain attribution integrity and equitable access.
  • The matter file knows where the client came from. Attribution is an architectural property, not after-the-fact analytics.

Diagram · Public discovery + private matter execution

One operating layer. Source, intake, and attribution travel with the matter.

One record · public origin → retained clientAttribution as architecturePublic surfaceFlowLawyersPublic AI intakeStructured schemaSource attributionOrigin capturedPractice-area routingNo re-entryShared operating layerOne record. Same schema.Source captured at originIntake schema preservedAttribution travels intactNo context loss at retentionPractice-area routing matches firm scopePrivate mattersFlowCounsel · MattersMatter recordPre-matter → retainedReview statesApproval-gatedFirm intelligenceCompounds per firmPublic surfaces · platform-branded · equitable accessFirm-branded campaigns paywalled to maintain attribution integrity
Public-side directories that collect prospects and hand them off force firms to re-enter context that already existed upstream. A shared operating layer means the matter file knows where the client came from. Attribution is an architectural property, not after-the-fact analytics.
Governance

Attorney judgment should be a system constraint, not a disclaimer.

The legal market is full of tools that say a human remains in the loop. That phrase is too weak to be useful. The real question is whether the workflow is designed so that legal work can move into the world without a defined approval boundary.

FlowCounsel™ is built so AI acts as a supervised assistant under attorney control, never as an autonomous legal actor. Final state changes are gated by a non-bypassable approval transition, not by a policy hope.

No external effect without an approval transition. Review is the state machine, not a checkbox.

  • Supervised assistant, not autonomous actor. AI is a non-lawyer assistant operating under attorney supervision. Roles and final authority are scoped at the system layer, not negotiated by prompt. The attorney is the lawyer.
  • Final-state-change lock. Send, file, finalize, and final client-facing advice require an explicit, role-scoped, audited approval transition. The lock is part of the data model, not a UI affordance.
  • Refuse-when-unsure. Every run records a sufficiency state of sufficient, needs-information, or inconclusive. The system is allowed to decline rather than produce a confident wrong answer.
  • Invariant registry. Named runtime constraints carry a severity tier (P0 blocker through advisory) and a declared enforcement layer (orchestrator gate, approval gate, symbolic validator, export check). Safety is a registered, owned, replayable contract.
  • Audit-as-product. The audit trail is a queryable artifact the firm can review, not opaque trace data sold back as analytics.
Provenance

Every assertion has a source. Every run knows what it loaded and what it left out.

A defensible legal AI system has to answer two questions on demand. Where did this claim come from. And what context was used to produce it. FlowCounsel™ answers both at the data model, not in the audit log.

A vendor can add verification. A claim that traces back to its source through a durable manifest cannot be retrofitted.

  • Citation ledger. Every legal-fact assertion carries a structured source record: source URI, version, content hash, passage span, and last-verified timestamp. Provenance is durable, not best-effort.
  • Context manifest. Every run records what was loaded, why each record was eligible, what was deliberately excluded, and which assembly policy version was in force. The manifest is a first-class durable record, not a debug trace.
  • Versioned legal sources. Statutes, regulations, and opinions are stored as versioned records with effective-date semantics. The system distinguishes current text from the text in force at the time of the matter.
  • Replayable runs. Every workflow run is resumable and replayable against its original context manifest. A firm can reconstruct what the system saw, when, and why, months or years later.
Intelligence

Firm intelligence (FirmIQ™) compounds from approved work.

One of the biggest limitations of template-driven AI systems, the ones that ask firms to author and maintain their own workflows manually, is that someone has to keep the intelligence current by hand. That works up to a point, but it is static and expensive to maintain.

FirmIQ™ is the FlowCounsel™ layer that distills attorney review signal into firm-scoped patterns. It is not raw chat memory, provider memory, cross-firm learning, or automatic base-model fine-tuning. It is governed promotion of approved work and reviewed corrections into reusable firm intelligence.

FirmIQ™ separates that intelligence into three memory classes so each class can stay governed independently.

Episodic memory remembers what happened. Semantic memory holds what a firm has approved. Procedural memory learns the shape of how work moves to approved.

  • Episodic memory: the raw, replayable history. Draft versions, redlines, comments, approvals, reviewer identity, and the context manifest used for the draft. Postgres records and S3 snapshots — what was produced, what changed, who changed it.
  • Semantic memory: stable firm knowledge. Firm preference rules, client guidelines, jurisdictional playbooks, approved fragment libraries. Each rule is scoped, versioned, provenance-linked, and revocable.
  • Procedural memory: learned workflow shape. The sequence that turns a rough draft into an approved artifact, the escalation paths that worked, the recovery paths after verifier failure.
  • Promotion discipline: candidate → under review → approved → rejected → superseded → recalled. No attorney edit silently becomes doctrine. Promotion sources are restricted to approved artifacts, repeated approved edits, validated outcomes, and explicit operator rules.
  • Context-bounded retrieval: every run loads only the FirmIQ records eligible for that firm, client, matter, practice area, jurisdiction, and specialist type. The context manifest records what was loaded, why it was eligible, and what was excluded.

Diagram · FirmIQ™ core memory classes

Three classes governed independently. One context manifest per run.

InputAttorney edits, approvals, draft diffsTrajectory Intelligence ExtractorDecision attribution · diff → candidateEpisodicWhat happenedDraft versionsAttorney redlinesApproval decisionsContext manifest usedSemanticWhat the firm approvesFirm preference rulesClient playbooksJurisdictional defaultsApproved fragment libraryProceduralHow approved work movesReview sequenceEscalation pathsRecovery patternsOutcome-linked patternsGoverned promotioncandidate → review → approved → rejected → superseded → recalledBounded retrieval · context manifestScoped to firm, client, matter, practice, jurisdiction, specialist
FirmIQ™ is not chat memory, provider memory, cross-firm pooling, or automatic base-model fine-tuning. It is governed promotion of approved work into firm-scoped patterns the system can retrieve next matter.
Infrastructure

Model providers are interchangeable. The firm's record is not.

A vendor that ties firm intelligence to a specific model provider is offering a temporary advantage. FlowCounsel™ is built so the inference layer can be swapped without disturbing the matter record, the approval state machine, the audit trail, or the firm's accumulated intelligence.

Swap the model. Keep the matter.

  • Hosted models act as inference engines. They do not own firm memory, matter state, or approval authority.
  • Matter state, work product history, approvals, correction signals, and promoted patterns stay in firm-scoped infrastructure the firm controls.
  • External legal data sources feed the matter record rather than becoming separate silos.
  • Practice-area specialists run inside the same review, provenance, and approval model. No one-off workflows.
  • The firm can change inference providers without re-keying intake, rebuilding workflows, or losing accumulated firm intelligence.
Cross-Practice Layer

The operating layer should not be a single-vertical OS.

Most legal AI operating systems are built for a single vertical. Plaintiff personal injury OS. IP-only AI. Defense-only review tools. The architecture decision underneath is usually: bake practice-area knowledge into the operating layer. That choice fragments the firm and constrains the platform.

FlowCounsel™ takes the opposite position. Matter-centric execution, approval-gated workflow, and firm-scoped intelligence are practice-area agnostic. Practice-area knowledge lives in specialists with bounded scope — not in the operating layer.

Practice-area knowledge belongs in specialists. The operating layer stays universal.

  • The execution infrastructure is identical across practice areas: workflow runtime, approval gates, review states, audit, provenance. Matter shape varies. A personal injury matter, an IP matter, and a defense matter carry different state and run different specialists. The infrastructure underneath them does not change.
  • Practice-area knowledge is encoded in function-named specialists: a shared foundation (Intake, Records, Communications, Discovery, Deadlines, Resolution, Closure) reused across every practice area, plus practice overlays (Demand and Lien for PI, Application Drafting and Office Action Response for IP) that ride on top.
  • Bounded Specialist Contract. Every specialist declares its inputs, outputs, confidence fields, provenance requirements, invariants, review behavior, and failure model. Extension means adding a typed contract, not bolting a prompt onto a pipeline.
  • Specialists across practice areas run inside the same review, approval, and provenance model. No one-off workflows.
  • Firm-scoped intelligence compounds independently per practice area within a firm. Cross-practice firms get platform benefit at the firm scope.
  • The architecture extends as new practice areas onboard. The operating layer does not fragment.

Diagram · Cross-practice operating layer

Specialists are function-named jobs. The shared foundation runs across every practice area; practice overlays ride on top. One operating layer underneath.

Shared foundationReused across every practice areaSpecialistIntakeSpecialistRecordsSpecialistCommunicationsSpecialistDiscoverySpecialistDeadlinesSpecialistResolutionSpecialistClosurePractice overlaysLane-specific specialists ride on the foundationPI specialistDemandPI specialistLien workPI specialistSettlementIP specialistApplication draftingIP specialistOffice Action ResponseIP specialistClaim ChartingIP specialistDocket / PTABBounded specialist contractInputs · outputs · invariants · provenance · review behavior · failure modelOne contractMatter execution layerIdentical infrastructure. Matter shape varies by practice.Workflow runtime · approval gates · review states · audit · provenance · context manifestFirmIQ™ · firm-scoped intelligenceEpisodic · Semantic · Procedural. Compounds per firm. No cross-firm pooling.
Specialists are function-named jobs (Records, Demand, Office Action Response) with bounded contracts. The shared foundation runs across every practice area; practice overlays add lane-specific specialists on top. Matter shape varies by practice. The execution infrastructure underneath does not.
Why It Matters

What cannot be retrofitted.

Verification can be added to any vendor stack. Citation ledgers can be replicated. Authoritative content can be licensed. Agent SDKs can be swapped. Features that look like moats in current vendor pitches are reachable by any competitor with engineering capacity.

What cannot be retrofitted: matter-centric execution as the data model, approval-gated transitions as a state machine, a citation ledger and context manifest written into every run, firm-scoped intelligence that compounds from approved work, and a public-private operating layer that carries attribution from origin through resolution.

Those are architectural decisions made at zero. A platform that did not make them cannot add them without rebuilding.

Features bolt on. Architecture does not.

Read next

Where this architecture shows up next.

The thesis explains the system design. The next pages show how that design hardens in production, the applied research that translates it technically, and how it shows up in the product surface.