Event keys.

An administrator changes an existing team member's office role to a different non-empty role.

An office role is granted to an email/account, either when an administrator adds or promotes a team member, or when the first local super admin is bootstrapped on sign-in.

An administrator removes a team member's office access entirely, dropping their role to none.

The agent (with staff approval) records a verification for a client and marks it verified immediately, capturing the verifying staff actor.

A first-time client signs in with Google and a brand-new account is auto-created for them, leaving a self-serve signup trail attributed to the new account itself.

Two duplicate accounts are merged into one (via the office accounts UI or the agent), folding the newer loser account into the older winner.

An account is soft-deleted by the agent (via the generic deleteRecord op or the dedicated deleteAccount tool), hiding it from every office view while remaining restorable.

An account-scoped email fails to send because the email provider returned an error or the send threw.

An account-scoped email (e.g. a verification-request email to a client) is successfully delivered via the email provider.

An account-scoped email is not actually delivered because email delivery is in dry-run/skip mode.

The super admin begins impersonating an office account, setting the impersonation cookie so the office subtree renders as that account.

The super admin ends an active impersonation session, clearing the impersonation cookie and returning to their own identity.

The agent (with staff approval) changes a client's standing to neutral or blacklist, where blacklist blocks the client from future rentals.

Staff save edits to a client's profile in the office (display name, phone, locale, standing, company, tax id, tags, or internal notes) and at least one field actually changed.

Staff approve a pending verification, recording the approving actor and an approval note on the account's verification.

A verification record is soft-deleted (archived) for an account, removing it from the active verification set.

Staff reject a pending verification, clearing its verifier and recording the rejection note.

A verification record (email, phone, or ID document) is created for an account, marking that the client has been asked to verify that item.

A staff member (or agent) marks one or more gear units unavailable for a date range; one log row records the whole batch, keyed to the parent item.

A staff member (or agent) removes an asset (gear unit) blackout; the row is hard-deleted and its prior contents are captured in the log payload.

A new physical unit row is inserted into the inventory table (named assets after the 0002 units-to-assets rename), logged automatically by the unit log trigger.

A physical unit row is hard-deleted from the inventory table, logged automatically by the unit log trigger with the removed row in the payload.

A physical unit row's fields change (e.g. status, condition, location), logged automatically by the unit log trigger with the old and new row in the payload.

A damage or loss claim is filed against a reservation by staff or the agent, opening it in the notified state.

The agent moves an existing claim to a new status (draft, notified, accepted, disputed, or closed), with closing the last open claim potentially settling the reservation.

The agent (with staff approval) updates a client's internal file, replacing the internal notes and/or tags on their client profile.

A condition photo is uploaded and attached to a draft outbound or inbound inspection report (creating the draft if the photo arrives first).

A client signs an outbound or inbound inspection asset report, locking that report and storing the captured signature.

An executed contract PDF is uploaded for a reservation, pointing the reservation at the new file and recording whether it replaced a prior one.

A staff member selects a different copy variant for a marketing-site section, appending a new copy.variants setting revision recording which registry-validated variant that section key renders.

An attempt to send a reservation email errors out (Resend returns an error or rendering throws); the failure is reported and logged but never breaks the reservation transition.

A transactional rental email tied to a reservation is successfully delivered via Resend during a reservation lifecycle transition.

A reservation email is intentionally not sent because delivery is in safe/dry-run mode (no API key, EMAIL_DRY_RUN on, or off-production), so its payload is logged instead of mailed.

The AI agent creates a Google Doc with a title and content via its googleDocCreate tool (a staff-approved write action).

The AI agent overwrites a range in a Google Sheet via its googleSheetWrite tool (a staff-approved write action).

A new inventory item (catalog SKU) row is inserted, logged automatically by the items log trigger.

An inventory item row is hard-deleted, logged automatically by the items log trigger with the removed row in the payload.

An inventory item row's fields change, logged automatically by the items log trigger with the old and new row in the payload.

A new kit (a bundled set of inventory) row is inserted, logged automatically by the kits log trigger.

A kit row is hard-deleted, logged automatically by the kits log trigger with the removed row in the payload.

A kit row's fields change, logged automatically by the kits log trigger with the old and new row in the payload.

A staff member soft-deletes a lead (via the lead view or the /office/tables console), hiding it from every office view while keeping it recoverable.

A staff member posts an internal comment on a lead (leads are internal-only, so there is no visibility flag).

A staff member creates a lead (inquiry) in the office, resolving its contact account and interest tags.

A staff member permanently deletes an already-archived lead from the /office/tables console (a hard delete that only ever removes a soft-deleted row).

A staff member restores a previously archived lead from the /office/tables console, clearing its deleted_at and bringing it back into office views.

A staff member adds or removes interest tags on a lead, changing which categories it carries.

A staff member edits a lead's referrer, budget amount, or budget currency.

A payment (deposit hold, capture, balance, or refund) is recorded against a reservation by staff or the agent, which can also advance the reservation's lifecycle.

A quote is sent to the client and an immutable pending snapshot of the quoted amounts and channels is recorded for the reservation's quote history.

The reservation's open pending quote reaches a terminal status, set to accepted when the client accepts in the portal, rejected when the client requests a change, or cancelled when the reservation is cancelled.

A reservation is soft-deleted (from the tables console or by the agent), hiding it from every office view while keeping it restorable.

A unit is scanned out on the staff app during pickup, binding the asset to the reservation (the first scan stamps the actual pickup time).

A unit is scanned in on the staff app during return, releasing the asset and possibly advancing the reservation toward returned/settled/closed.

An internal or client-visible comment (including the create form's notes) is added to a reservation, recording its visibility.

A new reservation is created (via the desk create form or the agent), born in the drafted stage with its reference and line count.

A reservation's pickup/return window is edited while it is still unlocked, after which its pricing is recomputed for the new rental days.

An item or space line is added to a reservation's cart, after which its pricing is recomputed.

The quantity on a reservation line is changed, after which its pricing is recomputed.

A line (or all lines of an item/space) is removed from a reservation's cart, after which its pricing is recomputed.

The system cron detects a confirmed reservation past its return time plus grace period and flags it overdue once, recording an advisory late-fee estimate.

An already-archived reservation is hard-deleted forever from the archived view in the tables console.

Staff (or the agent) sends a quote to the client over the selected channels, snapshotting the quoted amounts as a pending quote in the reservation's history.

A previously archived reservation is restored from the tables console (or by the agent), bringing it back into office views.

A reservation advances or moves through its lifecycle (drafted -> quoted -> accepted -> confirmed -> returned -> settled -> closed, or to cancelled), recording the from/to stages of the transition.

A super admin overrides a lifecycle gate to push a reservation to a stage the normal flow can't reach, logged separately with the override reason alongside the standard status-change row.

The document templates for a reservation are set to system, group, or custom mode, replacing its prior template picks.

Staff remove a previously selected unit from a reservation line (only allowed while that unit is not physically out).

Staff assign a specific physical asset (unit) to a reservation line at the desk, recording any serial captured for it.

Staff trigger auto-assign to fill a reservation's remaining selection slots with free serviceable units.

A new settings key/value revision row is inserted (every pricing, schedule, hero, or rollback save appends a row), fired automatically by the setting_log database trigger since the settings table is append-only.

An office settings row is hard-deleted, logged automatically by the settings log trigger with the removed row in the payload.

A staff member rolls a setting back to an earlier revision from the pricing history page, which inserts a fresh row copying the older value (the rollback is itself reversible).

A staff member saves a settings change in the office (pricing config, the home hero/appearance editor, or the studio schedule), recorded at the application level with the changed keys and a note.

An office settings row is changed, logged automatically by the settings log trigger with the old and new values; this is how pricing, schedule, and appearance edits are recorded.

A staff member soft-deletes a link (from the links console or /office/tables), making the code 404 on scan while keeping it recoverable.

A staff member creates a link / QR redirect in the /office/links console, either with a supplied code or an auto-generated one.

A staff member expires a link immediately from the /office/links console, setting its expiry to now so the code stops resolving.

A staff member permanently deletes an already-archived link from the /office/tables console (a hard delete of a soft-deleted row).

A staff member restores a previously archived link from the /office/tables console, bringing the code back into service.

A staff member edits a link's target URL or expiry in the /office/links console (a no-op when neither changed; asset-bound codes are administrator-only).

A staff member (or agent) takes a space out of supply for a date range, recording the blackout against that space.

A staff member (or agent) removes a space blackout; the row is hard-deleted and its prior contents are captured in the log payload.

A staff member creates a rentable space (studio/location) in the spaces admin, including its rates, deposit, and availability.

A staff member edits an existing space's details in the spaces admin (skipped as a no-op when nothing actually changed).

The AI agent runs a read-only SQL statement against the live database via its sqlQuery tool; every query is logged verbatim along with the row count returned.

Two tags are merged via the office tags UI, repointing every lead from the newer loser tag onto the older winner tag and soft-deleting the loser.

A staff member creates a new named communication template for a type, adding it alongside that type's seeded default.

A super admin promotes a named template to be its type's system default, repointing render-time resolution to it.

A staff member saves a new EN or ES version of a template and promotes it to be the active (live) version for that template and locale.

A staff member saves a new EN or ES body/subject version of a template as a draft without making it the live one.

A staff member creates a new named template group (a reusable set of per-type template picks).

A staff member soft-deletes a template group, hiding it from listings while preserving any reservation that referenced it.

A staff member edits a template group, replacing its name and its type-to-template mappings.

A staff member generates a QR link for a physical unit, auto-minting a code that resolves to the unit's office page.

A staff member manually binds a specific (re)entered link code to a physical unit, e.g. when transferring an existing sticker.