A research handoff, end to end
Imagine a Singapore litigation team that wants a more consistent path from a research request to lawyer review. This is the toolkit's synthetic integration example. It contains no client matter, asserted legal authority, or live research result.
The current consultation describes an associate clarifying the question, finding material, and sending a note to a supervising lawyer. Handoff expectations vary. The team has no measured time or cost baseline.
Model a bounded improvement
The proposed design records scope and relevant dates before research begins. A lawyer accepts or rejects that scope. Accepted requests proceed to a research capability, and the resulting memo, sources, and limitations return for lawyer review.
View the relationship model
flowchart TB
I(["Research request"]) --> S["Record question, jurisdiction, dates, and scope"]
S --> A{"Lawyer accepts scope?"}
A -->|No| X(["Scope rejected"])
A -->|Yes| P["Check capability and source access"]
P --> R["Run the registered research method"]
R --> H{"Lawyer accepts research?"}
H -->|Yes| Y(["Research accepted"])
H -->|No| N(["Research rejected"])The rejection branches end this particular example. A different blueprint could define bounded revision, but a host should not improvise that extra loop. Missing tool access blocks the research task.
See each component's contribution
| Component | Contribution |
|---|---|
| Process meta-skill | Models the consultation, compiles the agreed process, and controls task eligibility |
| Scrum skill | Helps the implementation team plan and review the work needed to deliver the service |
| Singapore research skill | Supplies the reusable source and verification method used by the active host |
| Lawyer | Confirms the blueprint and makes the designated scope and research decisions |
The delivery backlog belongs to building the service. The research task belongs to an individual run. The research skill remains reusable because the question, dates, and matter facts arrive as inputs.
Follow the capability boundary
View the relationship model
flowchart TB
N["Workflow task<br/>Research the accepted question"] --> C["Required capability<br/>Singapore legal research"]
C --> B["Version-pinned method binding"]
B --> S["Reusable research skill"]
S --> H["Active host and available source tools"]
H --> O["Memo, sources, limitations, and evidence"]
O --> R["Runner validation and lawyer review"]The method binding identifies the approved implementation. It does not authenticate a commercial database account. The runner receives structured output; the lawyer still evaluates its substance.
What the demonstration proves
The local fixture checks exercised accepted research, rejected scope, and rejected research. They used synthetic actor decisions and a limited research result with no authorities. They tested routing and integration, including rejection of an attempt to complete a human decision through an agent task-completion call.
The example's BPMN exports validated against the bundled OMG schemas and imported into an independent BPMN viewer without warnings. Those checks support structural compatibility for these models. They do not establish substantive research accuracy or live-host access.
No filing, client correspondence, or external delivery occurs in this example. Its purpose is to make the boundaries observable enough to test.
Continue with the complex breach-response rehearsal for a 41-node, seven-swimlane execution, actual Studio captures and an operator SOP. Its real helper checks expose a missing-law source limit and a failed capture; its matter facts, decisions and notification effects remain synthetic.