The Spaarke Method: Envision, Design, Build, Deploy, and Manage

Systems of record give legal operations data. A legal operations intelligence platform gives it intelligence. The AI imperative has made that difference urgent, because an AI tool can only be as accurate as the context and the definitions it reads, and a record, however complete, supplies neither. In the ILTA 2026 Technology Survey of 508 law firms, nearly every responding firm (94%) was engaged with generative AI, up 14 points from the year before, and the survey's executive summary concluded that "The platform migration is largely complete, but the governance migration has yet to begin."

Two shifts raise the stakes. First, the model layer is becoming easier to obtain from several directions at once, which leaves the organization's own model of how it decides, a model no provider supplies, as the part that determines the result. Second, a department and its outside counsel work on the same matter in separate systems, so each side builds its capability in isolation. The decision legal operations faces first is which recurring decision to build around: accepting new work, choosing counsel, staffing a matter, responding to a regulatory inquiry, or answering a request from the business.

In our earlier article, The New Mandate for Legal Operations, we described legal operations as the catalyst and manager of the operating model, and cited Harbor's conclusion that "Technology is in place. The operating model has not kept up." Legal operations is a function in law departments and in law firms alike, and the method described here applies to both. The Spaarke Method is how legal operations builds the intelligence the operating model needs, one decision at a time, through five phases that form a loop: envision, design, build, deploy, and manage. This article sets out how Spaarke works with legal operations in each phase, who takes part, what exists at the end of each, and how mastering the phases builds, grows, and perfects the organization's own AI capability. The platform in question is the legal operations intelligence platform we described in our earlier article, How to Build the Legal Operations Intelligence Platform.

Systems of record give legal operations data. A legal operations intelligence platform gives it intelligence

Systems of record are essential, and what they give legal operations is data. A system of record is a database with a defined scope and structure. A matter system holds matters, an e-billing platform holds invoices, and a document repository holds documents, and each does its job well because its designers fixed the scope in advance for one function. In our earlier article, The Legal Operations Intelligence Ontology, we described how each system of record holds one dimension of the work.

Data records what happened, and the decisions legal operations is accountable for ask for more than that. Consider a department choosing which outside counsel should take a dispute. The matter system holds the history of similar disputes, the e-billing platform holds what each firm charged, and the document repository holds the work product. The decision also depends on which partner handled a comparable dispute and how it ended, on any conflict, on what the business unit expects, and on who in the department has the authority to approve the choice. No one of those systems holds the decision, and the knowledge that connects them sits with the people who have made it before.

Intelligence is what turns a record into a decision. A legal operations intelligence platform defines the entire operation and the business around it. It is multidimensional and draws on every source: the systems of record, the email and documents that no system structures, and the knowledge held by the people who do the work. It holds the entities across all of them, the relationships among those entities, the policy and authority that govern each decision, and the actions that follow. It brings each decision, with its context, to the person who has the authority to make it, carries out the action through a governed process, and records the outcome, so that the next decision starts from what the last one taught. It also reaches past legal, to the finance partners, the business units, and the outside counsel who work on the same matters. Spaarke's own system of record is one source among the platform's many.

This is the distinction that matters most, because the cost of lacking intelligence is high and AI raises it. A legal operations function can buy a platform, engage advisers, and start an AI pilot without deciding which decisions any of them is meant to improve, and legal operations teams increasingly acknowledge that the definitions then have to be paid for anyway, in configuration work and change requests. In our earlier article on building the platform, we noted that a build that starts before its owner is named tends to stall at the first action that needs a named approver. A department in that position stays data-rich and insight-poor: its reports are assembled by hand from three systems, its decisions are made in email, and what it learns leaves with the people who made them. An AI tool added to that data gives fragmented answers faster, because it can read what was recorded and has no way to read how the department decides. An AI tool that reads the intelligence has the context to be accurate, the authority rules to stay inside, and the governed actions to carry out its work. No single system of record can supply that, because the limitation is inherent in the architecture of legal systems, which is why the platform is a different kind of thing from one more system of record.

The difference also determines how the platform has to be built. A database is specified from requirements about what people record, and a competent team can build one from a requirements document and a schema. A platform that defines how an operation works is built from knowledge about how people decide, including the evidence a decision needs, the exceptions the organization grants, and the thresholds nobody wrote down. A team working from requirements and schemas produces a reporting layer, because the decision logic never reached the specification. That knowledge sits with experienced practitioners and with the organization's own end users, so they take part from the first day and in every phase of the work.

The Spaarke Method builds that intelligence one decision at a time, through five phases that form a loop

The Spaarke Method has five phases: envision, design, build, deploy, and manage. Each ends with something the organization can inspect, and the last phase begins the next cycle (Exhibit 1). The work takes one decision at a time, which keeps every phase tied to a decision that matters, and each decision leaves behind entities, connections, and governance that the next one reuses, so the platform becomes cheaper to extend as it grows. The phases overlap in practice, since a first working model on real data is often what makes a design concrete to the people who own the decision. Each phase also adds one part of the organization's AI capability.

Envision. The work starts from the outcomes the general counsel, the CFO, and the business unit leaders need. In a law firm it starts from what the managing partner, the practice leaders, and clients expect. It then identifies the decisions those outcomes depend on, and each decision is written as one sentence naming the user, the working surface, the decision, the inputs, and the action it produces. Consider a business unit that asks legal for a standard agreement, where nobody can say who decides whether the request needs a lawyer. Writing the decision as a sentence shows that it has three owners, and most of the effort goes into agreeing which of them decides. The decision owners name and test each sentence. The phase ends with a ranked list of decisions, one chosen as the first, a named owner for the platform, and a baseline for how long the decision takes, how often it is revisited, and what it risks or delays. The contribution to the AI capability is a choice, made before any model is chosen, about where AI is wanted and where a calculation is the right tool.

Design. The model is built backward from the decision: the evidence it needs, the entities and relationships that hold that evidence, the systems where each piece of data lives, the policy and authority that govern the decision, and the governed action that carries it out. The people who own the terms settle each definition together, which is the hardest part of the work. The design also records the source of truth for each entity and the limits that follow. For a firm, design also covers the engagement it shares with each client. Consider a law firm deciding whether to accept new work after a conflicts check, a capacity check, and a view of the client. Each of the three checks lives in a different place, and agreeing what counts as capacity takes longer than connecting any of them. Permissions, ethical walls, and the limits on what an agent may do are set here, and they become the guardrails AI works within. The phase ends with a written model of the decision's entities, relationships, policies, and actions, a source map, and definitions signed by the people who own them.

Build. The build starts in the first days, on real data, with the decision owners and the end users who will work in the platform. The team connects the sources, creates the entities the organization lacks a system for, defines the governed actions, and builds the surface where the decision is made. Consider a regulatory inquiry that arrives, where the department needs to know who must be told, what must be preserved, and who decides. The thresholds that answer those questions are rarely written down, and the build finds them by asking the people who have handled inquiries before. The test is the set of questions the general counsel or the managing partner asks repeatedly. Each is put to the new surface, to a recent joiner, and to the AI, and each is timed. A question that takes longer on the platform than by telephone shows what the model has missed, and the set becomes the organization's own evaluation of its AI. The phase ends with a working model and surface that the people who will use them have tested.

Deploy. The platform is built natively on Microsoft, so it goes where people already work, in Outlook, Teams, Word, and the matter page. It runs in the organization's own tenant, under its own identity and governance. Because the legal work lives where Microsoft Copilot already looks, Copilot and the organization's other agents can reason across it under the permissions the organization controls, and legal operations builds its own AI capabilities inside its own tenant and under its own control. In our earlier article, Why We Built on Microsoft, we explained why that matters. AI starts in proposing mode: an agent stages an action with its evidence, and a person confirms or changes it. Consider what a client's general counsel needs to see this week about an engagement, a question the firm and the client each answer from their own records. The difficulty is agreeing that both read the same record, and the engagement record that both sides work against settles it. End users work in the platform and correct what it proposes, someone is named as accountable when the platform and a person disagree, and the results are measured against the baseline. The phase ends with the decision made through the platform in live work, with a record of each decision, who made it, on what evidence, and what followed.

Manage. The phase covers ongoing execution and continuous improvement, and it is where Spaarke's managed services, technical and legal, run alongside the organization. Managed operations put the legal team, Spaarke, outside counsel, and other alternative legal service providers to work hand in hand on one platform. The platform removes the barriers between those contributors, so each decision draws on a 360-degree view of the information, whoever holds it. The managed service operates the platform and its connections, the organization keeps its definitions and playbooks current as the business changes, and the team reviews the decision record: where people overrode a proposal, why, and whether the model or the person was right. Consider early legal involvement, where the department wants a review before terms are agreed on certain transactions. After a quarter the record shows which reviews the agent routed correctly and which it did not, so its latitude widens for one kind of review and narrows for another, and reading that record honestly is the hard part. Each cycle ends with a measured result against the baseline, an updated model, and the next decision. That decision begins the loop again and costs less than the first, because the entities, connections, and governance already exist.

Forward-deployed legal engineers work with practitioners and end users in every phase

A legal operations intelligence platform takes the experience and know-how of legal engineers. Software alone cannot deliver it, and neither can consulting alone. The technology, the advice, and the managed service that runs the result have to be envisioned and designed together, and legal engineers do that work and answer for what it delivers.

A legal engineer is an attorney, a legal operations professional, or a specialty practitioner in an area such as intellectual property, contracts, litigation, or regulatory work, who understands how legal work is done and can translate it into the ontology and the decision platform. A legal engineer is also an expert in AI, with a working view of where and how AI adds value in legal work and where it cannot, and of where other technology, such as workflow, rules and calculations, integration, and analytics, will have the greater effect. The title is in use across the market, and we use it in this sense. Our legal engineers are forward deployed: they sit inside the organization's operations from the first day, work on its real data in its own tenant, and answer for what they promise and deliver. The legal engineer who scopes what the platform will do is accountable for delivering it.

Experienced practitioners and the organization's own end users take part from the first day and in every aspect of the method. The decision owners name and test the decisions in envision and agree the definitions in design. The people who will use the platform test it with their own questions in build, work in it and confirm what AI proposes in deploy, and review the decision record in manage. Their knowledge is the source material of the platform, and nobody else holds it. Consider a paralegal who has triaged inbound requests for six years and knows which requesters describe an urgent matter as routine. No policy records that, and it comes out only when the paralegal is in the room while the routing rules are written. The hard part is finding the time in a busy week.

Technology projects have long drawn on subject matter experts, who are usually consulted at the start to describe the work and at the end to review the result. That practice has served many projects well. A platform that defines the whole operation needs the practitioners and the users throughout, because the questions that only they can answer arise in every phase, and a build that waits for a review meeting finds them late. Legal engineers work with them.

Four habits mark the work. Legal engineers start from the decision and go to where the work is done, in the matter team, in finance, and in the outside counsel function, rather than working from the schemas of the systems. They learn from the practitioners why a practice exists before they change it, because an exception or a threshold often holds judgment that the formal process lost. They leave the organization's authority over its model and its agents intact, so that the organization decides what the platform contains and what an agent may do. And they work with named members of the organization's staff in every phase, so that the capability stays when the engagement ends. In our earlier article, Legal Ops Is Not IT for Lawyers, we made the case that ownership of the platform belongs inside the legal department, and the same holds for a firm's own platform.

One ontology joins technology, consulting, and managed services

Organizations have usually bought technology, advice, and operational support separately, often from different providers, and some providers now offer two of the three together. The Spaarke Method is a single structure in which the three are joined through one ontology, and the same legal engineers carry the work across the phases.

The ontology holds what each of the three learns. What the consulting work finds about how an organization decides is recorded in the model the platform runs on. What the platform shows is tested against the real questions the organization asks. What the managed service learns from running the platform changes the next design. The work therefore runs in every direction, and because all three work from the same model and the same people carry the work, the context does not have to be rebuilt at a handover.

The ontology draws on data from systems of record. Where that data comes from changes how the work is done. Spaarke can provide the system of record for legal operations, and an organization can connect the third-party systems it already runs. Working from the Spaarke system of record has clear advantages. The entities, identifiers, permissions, ethical walls, and decision record are native to the platform, so there is no identity resolution across systems to build, no refresh cycle to schedule, and no write-back limit to design around.

Where the organization needs data from systems it keeps, those processes and their limits have to be addressed in design. The organization decides which system is the source of truth for each attribute. The same matter may carry one number in the matter system, another on the firm's bill, and a third in a folder name, so identifiers have to be matched. Data refreshes on a schedule, and each third-party system permits what its interface permits for reading and for writing. A law firm's engagement with a client is the clearest case of data that crosses an organizational boundary: the firm can work against the client's record and operational memory instead of rebuilding its own on the same matter, and the design settles what each side can see.

The organization owns the ontology, the definitions, the policies, and the decision record, and all of it runs in its own tenant. In our earlier article, Your Legal Data Belongs to You, we described why the data stays with the customer, and the same reasoning applies to the model of how the organization decides. A change of AI model or of provider leaves the ontology, the governed actions, and the decision record in place.

Mastering the five phases builds, grows, and perfects the organization's AI capability

An organization's AI capability cannot be bought as a product. It is built from context, definitions, permissions, governed actions, an evaluation set drawn from the organization's own questions, and the skills of the people who use it, and then it has to be kept current. An organization builds, grows, and perfects that capability by mastering the five phases of the Spaarke Method, because each part of it comes out of one phase.

The evidence that this work is still to be done is consistent across both kinds of organization. In that earlier article we cited Axiom's 2026 survey, in which only 7% of 528 in-house legal leaders had scaled AI beyond pilots, and Deloitte UK's The AI Imperative, in which 84% of senior legal leaders had not redesigned roles around AI. The ILTA survey shows the same pattern among firms, where sophisticated tracking and compliance tools for work product were in use at fewer than one firm in five.

Those findings describe one gap from several sides. The tools are in place, and what is missing is a model of how the organization works, the governance around it, and the roles to run it. Each phase of the method supplies part of what is missing. Design produces the context and the guardrails: the definitions AI reads and the permissions it works within, which apply to an agent as they do to a person. Build produces the evaluation set, so that accuracy is measured on the organization's own work with its own data. Deploy puts AI into proposing mode and records each decision with its evidence. Manage widens an agent's latitude where the record shows it has been reliable and narrows it where it has not. The legal engineers, working with named staff, leave the organization with the skills to do this itself. We describe the approach as AI-directed, human-controlled.

Consider a law firm whose lawyers are staffing a new matter and want to know what the firm learned on three similar matters. The answer sits in closed files, time entries, and the memory of the partners who ran them. Making it available to the next team and to the firm's AI depends on deciding which earlier matters count as similar and what each client permits the firm to reuse, and that decision takes more of the work than the retrieval does.

AI is reshaping how legal operations works, and it has limits that the method accounts for. Its probabilistic outputs can be variable, inconsistent, and inaccurate. A budget variance, a rate cap test, or an assignment rule has to return the same answer every time, so those decisions use a calculation, and AI takes the work that has resisted rules, such as classifying an inbound request or extracting obligations from an agreement. In our earlier article, Legal AI Is Not Deterministic, we explained why that matters for legal work that requires precision, and in Knowledge Management: The Context Behind Legal Operations Intelligence we described the context that AI needs in order to be accurate and useful.

The Spaarke Method in practice

Legal operations has moved from holding data in separate systems to needing intelligence across all of them. Building that intelligence takes five phases, with experienced practitioners and end users in each of them and forward-deployed legal engineers working alongside them. Technology, consulting, and managed services are joined through one ontology that the organization owns, and mastering the phases is how the organization builds, grows, and perfects its own AI capability.

Systems of record give legal operations data. A legal operations intelligence platform gives it intelligence. The Spaarke Method is how legal operations builds that platform, one decision at a time, through five phases that form a loop. It takes legal operations from holding data in separate systems to building the intelligence that brings each decision, with its context, to the person who has the authority to make it, and the AI capability that depends on it.

For legal operations leaders in a department or a firm, practical starting points include the following. Write down the 10 decisions your general counsel or your managing partner would name as most important, and for each, who makes it, where, what they consult, and where the outcome is recorded. Name an owner for the platform inside the organization, and treat any decision with no owner, or with three, as the first finding. Choose one recurring decision to build first, and set a baseline for it. Decide where AI is wanted and where a calculation is the right tool, before a model is chosen. And agree how you will tell that the first decision has improved, and what evidence would widen or narrow what AI may do.

The next article in this series, Envision: How Legal Operations Defines Its Intelligence, describes how legal operations chooses its first decision and finds the decisions nobody owns.

Sources

• ILTA, 2026 Technology Survey
• ILTA, 2026 Technology Survey executive summary
• Harbor, 2026 Legal Department Maturity Index
• Axiom, 2026 Legal AI Survey
• Deloitte UK, The AI Imperative

Related reading:

• From Spend Analytics to Legal Operations Intelligence
• The UX That Legal IQ Requires
• Tenant-Dedicated Deployment

---

For questions or comments about this article, contact Ralph Schroeder, Founder and CEO of Spaarke, at ralph.schroeder@spaarke.com, or visit spaarke.com.