@abloatai/ablo 0.50.0 → 0.52.0

package/docs/customer-organizations.md

@@ -0,0 +1,215 @@
+# Customer Organizations
+
+> Serve many customer organizations from one backend and one shared schema without weakening tenant isolation.
+
+An application serving many customers has two independent choices: where
+customer data is isolated and where the schema is authored. Ablo lets every
+customer keep a hard organization boundary while all of them use the schema
+pushed once by the owning project.
+
+## Choose the customer boundary first
+
+| Customer model | Isolation guarantee | Choose it when |
+|---|---|---|
+| One Ablo organization with customer scope roots | Whatever read boundary every model declares in `policy` | Cross-customer reads are intentional, or every model is explicitly and continuously policy-partitioned |
+| One Ablo organization per customer | Structural organization filtering and RLS on every row | Customers must stay isolated even when a model has no customer-specific policy |
+
+Sync-groups decide which changes are delivered. They do not, by themselves,
+authorize HTTP reads. If you cannot audit matching policies across every model,
+use one Ablo organization per customer.
+
+The rest of this guide uses organization-per-customer: one trusted backend
+holds one dedicated mint key, every customer has an `organizationId`, and each
+user session names that customer organization.
+
+## What you need
+
+- An owning project containing the schema every customer uses.
+- The schema pushed to that project's production root.
+- A server-side `sk_` carrying only `ephemeral:mint-any-org`.
+- A customer `organizationId` resolved from your authenticated application
+  membership, never accepted unchecked from the browser.
+- A model-by-model `can` grant for the UI being opened.
+
+The cross-organization key is a minting credential, not a tenant-data
+credential. Keep it in a secret manager and expose only your own authenticated
+session endpoint.
+
+## Mint on your backend
+
+Create the Ablo client once in server-only code:
+
+```ts
+import Ablo from '@abloatai/ablo';
+import { schema } from '@/ablo/schema';
+
+export const customerSessions = Ablo({
+  schema,
+  apiKey: process.env.ABLO_API_KEY,
+});
+```
+
+After your application authenticates the user, resolve the customer from that
+trusted membership and mint the session:
+
+```ts
+import { credentialEndpointSuccessSchema } from '@abloatai/ablo/auth';
+import { customerSessions } from '@/ablo/customer-sessions';
+
+export async function POST() {
+  const member = await requireSignedInCustomerMember();
+
+  const session = await customerSessions.sessions.create({
+    user: { id: member.userId },
+    organizationId: member.abloOrganizationId,
+    can: {
+      projects: ['read'],
+      records: ['read', 'create', 'update'],
+    },
+  });
+
+  return Response.json(
+    credentialEndpointSuccessSchema.parse({
+      token: session.token,
+      expiresAt: session.expiresAt,
+      credentialKind: 'ephemeral',
+    }),
+    { headers: { 'Cache-Control': 'no-store' } },
+  );
+}
+```
+
+Do not take `organizationId` directly from request JSON. A signed-in user could
+replace it with another customer's id. Derive it from the server-side membership
+you just authenticated.
+
+## Connect the browser
+
+The browser knows only your session endpoint. It never receives the
+cross-organization key:
+
+```tsx
+'use client';
+
+import Ablo from '@abloatai/ablo';
+import { AbloProvider } from '@abloatai/ablo/react';
+import { schema } from '@/ablo/schema';
+
+const ablo = Ablo({
+  schema,
+  authEndpoint: '/api/ablo-session',
+});
+
+export function Providers({ children }: { children: React.ReactNode }) {
+  return <AbloProvider client={ablo}>{children}</AbloProvider>;
+}
+```
+
+The client re-mints before expiry. Your endpoint should return
+`session_expired` only when the application's own login is gone; network and
+server failures are transient and must not sign the user out.
+
+## Schema and data stay on different axes
+
+For a cross-organization mint, Ablo derives the schema binding from the owning
+key automatically:
+
+```text
+owning key organization/project    -> schema shape
+customer organization              -> rows, RLS, database, sync groups
+session can                         -> allowed model operations
+model policy                        -> allowed reads inside that organization
+```
+
+Most applications should not pass a schema option. An explicit override exists for
+migrations or advanced routing:
+
+```ts
+await customerSessions.sessions.create({
+  user: { id: member.userId },
+  organizationId: member.abloOrganizationId,
+  schemaProject: {
+    organizationId: schemaOwnerOrganizationId,
+    projectId: migratingSchemaProjectId,
+  },
+  can: { records: ['read', 'update'] },
+});
+```
+
+Both schema coordinates move together; customer data does not move with them.
+
+## Customer lifecycle checklist
+
+When onboarding a customer:
+
+1. Provision or resolve its Ablo organization and store that immutable id on
+   your customer record.
+2. Connect that organization's production data source if it owns a separate
+   database.
+3. Keep the shared schema in the owning project; do not copy it into every
+   customer organization.
+4. Mint a test user session through the same backend route production uses.
+5. Verify one known read and write in the customer organization before enabling
+   the integration.
+
+When offboarding, stop minting immediately, revoke active sessions when an
+immediate cutoff is required, and retire the customer's data-source access
+through the control-plane process you use for provisioning.
+
+## Security checklist
+
+- Store the cross-organization key only in the backend secret manager.
+- Give it only `ephemeral:mint-any-org`; do not combine minting with schema or
+  data authority.
+- Resolve `organizationId` from authenticated membership server-side.
+- Keep `can` to the smallest model/verb set the UI needs.
+- Use organization-per-customer when a missing model policy must not expose
+  another customer's rows.
+- Rotate the cross-organization key on a schedule and after personnel or
+  infrastructure changes.
+- Record target organization, user, session id, and request id without logging
+  plaintext credentials.
+
+## Troubleshooting
+
+### The mint is forbidden
+
+The presenting credential must be a secret `sk_` with
+`ephemeral:mint-any-org`. A normal project key can mint users into its own
+organization but cannot name another one. Run `npx ablo whoami --json` in the
+backend environment to confirm which project and branch the configured key
+actually belongs to; the command never prints the full secret.
+
+### The session mints but bootstrap is empty
+
+Confirm that the cross-organization key belongs to the project where the schema
+was pushed, and that the customer's organization has its data source/root
+branch ready. Do not copy the schema into the customer organization. If you
+supplied `schemaProject`, remove it unless you intentionally override the
+owning-key default.
+
+### The mint reports an unknown model
+
+Every model named by `can` must exist in the active shared schema. Check the
+model key spelling against the schema used to construct `customerSessions`, then
+push that schema to the key's branch deliberately.
+
+### Data appears under the wrong customer
+
+Inspect the membership-to-`organizationId` lookup in your backend route first.
+The schema project never selects the data tenant. The `organizationId` passed to
+`sessions.create` does, and it must come from trusted server-side membership.
+
+### Realtime looks isolated but an HTTP read is too broad
+
+Sync-groups route changes; they are not a read policy. Add or correct the
+model's `policy`, or move customers to separate Ablo organizations when the
+boundary must hold structurally across every model.
+
+## Related guides
+
+- [Sessions](./sessions.md) — session lifecycle, refresh, revocation, and grants.
+- [API Keys](./api-keys.md) — credential classes, scopes, inspection, and rotation.
+- [Identity & Sync Groups](./identity.md) — participant delivery groups versus model read policy.
+- [Connect Your Database](./data-sources.md) — customer-owned database setup.
+- [Deployment](./deployment.md) — production schema and database rollout order.

package/docs/data-sources.md

@@ -149,8 +149,8 @@ own schema:
 ABLO_API_KEY="$MAIL_KEY" DATABASE_URL="$PRODUCTION_URL" \
   npx ablo connect apply --schema mail --yes
 
-ABLO_API_KEY="$SLIDES_KEY" DATABASE_URL="$PRODUCTION_URL" \
-  npx ablo connect apply --schema slides --yes
+ABLO_API_KEY="$ENTRIES_KEY" DATABASE_URL="$PRODUCTION_URL" \
+  npx ablo connect apply --schema entries --yes
 ```
 
 For a Neon or Supabase preview branch, use that branch's direct URL and keep the
@@ -380,7 +380,7 @@ export const ablo = Ablo({
 The API key still selects the project and branch; during `ready()` Ablo asks the
 server what the key actually targets and refuses startup when either coordinate
 differs. `ablo dev` writes all three values together, so accidentally exporting
-a slides key into the mail app—or a mail development key into production—fails
+a entries key into the mail app—or a mail development key into production—fails
 before any read, write, or subscription begins.
 
 The Ablo schema describes **only your synced, collaborative models** — the rows

package/docs/debugging.md

@@ -72,12 +72,12 @@ Precedence: an explicit `logLevel` wins, then `debug: true` (⇒ `debug`), then
 These lines (all at `info`) let you watch the handover you built:
 
 ```
-[Ablo] claim: requesting documents:doc_42 for "editing" (will queue if contended)
-[Ablo] claim: queued for documents:doc_42 — position 2 of 3, waiting
+[Ablo] claim: requesting records:doc_42 for "editing" (will queue if contended)
+[Ablo] claim: queued for records:doc_42 — position 2 of 3, waiting
 [Ablo] claim: granted 7f3c… — your turn (waited in queue)
-[Ablo] claim: rejected documents:doc_42 — held by agent_writer
-[Ablo] claim: lost documents:doc_42 (preempted or expired)
-[Ablo] claim: released documents:doc_42
+[Ablo] claim: rejected records:doc_42 — held by agent_writer
+[Ablo] claim: lost records:doc_42 (preempted or expired)
+[Ablo] claim: released records:doc_42
 ```
 
 Read it as the lifecycle of one claim:
@@ -189,7 +189,7 @@ function ActivityFeed({ log }: { log: ClaimLog }) {
 For **"who holds *this* row right now"** (a badge, not a feed), don't use `ClaimLog` — read the reactive claim state directly. It re-renders on change with no extra wiring:
 
 ```tsx
-const holder = useAblo((ablo) => ablo.documents.claim.state({ id }));   // Claim | null
+const holder = useAblo((ablo) => ablo.records.claim.state({ id }));   // Claim | null
 ```
 
 See [React](./react.md) and [Coordination](./coordination.md) for the claim-read APIs.
@@ -265,7 +265,7 @@ Every rejected live commit carries `requestId` on the thrown error and
 import { AbloError } from '@abloatai/ablo';
 
 try {
-  await ablo.documents.create({
+  await ablo.records.create({
     data,
   });
 } catch (error) {
@@ -289,7 +289,7 @@ evidence that the replication source has no history.
 Use:
 
 ```ts
-await ablo.documents.list({ type: 'complete' });
+await ablo.records.list({ type: 'complete' });
 ```
 
 `type: 'complete'` waits for a server round trip and returns the confirmed

package/docs/examples/agent-human.md

@@ -2,16 +2,16 @@
 
 > An agent that yields the row when a person is already holding it.
 
-A task-writing agent that yields when a person is editing the same task.
+A record-writing agent that yields when a person is editing the same record.
 
 ## Scenario
 
-The same tasks are edited by agents and by the people watching them. They must
+The same records are edited by agents and by the people watching them. They must
 not collide:
 
 - If a person already holds the row, the agent yields instead of fighting for it.
 - While the agent is updating, the UI can show who is active.
-- If the task changes mid-run, the commit is rejected instead of overwriting the
+- If the record changes mid-run, the commit is rejected instead of overwriting the
   newer edit.
 
 A **claim** does both jobs. Claims don't lock — if another writer holds the row,
@@ -24,9 +24,9 @@ a typed error if the row moved underneath you while the agent was busy.
 
 ## Schema-Backed Worker
 
-The worker uses the same schema client the app uses. It reads the task from the
+The worker uses the same schema client the app uses. It reads the record from the
 server with `get({ id })`, claims the row, and writes through
-`ablo.tasks.update(...)` with a stale-check so a concurrent edit can't be
+`ablo.records.update(...)` with a stale-check so a concurrent edit can't be
 overwritten.
 
 ```ts
@@ -34,7 +34,7 @@ import Ablo, { AbloClaimedError, AbloStaleContextError } from '@abloatai/ablo';
 import { defineSchema, model, z } from '@abloatai/ablo/schema';
 
 const schema = defineSchema({
-  tasks: model({
+  records: model({
     title: z.string(),
     status: z.enum(['todo', 'doing', 'done']),
   }),
@@ -46,19 +46,19 @@ const ablo = Ablo({
   transport: 'http',
 });
 
-export async function markDone(taskId: string) {
+export async function markDone(recordId: string) {
   await ablo.ready();
 
   // get({ id }) is an async server read — await it.
-  const task = await ablo.tasks.get({ id: taskId });
-  if (!task) return { status: 'not_found' };
+  const record = await ablo.records.get({ id: recordId });
+  if (!record) return { status: 'not_found' };
 
   try {
     // queue: false → don't queue behind a current holder. If another
     // participant holds the row, claim resolves null, so the agent yields
     // instead of waiting. Omit it, or pass queue: true, to queue behind them.
-    const acquired = await ablo.tasks.claim({
-      id: taskId,
+    const acquired = await ablo.records.claim({
+      id: recordId,
       queue: false,
       description: 'marking_done',
     });
@@ -72,7 +72,7 @@ export async function markDone(taskId: string) {
     // `onStale: 'reject'`. The write below is therefore equivalent to passing
     // those options yourself:
     //
-    //   ablo.tasks.update({
+    //   ablo.records.update({
     //     id: claim.data.id,
     //     data: { status: 'done' },
     //     readAt: <claim snapshot version>,
@@ -82,12 +82,12 @@ export async function markDone(taskId: string) {
     // If a newer version landed mid-run, the row no longer matches `readAt`, so
     // the server rejects this commit with AbloStaleContextError (caught below)
     // instead of clobbering that edit.
-    const updated = await ablo.tasks.update({
+    const updated = await ablo.records.update({
       id: claim.data.id,
       data: { status: 'done' },
     });
 
-    return { status: 'done', task: updated };
+    return { status: 'done', record: updated };
   } catch (err) {
     // The lease was lost or a foreign holder rejected the write.
     if (err instanceof AbloClaimedError) return { status: 'yielded' };
@@ -108,9 +108,9 @@ Keep workers on the same schema-backed client as the app.
 
 import { useAblo } from '@abloatai/ablo/react';
 
-export function TaskRow({ task: serverTask }: Props) {
-  const data = useAblo((ablo) => ablo.tasks.local.get(serverTask.id)) ?? serverTask;
-  const holder = useAblo((ablo) => ablo.tasks.claim.state({ id: serverTask.id }));
+export function RecordRow({ record: serverTask }: Props) {
+  const data = useAblo((ablo) => ablo.records.local.get(serverTask.id)) ?? serverTask;
+  const holder = useAblo((ablo) => ablo.records.claim.state({ id: serverTask.id }));
   const agentActive = holder?.participantKind === 'agent';
 
   return (

package/docs/examples/ai-sdk-tool.md

@@ -27,7 +27,7 @@ import { z } from 'zod';
 export const runtime = 'nodejs';
 
 const schema = defineSchema({
-  tasks: model({
+  records: model({
     title: schemaZ.string(),
     status: schemaZ.enum(['todo', 'doing', 'done']),
     summary: schemaZ.string().optional(),
@@ -40,15 +40,15 @@ const ablo = Ablo({
   transport: 'http',
 });
 
-const updateTask = updateTool(ablo.tasks, {
-  title: 'Update task',
-  description: 'Update a task without overwriting concurrent work.',
+const updateTask = updateTool(ablo.records, {
+  title: 'Update record',
+  description: 'Update a record without overwriting concurrent work.',
   inputSchema: z.object({
-    taskId: z.string(),
+    recordId: z.string(),
     status: z.enum(['todo', 'doing', 'done']).optional(),
     summary: z.string().optional(),
   }),
-  id: ({ taskId }) => taskId,
+  id: ({ recordId }) => recordId,
   apply: (current, { status, summary }) => ({
     status: status ?? current.status,
     summary: summary ?? current.summary,

package/docs/examples/existing-python-backend.md

@@ -95,7 +95,7 @@ export async function POST() {
   const userId = await currentUserId(); // your auth
   const { token, expiresAt } = await ablo.sessions.create({
     user: { id: userId },
-    can: { tasks: ['read', 'update'] },
+    can: { records: ['read', 'update'] },
   });
   return Response.json(
     credentialEndpointSuccessSchema.parse({

package/docs/examples/nextjs.md

@@ -21,11 +21,11 @@ app/
   api/
     ablo-session/
       route.ts              # mints a per-user ek_ token for the browser
-  tasks/
+  records/
     [id]/
       page.tsx              # RSC: get + render
       actions.ts            # Server Action: claim, then write
-      TaskEditor.tsx        # Client: live updates
+      RecordEditor.tsx        # Client: live updates
 lib/
   ablo.ts                   # Server Ablo client (holds ABLO_API_KEY)
   ablo.schema.ts            # shared schema
@@ -82,7 +82,7 @@ export async function POST() {
 
   const { token, expiresAt } = await ablo.sessions.create({
     user: { id: user.id },
-    can: { tasks: ['read', 'create', 'update'] },
+    can: { records: ['read', 'create', 'update'] },
   });
   return Response.json(
     credentialEndpointSuccessSchema.parse({
@@ -137,40 +137,40 @@ export default function RootLayout({ children }: { children: React.ReactNode })
 ## RSC Initial Render
 
 ```tsx
-// app/tasks/[id]/page.tsx
+// app/records/[id]/page.tsx
 import { ablo } from '@/lib/ablo';
 
-export default async function TaskPage({
+export default async function RecordPage({
   params,
 }: { params: Promise<{ id: string }> }) {
   const { id } = await params;
   await ablo.ready();
-  const task = await ablo.tasks.get({ id });
-  if (!task) return null;
+  const record = await ablo.records.get({ id });
+  if (!record) return null;
 
-  return <TaskEditor task={task} />;
+  return <RecordEditor record={record} />;
 }
 ```
 
 ## Server Action Commit
 
 ```ts
-// app/tasks/[id]/actions.ts
+// app/records/[id]/actions.ts
 'use server';
 
 import { ablo } from '@/lib/ablo';
 
 export async function markDone(id: string) {
   // Claim grants exclusive, ordered access and hands back the fresh row.
-  await using claim = await ablo.tasks.claim({ id });
+  await using claim = await ablo.records.claim({ id });
 
-  const task = await ablo.tasks.update({
+  const record = await ablo.records.update({
     id,
     data: { status: 'done' },
     claim,
   });
 
-  return { status: 'done', task };
+  return { status: 'done', record };
   // claim auto-releases as the action returns
 }
 ```
@@ -186,9 +186,9 @@ you — re-fetch and retry.
 
 import { useAblo } from '@abloatai/ablo/react';
 
-export function TaskEditor({ task: serverTask }: Props) {
-  const data = useAblo((ablo) => ablo.tasks.local.get(serverTask.id)) ?? serverTask;
-  const holder = useAblo((ablo) => ablo.tasks.claim.state({ id: serverTask.id }));
+export function RecordEditor({ record: serverTask }: Props) {
+  const data = useAblo((ablo) => ablo.records.local.get(serverTask.id)) ?? serverTask;
+  const holder = useAblo((ablo) => ablo.records.claim.state({ id: serverTask.id }));
   const busy = Boolean(holder);
 
   return (

package/docs/examples/scoped-agent.md

@@ -5,8 +5,8 @@
 You want an agent that edits **one workspace** and pushes realtime updates to the
 participants on **that workspace only** — not a broadcast to the whole org. The
 catch most people hit: which write reaches whom is decided by how the rows
-*relate*, not by which columns the write touched. So a task edit that never sets
-`workspaceId` still reaches everyone watching the workspace, because the task already
+*relate*, not by which columns the write touched. So a record edit that never sets
+`workspaceId` still reaches everyone watching the workspace, because the record already
 belongs to it. You get this by declaring the relationship once, then narrowing the
 agent to the workspace id — you never assemble a `workspace:<id>` audience string by
 hand.
@@ -27,9 +27,9 @@ export const schema = defineSchema(
       { title: z.string() },
       { groups: { root: 'workspace' } },
     ),
-    // A task has no group of its own. It inherits its workspace's group via the
-    // `parent` edge, so a task write reaches everyone watching the workspace.
-    tasks: model(
+    // A record has no group of its own. It inherits its workspace's group via the
+    // `parent` edge, so a record write reaches everyone watching the workspace.
+    records: model(
       { workspaceId: z.string(), title: z.string() },
       { relations: { workspace: relation.belongsTo('workspaces', 'workspaceId', { parent: true }) } },
     ),
@@ -67,7 +67,7 @@ const server = Ablo({ schema, apiKey: process.env.ABLO_API_KEY });
 export async function mintProjectAgentSession(workspaceId: string, agentId: string) {
   const { token } = await server.sessions.create({
     agent: { id: agentId },
-    can: { tasks: ['read', 'update'] }, // operation allowlist for this run
+    can: { records: ['read', 'update'] }, // operation allowlist for this run
     syncGroups: [syncGroup('workspace', workspaceId)], // narrowed to just this workspace
   });
   return token;
@@ -106,13 +106,13 @@ const ablo = useAblo();
 // Other participants subscribed to workspace:<workspaceId> — a reviewer agent, a
 // person watching in the UI — receive this delta in realtime. Participants on
 // other workspaces never see it.
-await ablo.tasks.update({ id: taskId, data: { title: 'Ship the Q4 report' } });
+await ablo.records.update({ id: recordId, data: { title: 'Ship the Q4 report' } });
 ```
 
-The task's delta is stamped `workspace:<workspaceId>`, derived server-side from the
-task → workspace `parent` edge — not from `workspaceId` appearing in this particular
+The record's delta is stamped `workspace:<workspaceId>`, derived server-side from the
+record → workspace `parent` edge — not from `workspaceId` appearing in this particular
 write, and not from whatever the agent happened to subscribe to. The routing is
-decided by the data: a task belongs to its workspace, so its writes go to the
+decided by the data: a record belongs to its workspace, so its writes go to the
 workspace's group, full stop.
 
 ## See also

package/docs/examples/server-agent.md

@@ -2,13 +2,13 @@
 
 > A stateless schema-backed worker: wake, claim, commit, go idle.
 
-A server agent is backend code — a cron job, a queue worker, an AI task — that
+A server agent is backend code — a cron job, a queue worker, an AI record — that
 reads and writes your app's records outside the browser. The hard part is doing
-it without racing whatever else is working: if two workers pick up the same task
+it without racing whatever else is working: if two workers pick up the same record
 at once, one write clobbers the other. This is what `claim()` is for.
 
 Agents hold no socket, so pass `transport: 'http'` and import the same schema the
-rest of the app uses. Below, a worker finishes a task by claiming it, writing the
+rest of the app uses. Below, a worker finishes a record by claiming it, writing the
 result, and releasing it automatically when the claim goes out of scope.
 
 `claim({ id })` takes the record for your worker and returns a disposable handle:
@@ -22,7 +22,7 @@ import Ablo from '@abloatai/ablo';
 import { defineSchema, model, z } from '@abloatai/ablo/schema';
 
 const schema = defineSchema({
-  tasks: model({
+  records: model({
     title: z.string(),
     status: z.enum(['todo', 'doing', 'done']),
     summary: z.string().optional(),
@@ -37,27 +37,27 @@ const control = Ablo({
 async function clientForWorker(workerId: string) {
   const { token } = await control.sessions.create({
     agent: { id: workerId },
-    can: { tasks: ['read', 'update'] },
+    can: { records: ['read', 'update'] },
   });
   return Ablo({ schema, apiKey: token, transport: 'http' });
 }
 
-export async function completeTask(taskId: string, workerId: string) {
+export async function completeTask(recordId: string, workerId: string) {
   // Participant identity comes from this worker-specific session. Two clients
   // made directly from the same root key are re-entrant, not contenders.
   const ablo = await clientForWorker(workerId);
   await ablo.ready();
 
-  const task = await ablo.tasks.get({ id: taskId });
-  if (!task) return { status: 'not_found' };
+  const record = await ablo.records.get({ id: recordId });
+  if (!record) return { status: 'not_found' };
 
-  const acquired = await ablo.tasks.claim({
-    id: taskId,
+  const acquired = await ablo.records.claim({
+    id: recordId,
     contention: {
       mode: 'skip',
       onStatus(event) {
         if (event.type === 'skipped') {
-          console.info('task already owned', event.error.code);
+          console.info('record already owned', event.error.code);
         }
       },
     },
@@ -66,12 +66,12 @@ export async function completeTask(taskId: string, workerId: string) {
   if (!acquired) return { status: 'already_claimed' };
 
   await using claim = acquired;
-  const updated = await ablo.tasks.update({
+  const updated = await ablo.records.update({
     id: claim.data.id,
     data: { status: 'done' },
   });
 
-  return { status: 'done', task: updated };
+  return { status: 'done', record: updated };
   // claim auto-releases as the function returns
 }
 ```
@@ -97,7 +97,7 @@ schema-backed client:
 ```ts
 await ablo.commits.create({
   operations: [
-    { action: 'update', model: 'tasks', id: 'task_123', data: { status: 'done' } },
+    { action: 'update', model: 'records', id: 'record_123', data: { status: 'done' } },
   ],
   wait: 'confirmed',
 });