LatticeKit
Rb
Reference

Reference

Runbooks

The operational jobs an operator actually has to do, end to end: standing a business up, bringing data across, going live on payments, opening a second location, connecting an agent, changing configuration reversibly, and closing a period.

Scope: these describe what the platform does and the order it does it in, not a click path — console screens change faster than mechanisms do. Each runbook links to the primitive that owns it. Where something is designed but not built, it says so.

The runbooks

Stand up a new business from a starter

You have a business and no configuration yet. Rather than building schedules, resources, offers and a price list from nothing, start from a worked example and change what differs.

  1. Pick a starter. Four ship today — racquet club, gym, salon, studio. They are shaped differently on purpose: the racquet club books resources by the hour, the gym runs a timetable needing a room and a trainer, the salon has two appointment lengths where the long one takes a deposit, and the studio is capacity-shaped rather than resource-shaped. Pick the one whose shape matches, not the one whose industry matches.
  2. Fill in the variables. A starter asks for the handful of things it cannot guess — business name, timezone. An unset variable is refused rather than left blank: a schedule anchored to an empty timezone is wrong in a way nobody notices until a booking lands at the wrong hour.
  3. Review the plan. A starter is an ordinary configuration bundle, so applying one produces the same reviewable plan as any other change: what will be created, what will be updated, what would be removed.
  4. Apply, then prove it. Each starter carries a scenario as its acceptance test. Run it and you get a structured verdict on whether the business actually works — resources to book, an offer to book them under, a customer record to book them for — with every side effect neutralised, so nothing real is sent, charged or reserved.
  5. Change what differs. From here the starter is not special. It is your configuration, and it edits, exports and rolls back like anything else.

Worth knowing: Nothing about a starter is privileged once applied. If none of the four fit, start from the closest and edit — that is cheaper than an empty tenant. Reference: Pirenne.

Bring your data over from an existing system

You are switching from another platform and have customers, staff, resources and a catalog to move. The import engine is built for exactly this: a whole export from your old system, not a hand-cleaned spreadsheet.

  1. Upload the export. CSV, JSON and XLSX are read directly, and a ZIP is enumerated so a whole legacy-system export becomes a set of importable files in one upload. Files go straight to storage via a presigned upload — the application never proxies the bytes.
  2. Let the mapping be proposed. Rather than mapping columns by hand, the uploaded files are read against a typed catalogue of what can be imported, and a per-file target and field mapping is proposed. You review and edit it per file.
  3. Dry-run the import. A preview exercises the identical path with nothing written: full validation, row counts, and per-row errors. Fix the mapping and preview again until the errors are ones you accept.
  4. Run it. The run streams rows through the mapping and writes through each primitive's normal write surface — the same rules a single record would hit apply to a hundred thousand. Idempotency keys derive from the source row identity, so a re-run does not duplicate.
  5. Import files that reference each other. Where file two references file one's identifiers — customers and then their bookings — an identity map remaps the old system's ids onto the records the earlier run created, so multi-file imports stay linked.

Worth knowing: Imports do not bypass validation. If your old data violates a rule the platform enforces, the import surfaces it per row rather than quietly accepting it — which is usually the first honest audit of that data anyone has run. Reference: Korell.

Take payments live

You have been running in test mode and want to charge real cards. The path is deliberately a gated sequence rather than a switch, because the failure modes here are expensive.

  1. Create the live configuration, inactive. A live processor configuration is born unverified and cannot be created already active — that attempt is refused outright. Create it first, prove it second, use it third.
  2. Let the key check itself. Key prefixes must agree with the declared mode at write time. A test key pasted into a live configuration, or the reverse, is rejected on the spot rather than discovered on the first real charge.
  3. Verify the credentials. Verification exercises the credential against the processor before anything depends on it, so an activation cannot succeed on a key that was never going to work.
  4. Activate and cut over. Activation is a separate, explicit act on a configuration that is already verified. Webhook endpoints are wired so processor-side events — captures, refunds, disputes — flow back in signature-verified and deduplicated.
  5. Watch the first live charges. Disputes arrive as first-class records with evidence submission, and refunds are capped against what was actually captured rather than what was requested.

Worth knowing: Card data never reaches the platform. Collection is processor-hosted and the platform stores tokens only — a posture that only holds while it is never violated, which is why there is no code path that accepts a raw card number. Reference: Payments.

Add a second location

One business, more than one place. The model is a sub-tenant scope on the rows themselves rather than a second tenant, so a location shares a catalog, a customer base and a ledger without sharing a schedule.

  1. Decide what is shared and what is not. Each kind of record is classified as location-private or tenant-shareable. A schedule is private to the place it happens; a product is normally shared. The classification is per record type, not per row, so the answer is consistent.
  2. Choose a scoping mode. A lenient mode lets tenant-wide records be seen from within a location; a strict mode does not. Strict is the stronger isolation and the more surprising one — pick it deliberately.
  3. Give operators a scope. An operator working at one location sees that location. Reads are filtered by a central scoper and writes are checked by a guard, so a location-scoped operator cannot read or write across the boundary even where a screen would otherwise let them.
  4. Check the reports. Reporting and realtime channels are keyed by tenant and sub-tenant together, so per-location figures are the default rather than something to be filtered for afterwards.

Worth knowing: Sub-tenant scoping is a real boundary, not a display filter. Adding it later to a busy tenant means deciding a scope for existing rows, so it is much cheaper to turn on before the second location opens than after. Reference: Demerzel.

Connect an AI agent

You want an assistant — yours or a customer-facing one — to work against your business rather than just talk about it.

  1. Approve the connection. The client asks; you see a consent screen naming it and choose what it gets. The grant is yours, and revoking it does not require rotating any credential.
  2. Choose the scopes deliberately. Read access covers roughly a hundred capabilities and is the right default. Write access unlocks only the repetitive tier — check-ins, attendance, form submissions — and nothing else.
  3. Decide what it may merely ask for. Granting the propose scope lets an agent request a consequential action without performing it. The request lands in an approval inbox with what it would do and what it would cost; a person decides.
  4. Bound it. Set daily ceilings on calls and money, so an agent stuck in a loop is limited by policy rather than by whoever notices first. A grant can also be marked sandbox-only, which forces neutralised side effects server-side — a good way to let something prove itself before it is trusted.
  5. Watch it. Every call is audited against the grant. The activity feed shows what agents are doing, and a grant can be stopped at any point.

Worth knowing: An agent can never reach an action you could not, nor reach it under weaker rules — it runs through the same checks your own console does, with the grant applied on top. Full contract on the Agent API page. Reference: Gaal.

Make a configuration change you can undo

You want to restructure pricing, add a schedule, or change a policy — and you want to see exactly what will happen first, and be able to reverse it.

  1. Export what you have. The current configuration comes out as one portable document. This is also your backup: keep it before you change anything.
  2. Edit and plan. Compare the edited document against what is live. The plan is the minimal difference — creates, field-level updates, deletions — with hard-to-take-back changes flagged and explained. Producing a plan writes nothing.
  3. Pin the plan you reviewed. Pinning stores the plan exactly as shown. Applying a pinned plan executes that plan or refuses — it cannot quietly do something different because the tenant moved underneath it.
  4. Apply. The apply is transactional and lands in a history with a digest, counts, who did it, and the plan it came through.
  5. Roll back if it was wrong. An earlier document can be re-applied from the history.

Worth knowing: The same mechanism is what makes an agent safe to let near a configuration: it proposes a document you read, not a sequence of writes you supervise. Reference: Pirenne.

Close an accounting period

Month end. You want the books fixed, the receivables understood, and the numbers out to whoever does your accounting.

  1. Check what is outstanding. An accounts-receivable aging report shows what is owed and how late it is, before anything is closed.
  2. Issue statements. Customer statements are generated from the same ledger the invoices posted into, so a statement and an invoice cannot disagree.
  3. Reconcile the exceptions. Credit notes, refunds and reversals are ordinary double-entry postings rather than adjustments layered on top — so the corrections are visible in the journal rather than hidden in a balance.
  4. Close the period. A fiscal period moves to closed. Everything posted is a balanced double-entry journal, which is what makes closing meaningful rather than cosmetic.
  5. Export. Ledger data exports as CSV for your accountant or accounting package.

Worth knowing: Export today is CSV. A live two-way sync with accounting software is designed but not built — if that is load-bearing for you, plan around the CSV path. Reference: Mallow.