chandlery

Build for a firm's matters without being trusted with them.

An app is a small program a lawyer starts from the firm's workspace. It reads matters through five primitives, may ask a model through the firm's gateway, and may propose what a lawyer then accepts. Every line it can't cross is held by the platform, so you don't build any of them.

The SDK

Five read primitives, a way to propose, and a way to ask a model. The types are generated from the same schemas the services check every call against, and every refusal comes with a reason and a hint, so a coding model can write a correct app from the types alone.

src/module.ts
import { defineModule, z } from '@chandlery/sdk';

export default defineModule({
  name: 'delay-notices',
  version: '0.1.0',
  description: 'Every notice of delay in your matters, by date.',
  input: z.object({}),
  async run(ctx) {
    const rows: [string, string][] = [];
    for (const m of ctx.run.scope.matters) {
      // A walled matter answers empty, never with an error.
      const events = await ctx.query.extract({
        matterId: m.matterId,
        shape: 'events',
        kinds: ['notice_of_delay'],
      });
      for (const e of events.rows) {
        const date = String(e.date).slice(0, 10);
        rows.push([date, String(e.description)]);
      }
    }
    rows.sort((a, b) => a[0].localeCompare(b[0]));
    return {
      view: {
        title: 'Notices of delay',
        blocks: [
          { type: 'table', columns: ['Date', 'Notice'], rows },
        ],
      },
    };
  },
});

An app returns a view: tables, figures, notes and links to passages. The platform draws it in the firm's own screen, watermarked for whoever is looking. An app that reads matters never brings a front end of its own.

The brief

One page is the whole brief, written for you and for the coding agent working with you. It says what an app can do, what the platform guarantees, and what an app sees when it meets a wall: an empty answer, never an error to retry. You don't need the platform's internals.

The synthetic firm

Build against a firm that does not exist: invented matters, people and documents, rendered from an answer key, beside real public dockets. Every draft is checked there before anyone runs it on a real matter, and a builder never needs a firm's data.

The worst an app can do is waste its budget or be wrong.

Draft

A lawyer who doesn't write code describes the app in plain words. Draft writes it, the platform checks it on the synthetic firm, and Draft fixes what the checks found and reads what the app showed before handing it over. The lawyer then runs it on their own matters, which Draft never sees.

Someone technical can do the same with their own assistant, over a build channel that can keep a draft and never read an answer.

Sharing

  • With yourself. An app starts as its author's draft.
  • With the firm. Shared, it waits for someone allowed to take apps in, and then appears in everyone's apps.
  • With other firms. Apps, and frameworks such as elements, orders of proof and checklists, built at one firm and run at another, with no firm’s data leaving it. This is being designed.

A vendor ships to many firms the same way: each firm runs the app in its own instance, and the vendor never receives any firm's data.