Inside the three layers

Each layer should have a clear job and a clear boundary. This makes it possible to replace a method, improve a workflow, or change a host without redesigning every other part of the system.

Domain capabilities: a library of methods for bounded work

A domain capability describes how to perform one kind of task in a legal context. Layer 1 is a library of them, not a single tool:

For Singapore research, the inputs include a scoped question, relevant facts, forum, the date at which the law is to be assessed, and the research date. The output includes findings, authorities, source locations, and coverage limits.

The method is reusable. The facts are not. A skill package should contain instructions and approved reference material, while each matter supplies its own inputs. This separation is what lets the same method serve another request without carrying a previous client's circumstances into it.

View the relationship model (Mermaid)

flowchart LR
    M["Reusable method<br/>Instructions · schemas · reference procedure"] --> T["Bounded domain task"]
    I["Matter inputs<br/>Question · facts · dates · documents"] --> T
    H["Available host tools<br/>Search · source reading · workspace"] --> T
    T --> O["Structured result<br/>Findings · evidence · limitations"]
    O --> R["Responsible human review"]

The first domain component is singapore-legal-research, which covers research and cite-checking. Its method distinguishes finding an authority from checking its identity, passage, proposition, and treatment. It does not supply a subscription to a paid database or guarantee that all relevant material was accessible. Other jurisdictions, drafting methods and review playbooks can join the library as further components.

The library is open to skills published elsewhere. Two examples, with thanks to their authors: LegalQuants' open-source skills cover drafting, playbook review, diligence and litigation workflows, and the legal plugin in Anthropic's knowledge-work plugins covers contract review, NDA triage, compliance checks and risk assessment. Both are Apache-2.0. Neither is part of the pinned toolkit; delivery can wrap either where it fits a need, and records that its revision is not pinned.

Each kind of capability has a contract: its inputs, its outputs and the consistency rules a reviewer relies on. A cite-check cannot report every citation as supported while one is unverifiable; an extracted value marked as found must carry the exact source text it came from; a date computed from an unverified rule must say so. Any skill that implements a contract can serve the same step, which is what makes the library replaceable piece by piece.

Delivery: find, build and release what the design needs

An architecture is a proposal until someone delivers it. The design states what each AI-supported step needs. Delivery decides how each need is met, looking first at what the domain library already offers:

View the relationship model

flowchart TB
    N["A stated need<br/>Inputs · outputs · evidence · decision owner"] --> I["Inventory Layer 1<br/>Pinned bindings · installed skills · host skills"]
    I --> B{"Reviewed binding fits?"}
    B -->|Yes| R["Reuse it unchanged"]
    B -->|No| W{"Installed skill has the method?"}
    W -->|Yes| A["Wrap it in an adapter<br/>Review before release"]
    W -->|No| G["Build a new method<br/>Legal rules from research, playbook or owner"]
    R --> T["Test every route · release sign-off"]
    A --> T
    G --> T

Reuse is preferred because a reviewed method has a known contract and version. A wrapped or newly built capability is marked for review before release and can be promoted into a reviewed binding once it proves itself. A need that cannot be met responsibly stays unresolved, and the work that depends on it stays out of the release.

The delivery layer also helps a team turn the design into increments: a validated intake, a first working handoff, a tested rejection route, or a recovery exercise.

Each increment needs acceptance criteria. “Research assistance works” is too broad to test. “The result includes source locations and coverage limits, and pauses for human review” is more concrete. The team also needs to know which legal criteria are settled, which depend on a reviewer, and which technical constraints remain unresolved.

The current components are scrum-skill, with its dashboard companion, and the capability resolver in the generated toolkit skill. They support resolution, facilitation and delivery records. Human accountability remains with the people holding the relevant responsibilities. The skill does not manufacture a commitment, a meeting outcome, or a legal approval.

Architecture: specify and control the process

The process layer makes the overall route explicit. Working with the lawyer, it records participants, task dependencies, business rules, input and output requirements, exceptions, and completion conditions. It distinguishes the process described today from the proposed future process, and states each AI-supported step as a need without assuming which tools exist. The design is signed off before delivery begins; the released version is signed off again before it runs.

The current meta-skill uses the active host to conduct intake and construct a structured manifest. A Python compiler validates that manifest and generates maps, skill packages, and execution artifacts. A local runner manages the resulting workflow state.

View the relationship model (Mermaid)

flowchart TB
    M["One validated process manifest"]
    M --> D["Readable models<br/>BPMN · SVG · analysis"]
    M --> S["Reusable skills<br/>Method · input contract · output contract"]
    M --> R["Execution plan<br/>Tasks · routes · human gates"]

Generating these outputs from the same specification helps keep the explanation and the executable behavior aligned. The diagram is not an independent promise maintained by hand while a separate script evolves elsewhere.

Interfaces make the layers composable

The architecture requests a capability through an explicit contract. Delivery work creates or improves that capability against acceptance criteria. The domain method produces a structured result that the runner can validate and a person can assess.

The implementation keeps the repositories separate and pins exact versions in a workspace lock. A pin is a reference to a specific revision rather than “whatever is latest.” It allows a run or installation to use a known method while another version is being developed.

This separation also prevents a common shortcut: treating a role as an agent. The partner lane records decision authority. A briefing skill can support that role, but the skill does not become the partner. The next chapter describes the skills that implement these layers today. Building the practice then explains, in depth, how the process is modeled and how reusable capabilities are derived from it.