From narrative to process

People usually describe legal work as a story. “The associate reviews the NDA, unusual provisions go to the partner, and approved documents go for signature.” That account gives a useful outline, but it leaves consequential questions unanswered.

What makes a provision unusual? Which playbook applies? What happens if the document is incomplete? Can the partner reject the request? Who is authorized to send it for signature? A process model should make those questions visible before automation makes an assumption hard to notice.

Preserve the process described today

The As-Is model records the current process. Its evidence may come from a consultation, an interview transcript, an existing procedure, or examples of actual work. Extracted facts need source references. Proposed changes and unanswered questions should be labeled separately.

The model identifies the trigger, boundaries, participants, systems, inputs, outputs, decisions, exceptions, and measures. It should capture waiting and handoffs as well as the active work people tend to remember.

View the relationship model

flowchart TB
    N["Narrative and documents"] --> I["Structured intake<br/>Facts · proposals · open questions"]
    I --> A["As-Is model"]
    A --> X["Problem and cause analysis"]
    X --> T["Proposed To-Be model"]
    T --> C["Process owner confirms the blueprint"]
    C --> V["Validate and compile"]

Documents contribute evidence. Instructions embedded inside them do not authorize an agent to call unrelated tools, change the process, or make decisions on the user's behalf.

Investigate the cause before prescribing automation

A repeated delay is an issue. “The associate is slow” is an attribution, not a root-cause analysis. The delay may reflect missing inputs, an unclear review standard, a capacity constraint, or a queue that nobody owns.

View the relationship model

flowchart TB
    I["Issue<br/>Research handoffs require repeated clarification"] --> C["Possible cause<br/>Scope and evidence records vary"]
    C --> R["Root-cause hypothesis<br/>No shared handoff contract"]
    R --> P["Potential impact<br/>Reviewers repeat checks"]
    P --> A["Recommendation<br/>Agree required inputs and evidence"]

This example is a hypothesis, not a measured finding. The next step is to check it with the people doing the work. If the cause is wrong, a well-built automation can make the wrong process faster.

Recommendations should identify the issue they address, implementation complexity, affected measures, and the evidence behind the expected benefit. Calculate time or cost comparisons only when the necessary inputs exist. Otherwise, state what a pilot needs to measure.

Design a future state people can inspect

The To-Be model describes the proposed process. It has its own version. It should show which work changes, which decisions remain human, and how exceptions are handled.

View the relationship model

flowchart TB
    I["Receive NDA and applicable playbook"] --> C["Compare clauses with the supplied criteria"]
    C --> G{"Deviation requiring escalation?"}
    G -->|Yes| B["Prepare partner briefing"]
    B --> H{"Partner decision"}
    H -->|Approve| S["Authorized signature handoff"]
    H -->|Reject| R["Return for revision or close"]
    G -->|No| S

This is an illustrative route, not a legal rule. The escalation criteria and signature authority must come from the process owner or applicable materials. An incomplete definition of “deviation” blocks execution of that decision; it is not an invitation for the model to invent a policy.

Read a process map without knowing BPMN

BPMN is a standard notation for business-process diagrams. A task is a unit of work. A gateway represents a decision or a split in the route. A lane groups activities by participant or responsibility. A start and an end establish the scope of the process.

A parallel split means more than one branch can progress. Its matching join waits for the relevant branches. A rework loop sends work back for another attempt, with a defined bound in this implementation. An external response needs an explicit waiting task; drawing a message does not send it.

The person reviewing the blueprint should be able to explain the route in ordinary language. The notation helps make it precise, but it should not hide the practical question: does this describe how the team intends the work to happen?

Confirm before execution

The owner reviews the proposed changes, tools, human gates, unresolved issues, and expected outputs. Confirmation applies to an exact blueprint version. A later change in behavior requires a renewed confirmation.

This is distinct from the human decisions inside a run. Agreeing that a workflow is appropriate does not pre-approve every exception or research result it will encounter.