Using Neon Law Navigator

Learning objectives

The lawyer is always the actor; Neon Law Navigator is the instrument. Each objective is tagged with its Bloom verb:

• Remember — name the four Neon Law Navigator nouns and locate each in the workspace glossary.
• Understand — explain why every glossary noun is a database table.
• Apply — open the seeded Henderson Project and bind its pre-seeded deed template as a notation in a configured AIDA environment.
• Analyze — validate a draft's notation structure and identify the lawyer's checklist findings.
• Evaluate — review a peer's notation and propose one kaizen improvement.
• Create — explain the notarization workflow step and deliver a three-minute demo from a configured workflow channel.

The running matter

The class works one matter together so every example aligns:

• Project — Henderson Bungalow Purchase
• Buyer — Virgo (the value bound to {{client_name}})
• Property — a single-family residence in Henderson, NV
• Workflow step — lawyer_review → notarization__pending → notarized (complete)

Who is in the room

This workshop is for Lawyer users of the application: licensed lawyers who work matters for clients. The client in the class is Virgo; Virgo is the person the firm represents on the Henderson Bungalow Purchase matter. You will use the lawyer workbench and AIDA to open the matter, bind the notation, review the checklist, and advance the workflow.

Local KIND presenter rehearsal

Start a fresh worktree environment, source its descriptor, and run the host web process:

cargo run -p cli -- dev worktree-env up --path "$PWD"
set -a; source .devx/env; set +a
cargo run -p neon

Then browse to $NAV_BASE_URL/auth/login. Sign-in lands each tier on its own home — a firm tier on the /app/team home, a client on /app/projects. The stock local accounts are deliberately different lenses on the same seeded matter:

• lawyer@neonlaw.com / password is the Lawyer presenter. Sign-in lands on the /app/team home; open /app/projects to see Henderson Bungalow Purchase through Lawyer's firm-side paralegal participation — the workbench lens.
• client@neonlaw.com / password is the client presenter. Sign-in lands on /app/projects, which lists Henderson Bungalow Purchase through the client account's client participation — the client lens. Its detail has no seeded client Documents, Engagements, invoices, or review documents; those surfaces remain empty until a later exercise creates and releases them.

lawyer and client are system roles; paralegal and client above are per-Project participation descriptions. Do not use the now-unnecessary navigator dev grant-lawyer step for this fresh seed: it remains harmless for the browser harness, but it does not add project membership. Re-login after changing any role or participation.

How Neon Law Navigator works

Neon Law Navigator grounds your LLM output in a deterministic, shared glossary backed by database tables. The noun ladder:

1. Project — the matter ("Henderson Bungalow Purchase").
2. Template — a markdown blueprint with {{placeholders}} and a workflow declaration.
3. Notation — one Person bound to one Template inside one Project, advancing through a workflow.
4. Workflow — the state machine the Notation walks.
5. Signed — the lawyer's own work product.

Matter files: portal for clients, workbench for lawyers

Every Project also has a matter file surface. Clients see it as Documents, Engagements, Invoices, and other plain-English portal views. If a person is added to a Project, Navigator can show them the client-facing files for that matter; if they are not added, those files do not exist from their portal's point of view.

Lawyer users have the firm workbench. Assigned lawyers work the Project through /lawyer. Admins are lawyer-tier users with installation-wide authority, so they can reach the same firm workbench without per-Project assignment. Clients never need that layer and never see the private GCS bucket behind the files.

The Shared Drive and Project repository map

The firm's Projects Shared Drive is the production matter-file root. Its top-level folders are Navigator Project codes, not display titles: a matter whose code is henderson-bungalow-purchase lives at Projects/henderson-bungalow-purchase/. A code uses only lowercase letters, digits, and single hyphens; Navigator requires it when a Project opens because the name is an equality check, not a display-name normalization.

The same convention is deployment-owned rather than guessed from a laptop or a repository:

The organization is configuration rather than a name in Navigator's source, and one string means two different things across the two vocabularies: the organization neon-law is staging, while the GCP project neon-law is production. The organizations are named for the entities and the GCP projects for the deployments.

A Project has one repository and one portal, and both are the code. That matter's source lives at neon-law/henderson-bungalow-purchase, holding its notation templates under templates/ and its client portal under portal/, and Navigator serves that portal at /app/projects/henderson-bungalow-purchase/portal/ — the repository name plus one literal segment. Nothing is composed, so nothing has to be parsed back apart, and there is no manifest anywhere restating a name the repository already carries.

Drive holds the firm's legal working files and Navigator holds the matter record and asset provenance. Project repositories hold source only: never client uploads, answers, generated legal documents, secrets, dependencies, or build output. When CI publishes approved Project-scoped template or application output to Drive, it resolves the matter folder from Navigator rather than from a repository-supplied folder ID, writes one way, and records the publication for audit. A hand edit to that published output is drift, not a source change. Project participation grants Navigator and deployed-application access; it never grants GitHub Enterprise access.

Install (no install)

The class uses Gemini's "Add AIDA" connector. About ninety seconds:

• Open your Gemini workspace and click Add connector. Paste the workshop's connector URL (the instructor will display it). Authenticate with your firm Google account, and confirm.

Sign in as yourself

The connector URL is not access to the firm's matters. AIDA acts as the person who signed in:

• Gemini sends Navigator the Google OAuth token for the firm account you selected; Navigator verifies it, then looks that email up in its own people record.
• Only a person recorded as lawyer or admin can use AIDA's matter tools. You cannot gain that role by asking AIDA.
• Denied during class? Sign in with the lawyer account the instructor provided, or ask them to check your role.

Tool calls are just prompts with specific words

Every "tool call" is a regular Gemini prompt with one or two words that route it through Neon Law Navigator. Try one:

"AIDA, list my projects."

Build the template

Write a small markdown template for a deed of sale. The minimum body for the class:

# Deed of Sale

This Deed is made between {{client_name}} ("Buyer") and the named Seller for the property described
herein. Choice of law: Nevada. Buyer's signature must be acknowledged by a Nevada notary public under
Nevada's Uniform Law on Notarial Acts (NRS 240.161 to 240.169).

Buyer: ______________________
Date:  ______________________

Run the transactional checklist

The checklist is the same list you run in your head: choice of law, privilege, confidentiality, active voice, inclusive language. aida_validate_notation can report structural notation diagnostics for supplied Markdown; it is not a named transactional-checklist service and it does not save the draft.

"AIDA, validate this notation Markdown and show the diagnostics."

When AIDA asks before she acts

One rule on the A2A connector: reads run, writes wait. A write pauses and asks first:

"Authorize this action? AIDA wants to Send Welcome Email for Virgo… Reply yes to authorize, or no to cancel."

When an answer is wrong, send it back — don't start over

Review is not only approve or decline. A third choice keeps the matter moving:

• Flag the specific answers that are wrong, add a note, and send it back. Only those get re-collected — by the client from their portal, or by your paralegal on their behalf — and it returns to your desk for review.

Answers and questions are two different things

You are correcting an answer, not re-opening the questionnaire:

• Only the answers you flagged are re-collected. Every other answer stays as it was, and the matter never re-walks the whole intake.
• The paper stays pinned. Correcting an answer does not swap the template version the matter opened on — the bytes you review are the bytes the client signs.

The conflict check runs before every new matter

When you create a Project, Navigator runs a conflict check first — before the matter exists:

"Conflict check flagged this matter for review: shares a party with a current client's matter. Confirm you have reviewed these findings and are authorized to proceed."

Notarize and demo

In a configured workflow channel, advance the notation: lawyer_review → notarization__pending → notarized (complete). The stock local KIND rehearsal does not include a Gemini connector or a configured reply-email channel, so do not present this as a browser-only local action. For the three-minute demo:

At lawyer_review, reply to the conversation's token address with these two command lines:

@link <notation-id>
@approve

@link connects the conversation to the Notation. @approve then fires the workflow's approved condition.

1. The matter ("Henderson Bungalow Purchase, buyer Virgo").
2. The template you wrote (show the markdown).
3. The notation you bound (show its returned notation record and the source template).
4. The one checklist failure you found and fixed.
5. The workflow advance to notarized.

Why this matters

A harness — a deterministic checklist applied every time — is how routine legal work gets cheap enough to reach the people priced out of it today.

Form a Nevada LLC from the command line

The same CLI forms a real Nevada LLC end to end — no browser — and downloads the filled official Nevada Secretary of State packet:

navigator site login --host https://your-firm.example
navigator site notation create nv__llc_formation --client-email libra@example.com
navigator site intake answer <notation-id>
navigator site notation status <notation-id>
navigator site notation approve <notation-id>
navigator site notation document <notation-id> --out llc.pdf

Walk a questionnaire like a text adventure

intake answer is a guided loop: it shows one question, you answer it, it shows the next — a text adventure through the matter's questionnaire.

navigator site intake answer <notation-id>

Your installation publishes its own schema

You do not need to read Rust to build against your matters. Your installation documents itself:

• https://<your-host>/app/api/openapi.json — the OpenAPI 3.1 document for every /app/api/* endpoint.
• https://<your-host>/app/api — the same document rendered as Swagger UI.

Sign in first, then open the second one. Then paste the first one into a coding agent and describe the screen you want.

Two doors — /api for a page, /mcp for an agent

Same database, same authorization, two shapes:

/mcp advertises fourteen tools, all namespaced aida_: aida_list_projects, aida_create_notation, aida_validate_notation, aida_answer_notation, aida_show_person, and the rest.

A first application is about fifteen lines

Point a fetch at your own host and read the tool catalog back:

const res = await fetch("https://<your-host>/mcp", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${token}`,
  },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "tools/list",
  }),
});

const { result } = await res.json();
console.log(result.tools.map((t) => t.name));

Swap tools/list for tools/call with {"name": "aida_list_projects", "arguments": {}} and you have your matters.

Vibe the screen — do not vibe the rules

Prototype freely on one side of the line, and call Navigator on the other:

• Vibe this. Layout, interaction, the empty state, the error state, what a report looks like when you print it.
• Call Navigator for this. Who may see it, what a valid notation is, what a signature means, what gets recorded.

Two rules travel with every prototype: no client data, ever — invented or firm-owned names only, and reserved example domains for any address — and your prototype is a specification, not a shipment.

Ship it as a Project's client portal

A React application can also live beside a matter, at a route Navigator owns:

/app/projects/<project-code>/portal/

One Project, one portal. The path is the Project code plus one literal segment, so the mount is derivable from the repository name alone — there is no application name for anyone to choose, register, or guess.

The line your application does not cross

Everything you build is a non-lawyer assistant under ABA Model Rule 5.3 — the same standing AIDA has. It may read, draft, summarize, and check your work. It does not:

• sign, file, or send;
• advance a workflow step;
• decide who may see a document.

Those are acts an attorney takes deliberately, through Navigator, which records that the attorney took them.