Concept Catalog

Generated from the live DSL by cmd/docs-gen -- do not hand-edit. A MemQL node is an instance of one of these concepts; each concept's fields below are its schema.

Total: 246 concepts.

#v1:accounts:account

An organization: the cluster operator's own company or one of its clients. The engine admits authorized organization members and cluster operators. Creating/archive operations remain cluster-operator decisions; scoped client administration never becomes cluster administration.

Relationships: parent -> v1:identity:user

#v1:actions:action

A reusable, replayable library entry minted from a candidate trace (Phase 1, #1736). A primitive stores one or more captured capability calls with literal args, keyed by inputFingerprint, and replays them token-free on identical input against the default surface. Reliability rises on verified replay; mismatches fall back to the LLM.

Relationships: parent -> v1:identity:user

#v1:actions:surface

A registered execution surface for action replay (Phase 2, #1737): workbench / computer-use:<machineId> / mcp:<server>, with its served capability verbs + current availability. The resolver binds capability->surface per world group with explicit > policy > availability precedence (decision A pins coupled actions to one surface).

Relationships: parent -> v1:identity:user

#v1:agents:agent

System-level AI assistant templates with configurable capabilities, personalities, and provider settings. Global-scoped: lives in _system alongside v1:identity:user, since per-user platform agents (assistant, plannerAgent, trainerAgent) are infrastructure that every tenant sees the same way -- keyed by ownerUserId payload field, addressed canonically as _system:v1:agents:agent:<seedName>-<userShortId>.

Relationships: parent -> v1:identity:user, references -> v1:identity:identity, createdBy -> v1:work:run, references -> v1:agents:agent

#v1:agents:agentAuthorization

Standing authorization granting an agent permission to trigger Plans of certain kinds without per-Plan user approval. Per Q4 Option B (tiered trust + opt-in autonomy): agent-proactive Plans default to 'requires user approval' (canvas suggestion card -> click Approve to start); the user can graduate a specific agent to standing authorization for specific plan kinds via the 'Approve & always allow this' button on the suggestion card. The grant is per (agentId, planKind, spaceScope) and carries a per-grant token budget cap + an expiry so autonomy is bounded by default. ROW AUTHZ (memql#3177, carrying memql#3129 + memql#3138). The tier below is what makes this concept's long-standing "only the granting user can revoke" claim a fact rather than a comment. Three things had to be true at once and now are: 1. the tier is DECLARED here, so #3174's write guard resolves the target row and refuses revokeAgentAuthorization / updateAgentAuthorization / updateAgentAuthScope when the row's userId is not the caller's; 2. userId is SERVER-STAMPED on every write that touches it (createAgentAuthorization stamps it; updateAgentAuthorization re-stamps it over its payload splat), so a caller cannot rewrite the field the tier is keyed on -- the two-call escalation memql#3138 documented; 3. the READ is caller-scoped (agentAuthorizationsForSelf), so the grants cannot be enumerated for a stranger either. Dropping any one of the three reopens the other two: an unstamped userId defeats the guard from inside a row the attacker legitimately owns, and an unscoped read hands out the ids the guard is asked about.

Relationships: parent -> v1:agents:agent, parent -> v1:identity:user

#v1:agents:agentRole

First-class catalog of agent roles. A role is the spine of an agent's identity: it picks the locked minimum skills (knowledge + tool + live-source bundles), declares the recommended LLM policy, and caps how many skills an agent in the role may carry at once. The role is the contract the assistant fulfills when it auto-creates a specialist mid-conversation -- pick the role, copy its locked + default skills onto the new agent, materialize the row. Lock semantics (#158): lockedSkillIds is the minimum required set for any agent carrying this role. The cockpit's Studio renders locked rows with a lock icon; updateAgent rejects writes that strip a locked id (server-side enforcement, not just UI). defaultSkillIds is pre-selected when the agent is created but the user / planner may remove them later. forbiddenSkillIds hard-denies skills the agent factory MUST NOT grant. availableSkillIds (when non-empty) is the inclusive 'visible in the picker' set; empty = anything not forbidden is permitted. maxSkills caps the count -- 5 for specialists, 2 for the assistant by default. Predefined rows are re-seeded on every startup; user-created roles default to predefined=false and stay fully editable. Predefined rows are locked on the write path by validateAgentRolePredefinedLock, which mirrors the v1:rbac:role guard: a non-system actor cannot modify one at all, and cannot mint a new predefined row (memql#2985). The SeedMaterializer re-materializes them on every startup, so an edit would not survive a boot in any case. Per-user roles are global-scoped because routing decisions need to see the same role surface across every partition; that makes one user's custom role visible to every caller -- a known trade rather than an oversight, with the scoped alternative written down. See the note above activeAgentRoles in dsl/agents/queries.memql.

#v1:agents:operatorMemory

Session-scoped memory for UI-driving agents. One record per user; accumulates short notes across takeovers so the operator agent can learn the user's app usage patterns and shortcut repeat work.

Relationships: parent -> v1:identity:user

#v1:agents:skillChangeEvent

Append-only audit log for every skill attach / reconfigure event on an agent. Mirrors v1:knowledge:validationEvent: denormalized state lives on the agent row for fast queries; this event log carries the per-mutation history the planner trace viewer (cockpit#125) and audits replay against. Two writes per attach (the agent row update + the event row); cheap. Phase 1 lands the concept; Phase 2 starts writing rows from the agent factory. detached is reserved for a future phase -- v1 is append-only because no consumer currently reads the negative path.

Relationships: references -> v1:agents:agent, references -> v1:skills:skill, references -> v1:agents:agent, parent -> v1:identity:user, references -> v1:work:run

#v1:authoring:bundle

An atomic, versioned unit of planner-authored DSL: one automation plus the dependency closure it needs (logic / shapes / specs / traits / policies / mutations / queries / prompts), compiled from a user Responsibility. The bundle is the unit of validation and activation -- the whole closure passes Gate 1 (isolated compile+bind), Gate 2 (tiered behavioral dry-run), and Gate 3 (user approval) together, then activates together into the sandboxed authored-construct runtime (#959). Never part of the core engine Init() path, so a malformed bundle can never brick the cluster. Member constructs are v1:authoring:construct rows pointing back via bundleId.

Relationships: parent -> v1:identity:user, parent -> v1:planner:responsibility, references -> v1:work:run, references -> v1:authoring:bundle

#v1:authoring:construct

One authored DSL construct that is a member of a v1:authoring:bundle: the .memql source for an automation / logic / shape / spec / trait / policy / mutation / query / prompt, plus its cached compiled form. These are the NET-NEW constructs the planner authored because nothing existing fit (compose-first, author-the-gap); reused constructs are recorded on the bundle's reusedConstructRefs instead. After a bundle activates, a construct can be promoted into the per-owner reusable catalog (catalogued=true) so later bundles compose it -- the catalog match key lives in catalogKey (#957).

Relationships: parent -> v1:identity:user, parent -> v1:authoring:bundle, references -> v1:authoring:bundle

#v1:authoring:dependencyEdge

One dependency edge in a bundle's construct graph (epic memql#954, issue #957). Construct fromConstruct (kind fromKind) in bundle bundleId depends on construct toName (kind toKind), which resolves from toSource (core = sealed engine, catalog = the owner's reusable catalog, bundle = bundle-local). Edges are recorded at compile time so the catalog can run IMPACT ANALYSIS -- 'which bundles depend on this construct' -- before a shared / cataloged construct changes. This is the reuse-coupling mitigation from the design doc: editing a cataloged construct re-validates its dependents.

Relationships: parent -> v1:identity:user, parent -> v1:authoring:bundle

#v1:authoring:ladderPolicy

The certification ladder's VALUES (epic memql#5408): how many shadow matches, across how many distinct bindings, earn a learned procedure its promotion proposal; how many clean canary replays make it trusted; how many failed replays -- or replays whose preconditions proved insufficient -- demote it; and how many days of disuse retire it. They are rows rather than constants so a person can read the numbers the ladder is applying, and so the Go that applies them carries the same numbers only as component/work.DefaultLadderPolicy() for an absent or unreadable row. ONE ROW, AT A LITERAL ID: v1:authoring:ladderPolicy:primary, written by seed ladderPolicy primary (dsl/authoring/seeds.memql) through createLadderPolicy. A global seed is re-asserted on every boot on every node, fields the seed declares winning, so the row is refreshed the way the cluster singletons are and an edit made anywhere else does not survive a restart. Every read pins the literal id, so a stray row at any other id is never mistaken for the policy. TIER: @rowAuthz(clusterOwner, rankFloor="reader") -- every signed-in person READS it, and the WRITE stays where the cluster-owner tier puts it: the cluster owner, or trusted server-side Go stamping internal origin (the seed materializer), with createLadderPolicy @serverOnly in front of that. There is no owner field because the numbers are the deployment's, not anybody's. The floor names reader and not viewer, although the two are one rung (rank 50, the lowest predefined one): reader is viewer's alias, and it is the spelling the ENGINE'S COMPILED LADDER answers (component/auth.RoleRank) as well as the seeded catalog. The load-time floor check runs at Init, before the rbac catalog is readable on a fresh cluster and with no database at all under memqllint, and there viewer would rank 0 and refuse the declaration. So the floor admits every predefined role; the one caller it refuses is a custom role authored BELOW viewer, whose holder reads nothing -- and the Go reader treats a row it cannot read as absent and applies the defaults, which are the numbers this seed carries. Every value is at least 1 (the schema refuses anything lower), so the row a person reads on Settings is always the row the ladder applies; Go's normalization of a non-positive value to its default exists only for the row that is absent.

#v1:bench:run

One invocation of the proving suite. Written by memql-bench --do=run, once per run, before any sample. CLUSTER-OWNER TIER WITH A READ FLOOR AT ADMIN (memql#5216), and it has no owner field at all. A benchmark is a fact about the DEPLOYMENT rather than about a person: there is nobody whose row this is, so the composite owner=..., clusterOwner form other operator surfaces use would have an owner key that nothing could ever fill. THE FLOOR RELAXES THE READ AND LEAVES THE WRITE WHERE IT WAS, and that asymmetry is why it exists. clusterOwner alone said two things at once -- only the deployment writes these, AND only the cluster owner reads them -- and the second was never intended. MemQL OS surfaces these rows at Settings -> Benchmarks with roles: { min: "admin" }, so a non-owner admin was admitted to the screen and served nothing. On a surface built so that an absence takes the same room as a number, that refusal rendered as UNMEASURED: a permission answer wearing the costume of a measurement, on the one screen whose design principle is that an absence must be legible. EVERY MUTATION BOUND TO THIS CONCEPT IS @serverOnly, and that is the load-bearing part. These rows are what the README's published claims rest on (the claims gate in scorecard/claims.go checks a marked claim against the committed scorecard), so a client-reachable write here would be a primitive for forging the numbers the product is sold on. The writer stamps internal origin and takes an entry in call_origin_conformance_test.go's allowlist saying exactly that.

#v1:bench:sample

One published figure: a metric, on one arm, for one scenario. A SAMPLE CARRIES EITHER A STATISTIC OR AN ABSENT REASON, NEVER BOTH AND NEVER NEITHER. That invariant is enforced in Go by component/proving/figure before a row is composed, and it is why absentReason is a first-class field rather than an empty median: a run whose provider-call count could not be measured and a run that genuinely made zero provider calls are different answers, and a schema that could only say "0" would collapse them. There is deliberately NO mean field, and no single-number form. The epic's honesty rule is medians and spread, never a best case, and a schema that offered a bare number is a schema somebody would eventually publish from.

Relationships: parent -> v1:bench:run

#v1:calendar:booking

A booking taken against published hours (memql#4142). Owned by the host so the portal's host calendar is the operations surface. Booker identity is payload (name + email), not a second owner. Cancel and reschedule append a new version of this id -- there is no silent overwrite of history.

Relationships: parent -> v1:identity:user, references -> v1:calendar:bookingHours, references -> v1:calendar:booking

#v1:calendar:bookingHours

Weekly booking hours a client owner publishes (memql#4142). Calendly-style availability without a Calendly bill or a new SPA. Config is data -- flipping published does not require a rebuild. Per-row authz: owned by the host.

Relationships: parent -> v1:identity:user

#v1:calendar:calendarEvent

A single calendar event owned by one user. The app-native source of truth for that user's schedule (#642): the reactive harness's reminder triggers read upcomingEvents over these rows ('remind me the day before X'), and the calendar tool/skill lets agents create + list + edit them. source discriminates native (first-party, the only writer in v1) from externalSync (a future Google/CalDAV sync, which would stamp externalRef back to the upstream event id; no sync path exists today). recurrence is an optional RFC-5545 RRULE string carried verbatim for v1 -- expansion into concrete occurrences is a downstream concern, not stored here.

Relationships: parent -> v1:identity:user

#v1:campaigns:audience

A named set of email recipients -- the WHO of a campaign. Audiences are authored in the portal and referenced by campaigns; membership lives on v1:campaigns:recipient rows pointing back here rather than as a list on this row, so a hundred-thousand-address audience is a hundred thousand rows rather than one enormous payload. Per-row authz: owned -- ownerUserId is stamped from actor.userId on every write and every read gates on row.ownerUserId == actor.userId.

Relationships: parent -> v1:identity:user, references -> v1:accounts:account

#v1:campaigns:campaign

A campaign: one template addressed to one audience, optionally at a scheduled time, plus the state of its send. This is the row an operator thinks of as 'the campaign'. Per-row authz: owned. The send-state fields (startedAt / completedAt / the three counters / lastError) are written by the sending engine's drain worker through updateCampaignProgress, which runs under the CAMPAIGN OWNER'S actor -- so ownerUserId is re-stamped from actor.userId there exactly as it is on the operator-facing writes, and the counters land on a row the worker was authorized to touch rather than on one it reached past the owner tier.

Relationships: parent -> v1:identity:user, references -> v1:campaigns:audience, references -> v1:campaigns:template, references -> v1:campaigns:senderIdentity, references -> v1:accounts:account

#v1:campaigns:campaignSeries

A repeating instruction, distinct from each occurrence's campaign and delivery ledger. Configuration is captured when an authorized person saves; every occurrence rechecks that person's current authority and snapshots the then-published template.

Relationships: parent -> v1:identity:user, references -> v1:campaigns:campaign, references -> v1:accounts:account

#v1:campaigns:consentEvent

Append-only consent / suppression event for one subscriber (memql#4141). Current status is derived from the latest event -- there is no mutable status column on this concept. Send-time suppression (v1:campaigns:suppression + recipient.subscriptionStatus) is unchanged; this stream is the export/compliance answer for "status, date, source". grant / withdraw / bounce / complaint / suppress are events. reason is required on suppress (enforced by recordConsentSuppress). Config and templates stay data, not this schema.

Relationships: parent -> v1:identity:user, references -> v1:campaigns:recipient, references -> v1:campaigns:campaign, references -> v1:accounts:account

#v1:campaigns:delivery

One recipient's outcome for one campaign -- the per-recipient audit trail a deliverability review is actually made of, and the LEDGER THAT MAKES A RESUMED SEND SAFE. Per-row authz: owned. IDEMPOTENCY IS STRUCTURAL, not a retry flag. The row id is derived deterministically from (campaignId, recipientId) -- per-part hashed, so no separator can alias two pairs onto one id -- which means a recipient has exactly one delivery row per campaign no matter how many times the send is resumed, restarted or raced between replicas. The worker's batch is "recipients of this audience with no delivery row, plus rows still pending whose nextAttemptAt has passed", so a recipient that already reached sent or skipped is simply not in the next batch. There is no "already sent?" flag to forget to check: the absence of the row IS the work queue. Written by component/campaigns' drain worker through recordCampaignDelivery, which runs under the CAMPAIGN OWNER'S actor -- so ownerUserId is stamped from actor.userId like every other write in this domain, never from a caller argument. That is what memql#3348 supplies and what took v1:campaigns:delivery off the owner-stamping gate's exemption list. outboundRequestId is EMPTY on every row this engine writes, and that is a decision rather than an omission (memql#3348). memql#3323 designed the send to stage v1:platform:outboundRequest rows and let the engine's outbound worker deliver them. Three things make that the wrong seam for bulk campaign mail: (1) the campaign worker has to SEE the provider's 429 + Retry-After to pace itself, and a queue drained by another worker turns that signal into an opaque retry -- which is exactly the "retries that look like duplicates to the recipient" failure; (2) a per-recipient TERMINAL outcome is the whole point of this row, and an async seam leaves every row pending until somebody writes a reconciler; (3) MEMQL_OUTBOUND_EMAIL_ALLOWLIST is a domain allowlist for TRANSACTIONAL mail, and a marketing audience is by definition arbitrary external domains -- so routing campaigns through it would either refuse every send or force that allowlist wide open and weaken the transactional egress control it exists to provide. The field stays on the schema because a future queued transport would populate it.

Relationships: parent -> v1:identity:user, parent -> v1:campaigns:campaign, references -> v1:campaigns:recipient, references -> v1:platform:outboundRequest, references -> v1:campaigns:emailRule, references -> v1:accounts:account

#v1:campaigns:emailRule

An event-triggered email: "when X happens on concept Y, send template Z" (memql#4829, program P4 and P5). THIS ROW IS THE FORM, NOT THE MECHANISM. What actually runs is a real authored automation construct, generated deterministically from these fields and activated through the runtime authoring pipeline; this row is what the app lists, edits, pauses and explains. WHY A GENERATED CONSTRUCT RATHER THAN ONE SHIPPED AUTOMATION WITH A LOOKUP TABLE. An automation's @trigger names ONE concept at load time. A user picking an arbitrary trigger concept therefore cannot be served by anything pre-shipped -- there is no wildcard trigger, and there should not be one. Generating a construct also inherits the whole governance apparatus for free: per-rule pause, the circuit breaker, the cluster kill switch, boot re-arm, and an author-scoped actor. The generator is a deterministic template. The LLM authoring path stays off: a rule that mails strangers is not a place for a model to improvise, and a deterministic generator is one a person can read the output of. TWO DELIVERY LANES, CHOSEN BY WHO RECEIVES (P5), never by a toggle the operator has to understand. recipientMode=cluster_roles OPERATIONAL. The recipients are this cluster's own people, so the mail rides the transactional outbox: the egress allowlist applies, there is no unsubscribe footer, and the marketing suppression list is neither consulted nor written. Telling an owner a new admin was added is not marketing, and running it through the campaign machinery would let an unsubscribe from a newsletter silence an operational alert. recipientMode=audience MARKETING. A campaign audience is being mailed one row at a time, recipientMode=row_address so it rides the campaign machinery: suppression checked at the point of send, unsubscribe attached, sender identity applied, outcome ledgered. row_address is the same lane with the address read off the triggering row instead of a roster. Per-row authz: composite -- the operator owns their rules, the cluster owner reads them all. The GENERATED construct runs under the author's own envelope, which is why the rule records who authored it: an automation's actor is not the row owner's, and a caller-scoped read from inside one returns nothing while looking entirely correct.

Relationships: parent -> v1:identity:user, references -> v1:campaigns:template, references -> v1:campaigns:audience, references -> v1:campaigns:senderIdentity, references -> v1:accounts:account, references -> v1:authoring:bundle

#v1:campaigns:engagementEvent

One tracked interaction with one delivered message -- an open or a click (memql#4823). Append-only: a person who opens a message four times produces four rows, and campaignStats computes the unique figure by (delivery, kind). Raw events are stored rather than counters incremented because a counter cannot answer "when", and "the whole audience opened it within ninety seconds of a tweet" is the shape of question an operator actually has. HOW A ROW GETS HERE, AND WHY THAT IS SAFE. The tracking endpoints are unauthenticated by necessity -- the caller is a mail client fetching an image, or a browser following a link -- so the only thing standing between them and a forged row is the token. The token is HMAC-signed by the same rotating key ring the unsubscribe links use, under its OWN context label, and it carries the delivery, the campaign, the kind and (for a click) the destination URL. An unsigned or edited token records NOTHING and, for a click, redirects nowhere: the signature over the URL is exactly what makes the redirect open-redirect-proof. The write itself is a @serverOnly mutation under internal origin, so no client can reach it directly whatever it holds. WHAT AN OPEN IS NOT. It is a pixel fetch, and mail clients cache, prefetch and block images. An open is therefore evidence of interest and never proof of reading, and the surfaces that render it say so rather than implying a precision the mechanism does not have. Text-only readers count as zero opens, which is the same statement. Per-row authz: composite -- the operator owns their own engagement history, the cluster owner reads every operator's.

Relationships: parent -> v1:identity:user, parent -> v1:campaigns:campaign, references -> v1:campaigns:delivery, references -> v1:accounts:account

#v1:campaigns:newsletterBinding

Explicit per-deployable newsletter configuration. Campaigns remains core; its form uses the same opt-in public-form carrier as storefront packs.

Relationships: parent -> v1:identity:user, references -> v1:accounts:account, references -> v1:platform:site, references -> v1:campaigns:audience, references -> v1:campaigns:template, references -> v1:campaigns:senderIdentity

#v1:campaigns:newsletterSignup

Durable intent for one welcome per audience/address. Only the signup capability may create it; the worker uses the original site owner's current authority.

Relationships: parent -> v1:identity:user, references -> v1:accounts:account, references -> v1:campaigns:newsletterBinding, references -> v1:campaigns:recipient, references -> v1:campaigns:audience, references -> v1:campaigns:template, references -> v1:campaigns:senderIdentity

#v1:campaigns:recipient

One email address in an audience, with the subscription state that decides whether it may be mailed. Subscription state is modelled here rather than derived at send time because it is a standing fact about a person, not a property of one campaign: an unsubscribe must suppress every future send, including sends of campaigns authored before the unsubscribe. Per-row authz: owned via ownerUserId, mirrored from the parent audience at create time.

Relationships: parent -> v1:identity:user, parent -> v1:campaigns:audience, references -> v1:accounts:account

#v1:campaigns:reputationWindow

Per-(sending identity, recipient domain, day) counters -- the reputation telemetry a warming ramp has to be driven by, and the thing memql#3462 says has to exist before a ramp is anything but a hardcoded table pretending to be a control loop. WHY PER DOMAIN. Mailbox providers judge a sender independently. "Our bounce rate is 1%" is not a number any of them acts on; "our complaint rate at gmail.com is 0.4% this week" is. It is also the question an operator asks long before they want anything automated, which is why this half is worth having on its own. WHY A ROW PER REPLICA (nodeId). Counters are accumulated in each worker's memory and written as ABSOLUTE values to that replica's own row. Two replicas incrementing one shared row would need a read-modify-write on the send path and would lose counts to the interleaving; one row each, summed at read time, has neither problem. The cost is that a reader must aggregate, which it was going to do anyway across domains and days. WHAT accepted IS NOT. It counts messages the TRANSPORT accepted, which is not delivery -- Graph answers 202 and the bounce arrives later. Delivery is therefore inferred (accepted minus bounces) and the field is named for what it actually observes. A delivered column would be a number nothing on this side can honestly produce. UNSUBSCRIBES ARE NOT COUNTED HERE, deliberately: the one-click endpoint is a separate HTTP handler with its own store and no collector, so a field for them would be a field nothing writes -- the exact shape this issue exists to remove. The ramp's thresholds are the bounce and complaint rates, which are what the providers themselves act on. clusterOwner tier, for the same reason the suppression list is: one deployment, one sending mailbox, one reputation. It is not an operator's number and no operator's authority should decide what it says. It carries no address -- a domain and four integers.

#v1:campaigns:sendJob

The engine's own record of one send RUN -- the queue the drain worker scans, and the only row in this domain the worker can find without already knowing whose it is. WHY THIS IS clusterOwner AND NOT owned. A worker cannot scan an owned concept: the owned tier injects row.ownerUserId == actor.userId into every read and there is no cluster-owner bypass on it (component/memql/rowauthz_enforce.go), so "which campaigns want sending" is not a question an owned row can answer. Nor should it be answerable from a row a caller can write: whichever row says "send campaign X as user Y" is an instruction the engine carries out under Y's authority, so a caller-writable one is an escalation with extra steps. Both writers of this concept (campaignStartSend and the worker) are Go that derived campaignOwnerUserId from a campaign row it had ALREADY READ under the caller's own actor -- the caller proves ownership by being able to read their own campaign, and nothing they typed is trusted. One row per campaign, id = the campaign's bare short id, so pause / resume / restart all land on the same timeline rather than accumulating runs. Per-recipient idempotency does not live here -- it lives on the delivery ledger (see v1:campaigns:delivery), which is what makes a resumed send safe even if this row is lost entirely. A SCHEDULED CAMPAIGN IS A JOB IN THE scheduled STATUS (memql#3459), and that is why scheduling needed no new concept and no cross-owner scan. "Which campaigns are due?" is not a question an OWNED row can answer -- the owned tier injects row.ownerUserId == actor.userId into every read with no cluster-owner bypass -- so a clock-driven scan over v1:campaigns:campaign is not expressible at all. The scheduling builtin therefore does what campaignStartSend already does: it reads the campaign under the CALLER'S own actor, and writes a job here carrying the owner it derived. The worker then scans this concept, which it can, and asks the campaign row whether its time has come. scheduled is deliberately NOT drainable (see isDrainableSendJob): a job in this status is inert until something promotes it to queued, so the row existing can never by itself mail anybody.

Relationships: parent -> v1:campaigns:campaign, references -> v1:identity:user, references -> v1:campaigns:audience, references -> v1:campaigns:template, references -> v1:accounts:account

#v1:campaigns:senderIdentity

A mailbox this deployment may send campaign mail AS -- the "from whom" of a send (memql#4821, program P1). IT CARRIES NO SECRET MATERIAL, and that is the whole shape of the design. Authentication stays the cluster's ONE Graph credential; an identity row is the operator's DECLARATION that a mailbox exists inside their tenant and that campaigns may leave from it. Nothing here grants access to anything. Whether the send actually succeeds is decided by the tenant's Exchange ApplicationAccessPolicy -- the mail-enabled security group that scopes Mail.Send -- which no engine preflight can read. So a mailbox declared here but not added to that group surfaces as Graph's own 403 on the campaign's lastError, and that refusal is the honest check. The runbook section "adding a sending identity" is the other half of creating one of these. WHY A ROW RATHER THAN MORE ENV VARS. The deployment runs campaigns for several accounts, and which mailbox a client's mail leaves from is a per-account fact an operator changes without a restart. The env-configured sender remains the DEFAULT -- a campaign naming no identity behaves exactly as every campaign did before this concept existed -- so plurality is purely additive and the single-mailbox deployment never has to know this concept is here. SUPPRESSION DOES NOT FOLLOW THE IDENTITY (program P8). Several mailboxes inside one operator tenant are still one legal sender org and one domain reputation, so the do-not-mail list stays cluster-wide: an unsubscribe is a statement to the operator of this deployment, not to one of their mailboxes. Reputation and warmup DO key per identity -- they always did, on v1:campaigns:reputationWindow.sendingIdentity and v1:campaigns:warmupState.sendingIdentity, which were built for a plurality that did not yet exist. This concept is what finally supplies it. Per-row authz: composite. The operator owns their identities; the cluster owner reads them all.

Relationships: parent -> v1:identity:user, references -> v1:accounts:account

#v1:campaigns:singleSendReceipt

Private receipt for one caller's intended event email. A durable attempting record prevents a lost response or another replica from mailing it again.

Relationships: parent -> v1:identity:user

#v1:campaigns:suppression

Engine-owned suppression state. Rows without accountId are existing cluster-wide safety blocks. Organization opt-outs use a digest of (organization, normalized-email digest) as their row id, so leaving one client's mailing list does not unsubscribe the same person from another client. Both scopes are checked at send time; a later import cannot bypass either. No plaintext mailbox is stored. Organization scope is derived from a signed unsubscribe token or an authorized action.

Relationships: references -> v1:campaigns:campaign, references -> v1:accounts:account

#v1:campaigns:template

The authored content of a campaign -- subject line plus plain-text and optional HTML bodies. Kept separate from the campaign so one piece of content can be sent to several audiences without being retyped, and so editing copy is a different action (and a different authorization decision, later) from scheduling a send. Per-row authz: owned.

Relationships: parent -> v1:identity:user, references -> v1:accounts:account

#v1:campaigns:testSettings

The shared testing audience for one organization. Only the governed configuration action writes it.

Relationships: parent -> v1:identity:user, references -> v1:accounts:account, references -> v1:campaigns:audience

#v1:campaigns:warmupState

The warming ramp's own state -- one row per sending identity, id = the sending identity (memql#3462). A RAMP THAT ADVANCES ON A CLOCK IS A GUESS WITH A SCHEDULE ATTACHED, and the issue is explicit that the reason no ramp shipped with memql#3348 was the absence of the evidence one would need. So this row records a decision rather than a countdown: a step advances only when the previous step produced enough volume, held long enough, and stayed inside the bounce and complaint thresholds. decision and reason are what the row is FOR -- an operator who cannot see why the ramp last held has a control loop they have to trust rather than read. clusterOwner, like the counters it reads: the ramp paces the deployment's one sending mailbox.

#v1:cluster:cluster

A MemQL cluster -- the top-level deployment unit consisting of a shared database and seed nodes (bff, agent, planner). Partitions exist within a cluster for data isolation.

Relationships: owns -> v1:cluster:database, owns -> v1:cluster:identityProvider

#v1:cluster:database

A PostgreSQL database instance backing a MemQL cluster. Tracks connection info, engine version, and installed extensions. # status IS GONE, AND IT CANNOT COME BACK (memql#4766) It was enum("healthy","degraded","unreachable") stamped as the literal "healthy" by createDatabase and refreshed by nothing, so every reader got a hardcoded verdict. The fix is not "write a refresher" -- the field is STRUCTURALLY incapable of carrying the answer. This row lives IN the database it describes. Reading it requires that database to be reachable, so a successful read can only ever return healthy, and an unreachable database returns no row at all rather than unreachable. The one value the field exists to communicate is the one value it can never be observed holding. A surface that wants database health observes the CONNECTION, which already knows. Do not re-add this field.

Relationships: parent -> v1:cluster:cluster

#v1:cluster:deployment

A persisted deployment record (foundation of epic #1871, issue #1872). Append-only + time-series like the other cluster concepts: the row is written at deploy start (pending/in_progress) and every status transition appends a new payload version under the SAME concept id (the deploymentId, which is also the rollout hash) -- so the full lifecycle is reconstructable asOf any time, and asOf latest collapses to the deployment's current status. The CDC path emits graph.node.created/updated.<partition>.v1:cluster:deployment on every write, which the cockpit Deployments view subscribes to (same mechanism v1:cluster:node uses for live topology). The image digest -- previously only in releases/*.yaml on disk -- now lands in the data layer so history, node<->deploy linkage, next-version suggestion, and rollback can all be served from a query.

#v1:cluster:deploymentNodeSpec

Per-node-type spec for a deployment (Epic 2 / #2094). One row per (deploymentId, nodeType): the version + replica count + resolved image digest a given node type runs under a deployment. Engine-as-spine: an empty version means this node type resolves against the parent deployment's engine version (the release lockfile's engineVersion); a non-empty version pins this node type to a specific version that overrides the spine. Append-only + time-series like the parent deployment: the row is written when the spec is first set and every re-pin (version/replicas/imageDigest change) appends a new payload version under the SAME concept id -- hash(shortId(deploymentId) + ":" + nodeType) -- so the per-node-type spec history is reconstructable asOf any time, and asOf latest collapses to the node type's current spec. The CDC path emits graph.node.created/updated.<partition>.v1:cluster:deploymentNodeSpec on every write. deploymentId is a plain string FK to v1:cluster:deployment.deploymentId (cross-concept references use FK fields, not @relationship). A deployment's full per-node spec set = every deploymentNodeSpec with the same deploymentId.

#v1:cluster:identityProvider

An identity provider used for authentication and user management in a MemQL cluster. Typically the in-house identity service (component/identity), surfaced for cluster-topology dashboards. # status AND lastVerifiedAt ARE GONE (memql#4766) Both were written once at bootstrap -- status as the literal "connected" -- and refreshed by nothing, so a cluster whose IdP had been unreachable for a week still reported connected. Unlike database.status this one is not structurally impossible: the IdP is a different system, so a node CAN observe it. It is dropped because no writer is honest at this granularity. Every node runs a verifier that refreshes JWKS on a five-minute timer, so writing from all of them is a write per node per five minutes forever for a single-row fact -- the volume reasoning that keeps lastSeenAt off the broadcast rules. Electing one writer makes the row report THAT node's view rather than the cluster's. And a stored freshness stamp decays: "connected as of five minutes ago", read an hour later, is not a health signal. A surface that wants IdP health probes it, and says when it looked. Re-add these only with a named writer and a stated staleness contract.

Relationships: parent -> v1:cluster:cluster

#v1:cluster:node

A registered node in the MemQL cluster. The record is written on registration and updated on every liveness transition (connecting, healthy, degraded, draining, offline, stopped). States mirror the NodeHealthStatus enum defined in component/node/node.proto -- that proto is the source of truth.

#v1:cluster:nodeType

Definition of a node type and its expected capabilities.

#v1:cluster:releaseCut

One release cut of MemQL itself: the tag and published GitHub Release that make the CI cascade (dispatch-engine-images-on-release.yml, #2519) build every node image at that version. Written only by integrations/release, and append-only -- the row id is the VERSION, so every status transition appends to that version's own timeline and a cut is never edited into a different one. WHY THE ROW IS HISTORY AND NOT THE ANSWER TO "WHAT IS NEWEST". GitHub's tags are. A human who cuts a release by hand -- which release.sh's break-glass path still allows -- creates a tag this concept never hears about, so a reader that trusted the newest row would name a version that is no longer the latest and be confidently wrong. The portal card reads TAGS for "newest existing" and these rows only for "what did this cluster do", which is a division the card states in words. STATUS IS WHAT WE VERIFIED, NOT WHAT WE EXPECT. dispatched means the Release published and the cascade was handed the version; it does NOT claim the images exist. Only an actual GHCR manifest check moves a row to images_available (releaseCutStatus, D5), and a check that ERRORED leaves the row where it was rather than guessing -- the workflow can fail after the Release publishes, and the registry is the only thing that knows.

#v1:cluster:spawnEvent

Lifecycle event recording node state transitions (started, stopped, failed). Used for audit trail and cluster state recovery. Legacy name retained for data compatibility.

#v1:commerce:approvalChain

An approval chain: who has to say yes, in what order, above what value. Evaluated in MemQL BEFORE a draft order is sent, which is the whole point -- Shopify's own order-review Functions run at checkout, by which time the buyer has already been quoted a price nobody internally approved.

#v1:commerce:companyLocationNote

An internal note about a company location, projected the same way.

#v1:commerce:creditLimit

A credit limit for a company location. Shopify has no credit-limit field, so the limit is projected to a company-location metafield (memql.creditLimit) where a checkout validation Function can read it. THE FUNCTION IS NOT HERE: Functions are authored in the product repository and deployed to the store, and this row is what one reads. What MemQL owns is the number and its history.

#v1:commerce:customerNote

An internal note about a customer, projected to a memql-namespace metafield on the Shopify customer. Not storefront-readable.

#v1:commerce:productContent

Agent- and operator-authored product copy, projected into Shopify as metafields in the memql namespace. The FIRST origin domain (design D7): additive, cannot break a store, and the vehicle for agent-written content.

#v1:commerce:quote

A quote: priced, time-boxed, and turned into a Shopify draft order when the buyer accepts. MemQL-origin and NOT mirrored. Shopify has no quote object, so pushing one would mean inventing a representation in metafields and then owning it forever. What crosses over is the ACCEPTED quote, as a draft order with locked prices -- which is a Shopify object that already exists.

#v1:commerce:reorderList

A saved reorder list: what a buyer buys again.

#v1:commerce:salesRep

A sales rep. A MemQL identity, deliberately: a rep is a person in the wholesale business, not a Shopify staff member, and on a non-Plus plan Shopify will not tell us about staff at all.

#v1:commerce:territory

A territory: a named set of companies and locations one rep covers.

#v1:common:attachment

A file attachment with extracted transcription.

#v1:compose:composeTemplate

A file that makes an output repeatable for a customer: a .docx with a branded header, an HTML shell, a Markdown skeleton, or a zip of files for a deployable. The row binds one Library file to the format it produces and the placeholders it expects.

Relationships: parent -> v1:identity:user, references -> v1:library:file, references -> v1:accounts:account

#v1:compose:composition

One materialization: what was made, from what, through which template, by which models, and whether the file it produced carries its own provenance. The record is the provenance of last resort -- for a format with no metadata channel (design D4) it is the ONLY provenance the output has, which is why it is a first-class row rather than a field on the file.

Relationships: parent -> v1:identity:user, references -> v1:library:file, references -> v1:library:folder, references -> v1:compose:composeTemplate, references -> v1:work:goal, references -> v1:work:run, references -> v1:compose:recipe, references -> v1:accounts:account

#v1:compose:compositionInput

The saved execution request and captured source payloads for one materialization. Kept apart from the account-shared composition so sharing its provenance does not share private inputs.

Relationships: parent -> v1:identity:user, references -> v1:compose:composition

#v1:compose:recipe

A composition that worked, promoted to something you can run again: the source SELECTORS, the template and the format. Running one opens a goal exactly as a fresh materialization does, and a re-run with the same shape is a catalog exact match -- so it reaches no model at all.

Relationships: parent -> v1:identity:user, references -> v1:compose:composeTemplate, references -> v1:library:folder, references -> v1:accounts:account

#v1:data:log

Audit log entry for validation state transitions. Tracks who performed each check, confirm, or revert action, when, and why.

Relationships: parent -> v1:data:record

#v1:data:policy

Validation policy defining check/confirm requirements for a record type. Controls how many synthetic checks and human confirmations are needed, and whether checked data is usable before full confirmation.

#v1:data:record

Data record with validation lifecycle: draft -> checked -> confirmed. Replaces the staging/production split with a unified concept where data visibility is governed by validation state and policy.

#v1:email:capturedMessage

An encrypted message captured by an explicitly configured test transport. There is no Internet receipt or external delivery implied by this record. Bodies and recipient addresses are decrypted only by the gated email capability.

#v1:email:connectionState

Encrypted Azure sign-in or organization transport state. Read through the gated email capabilities only; plaintext credentials never enter the feed.

#v1:email:sendOperation

Private provider receipt. The integration checks organization authority before projecting status; addresses, message content and credentials are not stored.

#v1:forge:project

A project/codebase forge develops against (e.g. memql, or a given client's app). Requests are scoped to a project so one agnostic bundle serves many apps. Partition-scoped: team-shared within the tenant.

Relationships: parent -> v1:identity:user

#v1:forge:request

A request a team member submits through Claude -> the forge MCP surface: a bug, feature, or (later) HR action. Routed by submitterRole through the approval pipeline (submitted -> needs_validation -> validated -> needs_approval -> approved -> queued). Partition-scoped so validators/approvers can read it. Every transition is recorded as a v1:forge:requestEvent for a full time-series audit trail.

Relationships: parent -> v1:forge:project, parent -> v1:identity:user, parent -> v1:identity:user, parent -> v1:identity:user

#v1:forge:requestEvent

An append-only event in a request's lifecycle: a routing decision, validation, approval, rejection, comment, or mentoring touch. The time-series audit trail for a request -- every transition is one row, never mutated.

Relationships: parent -> v1:identity:user

#v1:healing:healedOverride

A two-tier definition of a self-healable construct: the immutable BASE (authored/embedded, never LLM-healed -- the deploy spine's source of truth) and a healed OVERLAY override (data, produced by the repair loop, human-validated) that shadows its base when valid. Resolution prefers the most-recent VALID overlay override for a baseConstructId and falls back to the base. Mirrors the Epic 1 RBAC base/custom hybrid (immutable predefined base + dynamic custom data, newest-wins). The tier field is the immutability axis: a tier=base row is immutable at runtime (the validateHealingBaseImmutable Go guard rejects any non-system-actor write to it, so an override can never be forged as base to escape the override-is-data contract); a tier=overlay row is the healed data an actor may add. Per-row authz: owned -- ownerUserId is stamped from actor.userId on every write and every read gates on row.ownerUserId == actor.userId. Multi-node consistent via the shared Postgres + the cache.invalidate broadcast.

Relationships: parent -> v1:identity:user

#v1:identity:accessRequest

Self-service access request placed on the waitlist queue. Created when an unknown email submits the registration form while MEMQL_IDENTITY_REGISTRATION_MODE=approval. Admins triage rows in the admin console: approval mints a v1:identity:invitation and emails a magic link; rejection stamps the reason and closes the row. Also auto-aged by the accessRequestExpirySweep cron once IDENTITY_ACCESS_REQUEST_EXPIRY_DAYS has elapsed without a decision. Global scope so admins in any partition (typically owners of the cluster) can review the queue.

Relationships: parent -> v1:identity:user, parent -> v1:identity:invitation

#v1:identity:account

A CUSTOMER THE OPERATOR MANAGES -- the record MemQL keeps ABOUT a downstream business, as opposed to v1:identity:user (a principal that logs in) or v1:identity:accountEntitlement (a billing cap keyed on a paying account id). An account is operator-side bookkeeping: it holds no credential, mints no session and is never a subject -- nothing authenticates AS an account, and no v1:identity:identity row points at one. Accounts are also FLAT: there is deliberately no parentAccountId, because a nesting edge makes the isolation predicate transitive and a transitive predicate cannot be pushed down as a single filter conjunct. An agency with sub-clients is N sibling accounts sharing an operator, not a tree. Per-row authz: OWNED, and engine-enforced rather than author-enforced -- ownerUserId is @serverSet and stamped from actor.userId on every write, and the @rowAuthz declaration makes the engine AND row.ownerUserId == actor.userId into every read (component/memql/rowauthz_enforce.go, memql#3172) and refuse any update whose target row the actor does not own (component/memql/rowauthz_write_guard.go, memql#3174). The model, and the three places it is NOT sufficient, are recorded in docs/internal/design/account-isolation-model.md.

Relationships: parent -> v1:identity:user

#v1:identity:accountEntitlement

Per-account entitlement that caps the number of CONCURRENTLY-RUNNING tasks (Plans) a paying account may have across all of its spaces, sourced from the billing tier (epic memql#902 / foundation child #903). The cap is per paying account -- v1 keys on v1:identity:user.id (accountKind='user'); accountKind='org' is reserved for a future per-organization rollup where many users share one paying account's slots. DEFAULT = UNLIMITED (enterprise behavior): an account with no row here, an enterprise tier, or a non-positive maxConcurrentTasks is uncapped -- the admission controller (#904) is a no-op until a finite cap is written, so existing / unconfigured accounts behave exactly as today (no regression). The NUMBER (maxConcurrentTasks) is the source of truth so billing can change a tier's cap without a code change; tier is carried alongside purely for the Tasks-UX upgrade / limit messaging (#909) and the enterprise=unlimited shortcut. Global scope (lives in _system) so the planner node's admission controller and the billing / admin writer can both reach it from any partition. One logical row per account: setAccountEntitlement mints a deterministic id (accountEntitlement-<hash(accountId)>) so each set appends a new time-series version and the latest wins.

Relationships: parent -> v1:identity:user

#v1:identity:auditEvent

Append-only audit log entry. Captures security-relevant events (auth, identity, authorization, configuration, admin) with actor + target + source attribution. Global scope so any cluster operator can read the full trail. Retention controlled by MEMQL_IDENTITY_AUDIT_LOG_RETENTION_DAYS via the daily auditEventRetentionSweep automation. The prevEventHash field is reserved for future hash-chain tamper-resistance; written but not validated in MVP. TIER: clusterOwner, and that is a RULING rather than a default (memql#4366, which carved this decision out of memql#4313). Three things ruled out the alternatives:

• owner="actorUserId" cannot be declared. createAuditEvent writes actorUserId from CALLER ARGS, which TestDeclaredOwnerFieldsAreServerStamped refuses for a declared owner field -- and re-stamping it from the actor would be WRONG rather than inconvenient: the identity service writes these on a user's behalf, and actorUserId is deliberately EMPTY for an anonymous event. A tier whose owner field is empty on the rows that matter most is a tier that admits nobody to them. - The composite owner=..., clusterOwner cannot deliver "an admin reads all" either. clusterOwner is Role == owner ALONE (AccessContext.IsClusterOwner), so an admin would be passed by a requiresOwnerOrAdmin query gate and then narrowed by the tier to nothing. memql#4313 assumed the two were the same; they are not. - via="<spec>" over a role predicate would parse, and is refused on meaning. The granted tier's whole design premise is "a row in isolation cannot answer this, the filter's join can" -- which is FALSE for a role check, needing no row at all. Every fail-closed edge it has (graph traversal, top-level builtin results, the write guard) would then fail for a reason that does not apply. So the ruling is the one memql#4366 offers as the alternative: THE CLUSTER-WIDE SECURITY LOG IS OWNER-ONLY. It is the same split memql#4328 already made for its sibling -- recentAuthActivity is the operator roll-up, authActivityForSelf is where a person reads their own story. Routine MECHANICS are self-readable; security DECISIONS about the whole cluster are the operator's. A non-owner admin keeps authActivityForSelf and loses the cluster-wide trail. createAuditEvent is unaffected: the write guard resolves a TARGET ROW and so covers updates and deletes, never creates (rowauthz_write_guard.go), and this concept is append-only with no update path at all.

Relationships: parent -> v1:identity:user, parent -> v1:identity:identity

#v1:identity:authActivity

Routine authentication MECHANICS: refresh-token rotations, the blocked ones, grace-window acceptances, and PAT-authenticated requests (memql#4328). The high-volume sibling of v1:identity:auditEvent, split from it so the audit trail stays a log of DECISIONS AND SIGNALS and is clean by construction rather than by a filter every reader has to remember. WHY A SECOND CONCEPT. One rotation is one row, and the designed cadence is one rotation per ~10.5 minutes per open tab. Two defects (memql#4326's skew-blind timer, memql#4327's per-route probe) turned that into a row every few seconds, and the operator's Audit Trail -- a generic concept walk over auditEvent with no filter of any kind -- became unreadable. Considered and rejected: a severity field plus a server-side filter on the generic browse walk (new engine, SDK and view-kit machinery, epic #4274), and simply not persisting rotations (which throws away the one signal showing WHICH DEVICE refreshed WHEN -- exactly what you need when a refresh token is stolen, and what memql#4329's reuse detection is built on). Two concepts also let retention differ, and keep a session's whole story one join on sessionId. action IS A CLOSED ENUM, unlike auditEvent.action. This concept has exactly four writers and will not grow by convention; a fifth mechanic is a deliberate change to this line and to the Go constants beside it, checked against each other by test/dslconformance/identity_audit_enum_contract_test.go. RETENTION IS REAL HERE. Rows older than MEMQL_IDENTITY_AUTH_ACTIVITY_RETENTION_DAYS (default 30) are HARD-DELETED daily by a Go-side job on the identity node (component/identity/authactivity, memql#4330) -- not counted, as auditEvent's observe-only sweep does. Reuse detection therefore reaches back exactly that far; the default exceeds both the 14-day idle timeout and the 30-day refresh TTL, so a token older than the window is dead on its own account.

Relationships: parent -> v1:identity:user, parent -> v1:identity:identity, references -> v1:identity:authSession

#v1:identity:authCode

One-time OAuth authorization code, RFC 6749 §4.1 style. Minted at /auth/magic-link/consume when the originating magic link carried an oauthCtxJSON (third-party OAuth client flow) and exchanged at /oauth/token for an access + refresh token pair. Single-use, redirect-URI bound, client-ID bound, ~60s TTL. Bound to the specific magic-link row it was minted from so a leaked code cannot be replayed across sessions. Global scope: token redemption is unauthenticated and must work without partition context. NO PLAINTEXT IS STORED (issue #3187). This concept once carried a code field holding the cleartext one-time code -- the only stored-plaintext credential in the tree. Its description claimed the plaintext was "the equality check on redemption". That was false: /oauth/token hashes the presented code and looks the row up BY codeHash (component/identity/http/token.go), AuthCodeRow has no Code member, and authCodeFull never projected it. The field was written and read by nothing. Finding a row by sha256(presented) IS the verification -- it proves the presenter holds the preimage -- so removing the field cost no property.

Relationships: parent -> v1:identity:user, parent -> v1:identity:identity, parent -> v1:identity:magicLinkRequest

#v1:identity:authSession

Bearer-token session record. One row per access token issued by the identity service's magic-link / refresh flow. Looked up on every authenticated request to enforce per-session revocation; rows past expiresAt are tombstoned by GC, not by user action. Global scope: lives in _system so any partition's middleware can resolve a session.

Relationships: parent -> v1:identity:user, parent -> v1:identity:identity

#v1:identity:clusterSettings

Runtime-editable cluster settings. Single-row concept (id='cluster') that holds the operator-tunable knobs originally bootstrapped from IDENTITY_* env vars. The first-run wizard (Phase 3) writes this row; the admin app (Phase 6) edits it. Service.LiveConfig() reads from here first and falls back to env so a fresh deployment is functional without any post-bootstrap edits. Global scope so the configuration is reachable from every binary that needs it (identity itself plus future per-node verifier middleware).

#v1:identity:delegation

Grants an AI agent the right to act through a user's v1:identity:identity for a bounded role ceiling, scope set, and lifetime. Global scope: lives in _system and is readable from any partition so cross-partition agent work does not require per-partition delegation rows.

Relationships: parent -> v1:identity:identity, references -> v1:agents:agent

#v1:identity:deviceCode

RFC 8628 device authorization grant state (memql#3410). One row per POST /device/code call. The device (a headless box, a hardened network, an editor extension that cannot bind a loopback listener) holds the plaintext device_code and polls /oauth/token; the human carries the short user_code to /device on a second device, signs in normally, and approves or denies. BOTH credentials are hashed at rest -- the plaintext device_code is returned exactly once in the POST /device/code response and the plaintext user_code is shown to the operator there and typed into the verification page; neither is ever persisted. Single-use: status is the state machine (pending -> approved -> redeemed, or pending -> denied), and only a row in approved can be redeemed, exactly once. 10-minute TTL (expiresAt), independent of status.

Relationships: parent -> v1:identity:user

#v1:identity:enrolmentToken

Single-use enrolment credential: authorizes exactly one action -- register a passkey as the named user -- which is what makes a FIRST credential obtainable with no mailbox (memql#3408). The plain token is mql_enr_<43 base64url chars> (32 CSPRNG bytes); only its SHA-256 hex digest lands here, so a database snapshot cannot be replayed into an enrolment. Single-use via consumedAt, stamped when the passkey registration succeeds; revokedAt is the issuer's kill switch before that. Default TTL 15 minutes.

Relationships: parent -> v1:identity:user, parent -> v1:identity:user, references -> v1:identity:invitation

#v1:identity:githubConnectState

Relationships: parent -> v1:identity:user

#v1:identity:group

A GROUP -- the thing that lets a client's people reach the client's work (epic memql#5165, D1). Membership in a group tied to an account is what admits a person to that account's rows: reads for any active member, writes for a member whose role holds the verb. That is not a second authorization mechanism -- it is the account="<field>" argument of the owned tier every tied concept already declares, resolved per request from these rows (design section C). THE ROW IS THE DEPLOYMENT'S, NOT A PRINCIPAL'S (D2), which is why ownerUserId is always empty and the tier carries unowned="admin". A membership keyed as owner-tier on userId would let a Member insert their OWN row into Acme's group, because an owned row admits its owner's inserts -- so both concepts here are unowned and written only by the Go builtins in integrations/groups under internal origin. A GROUP WITH NO ACCOUNT GRANTS NO ROWS (D8) and exists to organize. kind says which of the two a row is: account for the one the automation makes per account, custom for any other. It can still be a GRANT SUBJECT (design 2026-09-11-app-access-grants, D13): a group with no account grants apps -- it is a subject an app capability can name, and its members open that app's door -- and still grants no rows, because the rows a person then sees are decided by the tier of each concept, and a group with no account ties them to nothing.

#v1:identity:groupMembership

ONE PERSON'S MEMBERSHIP OF ONE GROUP (epic memql#5165, D11). The id is derived -- <groupShortId>-<userShortId> -- so re-adding somebody who was removed writes a NEW VERSION of the same logical row rather than a second row. History is the versions, which is what makes "when did they join, and who put them there" answerable without a second audit concept. UNOWNED for the reason the group is (D2): the row records a decision the deployment made about a person, not a row that person owns. Written only by integrations/groups, never by a mutation a caller can reach.

Relationships: references -> v1:identity:group, references -> v1:identity:user

#v1:identity:identity

An account or credential set owned by a v1:identity:user. One user can have many identities: a magic-link verified email, OAuth accounts on external apps, API keys (Personal Access Tokens), or service accounts. Agents borrow identities to act on the user's behalf via v1:identity:delegation. Cluster-wide: one row set, the same from every caller's view.

Relationships: parent -> v1:identity:user, references -> v1:identity:user

#v1:identity:invitation

Token-hashed invitation credential. Maps an invitee (existing user by ID, or an external address by email + token) to the cluster role they land with. The identity layer owns the lifecycle (pending/accepted/expired/cancelled) and the auth primitive. The space scope this used to carry (partitionId / spaceName) went with the space concept (epic memql#4988), and with it the guest half of the flow: the guest-auth interceptor, the five guest gRPC messages, and the mutations that minted a guest participant. What remains is the user invitation, which is what the MemQL OS Users app issues. kind keeps its "guest" value for rows already written; nothing produces one.

Relationships: parent -> v1:identity:user, parent -> v1:identity:user, references -> v1:identity:account

#v1:identity:magicLinkRequest

Pending magic-link authentication request. One row per /auth/magic-link issuance. The plain token is hashed (SHA-256) before persistence -- only the hash lives here so a database snapshot can never be replayed into a login. Single-use semantics: consumedAt is set atomically on the first successful click and any subsequent click against the same row is rejected. Past expiresAt the row is also rejected. Global scope so the public unauthenticated /auth/magic-link/consume endpoint can resolve the row regardless of which partition the eventual user belongs to.

Relationships: parent -> v1:identity:invitation

#v1:identity:oauthClient

Public OAuth client minted at dynamic client registration (RFC 7591). claude.ai / Claude Desktop's 'add custom connector' flow POSTs to /register and cannot pre-configure a client_id, so the identity service issues one here and looks it up at /authorize + /oauth/token exactly like a static MEMQL_IDENTITY_REGISTERED_CLIENTS entry. Public clients only -- no secret is issued (token_endpoint_auth_method = none). Global scope: registration + token redemption are unauthenticated and must work without a partition context. Because registration is unauthenticated, NOTHING on a freshly-registered row may confer a privilege: corsOriginsJSON is the one field here an owner/admin has to write deliberately, and it is written by nothing on the /register path (memql#3716).

#v1:identity:user

A person (or synthetic principal). Owns identities. Same record cluster-wide.

Relationships: references -> v1:agents:agent

#v1:identity:workerPairingCode

Short-lived pairing credential for the computer-use enrollment flow. The frontend's Settings -> Computer Use 'Connect this computer' card mints a row + plain code (XXXX-XXXX, 8 alphanumeric chars from Crockford's Base32 alphabet). The cockpit wizard on the user's machine redeems the code on the cluster's gRPC stream via Authorization: Pair <code>, the redeem handler stamps redeemedAt + redeemedBy, mints a v1:identity:identity worker_token row owned by the same user, and returns the plain mql_wkr_<...> token + cluster URL to the cockpit. Single-use: a row with non-empty redeemedAt is dead. TTL ~10 minutes (IDENTITY_PAIRING_CODE_TTL_MIN, default 10).

Relationships: parent -> v1:identity:user, parent -> v1:identity:identity

#v1:install:installRun

One execution of the install or uninstall step graph on one machine. The row is written when the run starts and re-written on every step transition under the SAME id (the runId), so the run's history is reconstructable asOf any instant. Its reason for existing is the receipts field: the per-step record of what the run placed on this machine and whether the machine already had it, which is the only evidence uninstall has that an artifact is ours to remove.

#v1:knowledge:documentChunk

A single retrievable text chunk attached to a knowledge domain. Chunks are produced by the knowledge ingestion integration (which splits source text and embeds each chunk). The embedding itself lives in the node_vectors table keyed by this chunk's id, via integration.embedding.store with vectorField='content'. Per Q8: text-style breakdowns of user-uploaded Documents (PDF sections, markdown chunks, plain text chunks) reuse this concept rather than duplicating the chunk infrastructure into a new typed concept.

#v1:knowledge:knowledgeDomain

Relationships: references -> v1:accounts:account

#v1:library:artifact

A single Library index row pointing at one underlying source concept (document / generated output / note / to-do / calendar event / memory / live source). Carries the shared provenance + type spine the Library panel needs to list / search / filter / sort across heterogeneous sources, while the actual content stays on the backing concept referenced by sourceConceptRef. The LOCKED backend shape for the Library epic (memql#693): a real index concept, not a UI projection. Per-row authz: the COMPOSITE tier (memql#4312) -- the owner, or a cluster owner. Every read already carried row.ownerUserId == actor.userId by hand; the declaration is what extends that to the paths a filter cannot reach (subscriptions, graph expansion, a raw query string) and what gives an operator console the cross-user view a plain owner= tier has no bypass for.

Relationships: parent -> v1:identity:user, references -> v1:agents:agent, references -> v1:work:run, references -> v1:worker:registration, references -> v1:library:folder

#v1:library:documentComment

Revision-bound document feedback. Shared reads go through libraryDocumentReview, which first rechecks access to the current artifact and its backing document.

Relationships: parent -> v1:identity:user, references -> v1:library:artifact, references -> v1:identity:user

#v1:library:documentVersion

An immutable content snapshot of one logical Library document at one point in its edit history. Appended -- never overwritten -- whenever a document is produced, edited (by user or assistant), or restored, with a monotonically increasing versionNumber. The artifact index + backing document always point at the LATEST version while the full append-only history is retained behind it. Backed by the MemoryNodes TimescaleDB hypertable (partitioned on createdAt); long-lived, compression-after-90-days, no retention drop (memql#1228). Per-row authz: owned -- ownerUserId is stamped from actor.userId on append; reads gate on row.ownerUserId == actor.userId.

Relationships: parent -> v1:identity:user, references -> v1:common:attachment, parent -> v1:identity:user, references -> v1:work:run

#v1:library:file

A file the owner put in their Library -- uploaded, exported from another artifact, produced by an agent, or derived from another file. The Library's own byte-bearing row: the bytes live in blob storage at blobUrl, and every fact about them (name, mimeType, size, sha256) lives here rather than on the artifact index, which owns no content (memql#693). Any MIME type is accepted; an unknown one is stored opaquely with status=ready and no chunks. Promoted into the Library by indexFileOnCreate. Per-row authz: the composite tier (memql#4312) -- the owner, or a cluster owner; ownerUserId is stamped from actor.userId and never accepted from caller args.

Relationships: references -> v1:work:run, parent -> v1:identity:user, references -> v1:worker:registration, references -> v1:worker:registration, references -> v1:library:folder

#v1:library:fileChunk

One chunk of a Library file's extracted text, embedded for similarity search. Written by the analysis pass, one row per chunk in file order; librarySimilarArtifacts runs similarTo over these and folds the hits up to their artifacts by best score. Deliberately NOT v1:knowledge:documentChunk, which requires a knowledge domain the engine tree does not declare (design D2). Per-row authz: the composite tier (memql#4312), the same as the file it belongs to -- ownerUserId is stamped from actor.userId, never accepted from caller args.

Relationships: parent -> v1:identity:user, references -> v1:library:file, references -> v1:library:artifact

#v1:library:fileVersion

One superseded version of a Library file: the byte facts, the provenance and the two moments that version had, frozen at the instant it stopped being the head (epic memql#4806, design D1). The newest version is NEVER one of these rows -- it is the v1:library:file itself, which is what lets the artifact index, the content route and the analysis pass go on reading exactly one row. Written only by supersedeLibraryFile through the @serverOnly pair, at the derived id '<fileId>-v<n>' so a retried supersede re-versions the same row instead of appending a duplicate to somebody's history. Per-row authz: the composite tier (memql#4312) -- the owner, or a cluster owner -- matching the file it is a version of.

Relationships: parent -> v1:identity:user, references -> v1:library:file, references -> v1:worker:registration

#v1:library:folder

One folder in the owner's Library tree (memql#4781, design B1/D3): a named collection artifacts and other folders point INTO via ids -- never a path segment, never a namespace. parentFolderId nests it (empty or absent = root); sibling name duplicates are allowed by design, so there is no uniqueness machinery to fight and a rename touches exactly one row. Archiving is the same soft delete every Library row gets -- the client-driven walk archives contents first (design B5), and a folder that vanishes under its children only degrades the picture: the tree fold renders orphans at root with a marker. A folder whose subtree holds no file at all takes the OTHER disposition instead: deleted, which no surface shows and no restore undoes, because there is nothing inside it for anybody to want back. Per-row authz: the composite tier (memql#4312) -- the owner, or a cluster owner -- matching artifact and file, whose rows it organizes.

Relationships: parent -> v1:identity:user, references -> v1:library:folder

#v1:library:generatedOutput

A deliverable PRODUCED through the app (as opposed to an uploaded document): a workbench result, a computer-use output, or a standalone agent output. Carries either inline text (body) or a reference to file bytes (attachmentId -> v1:common:attachment). Auto-promoted into the Library by indexGeneratedOutput on creation. Per-row authz: owned -- ownerUserId is stamped from actor.userId on every write and reads gate on row.ownerUserId == actor.userId.

Relationships: parent -> v1:identity:user, references -> v1:common:attachment, references -> v1:work:run, references -> v1:agents:agent, references -> v1:worker:registration

#v1:library:memory

A durable memory the assistant retains about the user across sessions (a fact, preference, standing instruction, or episodic recollection). The user-facing LLM-memory concept; surfaced in the Library's Records lens. Per-row authz: owned -- ownerUserId stamped from actor.userId; reads gate on row.ownerUserId == actor.userId.

Relationships: parent -> v1:identity:user, references -> v1:agents:agent

#v1:library:uploadSession

One chunked upload in flight (memql#4782, design C2): the per-chunk authorization row (row admission is the owner check) and the record of init-time facts the complete step needs. Staged blocks live with the blob in Azure, never in any replica's memory, so any bff serves any chunk. Written ONLY by the upload routes through @serverOnly mutations: blobPath and fileId are storage-layer facts a caller must never author -- a forged blobPath would point complete at somebody else's bytes. Abandoned sessions are inert rows; their staging garbage-collects on Azure's ~7-day clock and no sweeper exists. Per-row authz: the composite tier (memql#4312), matching every other Library concept.

Relationships: parent -> v1:identity:user, references -> v1:library:folder, references -> v1:library:file, references -> v1:library:artifact, references -> v1:worker:registration

#v1:library:watchedFolder

One folder on one of the owner's fleet machines, continuously backed up into a Library folder (epic memql#4783, the cockpit half memql#4841). The engine holds the arrangement and the state last reported about it; the cockpit does the sweeping, the pushing and the looking-at-the-origin, because it is the only party that can see the origin at all. Per-row authz: the composite tier (memql#4312) -- the owner, or a cluster owner -- matching every other Library concept, so an operator answering "why has this machine stopped backing up" can read the arrangement without being able to rewrite it.

Relationships: parent -> v1:identity:user, references -> v1:worker:registration, references -> v1:library:folder

#v1:memory:belief

A durable, distilled belief consolidated from episodic memory (#586) -- a stable fact, preference, or learned outcome the agent should keep across plans. The content field is the embedding text: the consolidation + embedding loop stores it into node_vectors keyed by this memory's id (integration.embedding.store, vectorField='content'), mirroring v1:harness:observation and v1:knowledge:documentChunk, so semantic memories are themselves similarTo-recall-able -- both for the recall path (#585) and for the dedup step of consolidation itself (before writing a new belief, similarTo against existing semanticMemory rows; reinforce the match instead of duplicating). Provenance is the killer feature: sourceEpisodes links every belief back to the episodic node ids that formed it, so a belief is always auditable. confidence rises on reinforcement and decays when a belief goes unreinforced; lastReinforced is the decay clock. ownerUserId is the per-row authz key (owned tier), stamped from actor.userId at create time; only the owner reaches their own beliefs.

Relationships: parent -> v1:identity:user

#v1:memory:consolidationCursor

The per-owner consolidation watermark (#586), stored as a node so the consolidation loop's bookkeeping is itself durable + queryable -- no separate cursor store. Holds the createdAt boundary of the most recent episodic batch already consolidated for this owner; each scheduled run reads only episodes with createdAt > watermark, then advances the watermark to the newest episode it processed. This is what makes consolidation INCREMENTAL: cost is bounded by the new-episode delta, not total history, as the agent's log grows without bound. One row per owner (content-addressed id on ownerUserId), updated in place. ownerUserId is the per-row authz key (owned tier), stamped from actor.userId at create time.

Relationships: parent -> v1:identity:user

#v1:models:modelProfile

A curated model the catalog recommends, by category and machine class. TIER: public, requiresIdentity. Any signed-in person reads it. The Fleet models surface has to say what this fleet COULD run before anybody has pulled anything, and a catalog narrowed by owner would show a new operator an empty page with no way to tell that from "nothing is recommended". There is nothing here to protect: every row is a public model id and a published size.

#v1:notes:note

A user-owned standalone note: an optional title, a body, and tags, plus an updatedAt watermark. The standalone notebook concept -- distinct from the product pack's canvas-state note caption field. Per-row authz: owned -- ownerUserId is stamped from actor.userId on every write and every read gates on row.ownerUserId == actor.userId.

Relationships: parent -> v1:identity:user

#v1:observability:codeMetric

Aggregate observability rollups for a code reference over a time window. Backed by TimescaleDB continuous aggregates over the code_invocation hypertable -- callCount, p50/p95/p99 durations, errorRate -- so a drill-down sparkline can query the metric for any (codeReference, kind, window) in O(few rows) regardless of how many raw invocations the function had. Aggregates outlive raw rows: when codeProfile.retentionDays evicts the underlying invocation chunk, the matching codeMetric rows for that chunk are preserved by the policy so the trendline stays continuous.

#v1:observability:codeProfile

Live per-function observability configuration. Created on demand: a function only has a codeProfile row when someone wanted to set a non-default level on it (incident response, hot path under investigation, etc.). Resolution at call time is codeProfile -> MEMQL_OBSERVE_LEVEL default -> off. Keyed by codeReference, which matches the model.Node.ID for the Method or Func node in the architecture model (component/architecture/embedded/topology.model.json, e.g. 'method:github.com/znasllc-io/memql/component/auth.(*Handler).Login'). The observe runtime reads them through a CDC-driven cache.

Relationships: parent -> v1:identity:user

#v1:observability:invocation

One captured invocation of a Method or Func. Backed by the code_invocation TimescaleDB hypertable (see scripts/dev/migrations/observability/); rows are time-partitioned, jsonb-compressed after 24h, and dropped per codeProfile.retentionDays. The mutation surface goes through the engine like any other concept so the engine's auth + partition middleware applies uniformly, but the read path on the hot drill-down view is intended to use the continuous aggregates (codeMetric) rather than these raw rows. Hand-querying invocation rows directly is fine for forensic 'last 20 calls to X' lookups.

#v1:observability:logLine

One persisted log line from any node type or from the MemQL OS front end (epic memql#4893). Backed by the log_line TimescaleDB hypertable (component/database/memory-nodes/migrations/20260903000000_log_line_hypertable), written by the store sink core/logger installs beside every node's console handler and by logsRecordClient for OS lines, and NEVER a graph row: like invocation, this concept declares the table's shape and nothing maps a field to a column. Rows are read through the @sdk builtins in builtins.memql (logsSearch, logsTail, logsSources), all floored at admin in their Go handlers, which is why the concept declares no row tier -- no row of it ever passes graph admission. Retention is the nightly logsRetentionSweep automation: archive to blob storage first, delete second, thirty days by MEMQL_LOGS_RETENTION_DAYS. subject plus subjectConcept is the one seam between a line and the thing it is about (a deployment, a site, a plan); logger.Subject stamps both. Design: docs/superpowers/specs/2026-09-03-logs-design.md.

Relationships: references -> v1:identity:user

#v1:observability:siteTraffic

One bucket of one deployable's traffic, folded from the edge's request log (epic memql#4906, the Run epic of the Deployables program). A DECLARATION OF A RELATION'S SHAPE, the invocation and codeMetric precedent: rows live in the edge_request_1m / _1h aggregates TimescaleDB maintains, never in the graph, and reach a client as synthetic nodes from siteTrafficInWindow. Nothing maps a field here to a column; the mapping is component/sitetraffic's. AN ABSENT ROW IS THE UNMEASURED ANSWER. A window nothing recorded produces NO ROW for that deployable, and a window with requests and no errors produces a row whose errorCount is 0 -- "nobody visited" and "we were not recording" send a person to two different places, which is the same rule campaignStats states about a unique-open count it could not measure. windowEnd - windowStart says whether a row is a BUCKET or a SUMMARY: a bucket's span is the bucket size and a summary's is the window the caller asked for. Read the span rather than looking for a flag, which is codeMetric's own convention.

#v1:os:askConversation

A private conversation with MemQL. The transcript is written by the agent service; ownership is always taken from the authenticated caller.

Relationships: parent -> v1:identity:user

#v1:os:attentionReceipt

A person's acknowledgment of one meaningful UI or runtime change. Receipts are immutable per revision, so viewing an older revision cannot hide a new one.

Relationships: parent -> v1:identity:user

#v1:os:desktop

One person's MemQL OS desktop: their desks, the items and folders on each, their dock pins and their theme -- the document DesktopStore loads and saves, kept where their other machines can resolve it. TIER: the plain owner tier, deliberately WITHOUT clusterOwner. Every other owner-tier concept in this tree pairs the two because an operator has to support the person -- "why is this workbench node full", "why did this call route there". A desktop layout answers no such question; it is where somebody put their icons. The composite would let a cluster owner read it and buy nothing, so this concept is one of the few places the plain form is the right one. There is no deleted / active field and no delete path. A person who wants their desktop back to nothing rearranges it, and the next save carries that; a row that can be absent would make "no desktop yet" and "desktop emptied" the same state to a reader that has to tell them apart.

Relationships: parent -> v1:identity:user

#v1:planner:responsibility

A user-authored standing directive aimed at an agent (epic #631 / program #629). Three archetypes discriminated by trigger: REACTIVE (a condition is evaluated against incoming signals; fires when it matches -- e.g. 'when a customer escalation mentions a refund, draft a reply'), STANDING (a behavioral always-on directive with no schedule or condition -- e.g. 'always keep the project tracker tidy'), and RECURRING (a cron schedule; the old standingTask -- e.g. 'every Monday 9am summarize last week's marketing performance'). Per-user; the optional scopePartitionId pins the directive to one space. Consumed by the reactive-loop epic #632 (dueResponsibilities feeds the heartbeat-driven evaluator; recordResponsibilityEvaluation closes the loop). Replaces the retired standingTask concept -- recurring directives carry the same cron schedule + soft-disable + last-run bookkeeping standingTask had.

Relationships: parent -> v1:identity:user, references -> v1:agents:agent

#v1:platform:accountFrontDoor

One account's reserved MemQL name, served (epic memql#5168, design D of the access program: docs/superpowers/specs/2026-09-08-per-account-front-door-design.md). A client whose own domain is acme.com reserves memql.acme.com through record A's domain walk, and this row is what turns that reservation into three hosts the cluster actually answers on -- app. for the OS shell, api. for the engine's API edge, id. for sign-in. A NEW CONCEPT RATHER THAN FOUR MORE FIELDS ON THE ACCOUNT ROW, for customDomain's own reason: what a cluster serves at its front door is one DEPLOYMENT's fact, and v1:accounts:account sits on a rank-visible tier where a client-rank member can read it. The reservation belongs on the account (it is a fact about the client); the serving belongs here. It reuses the custom-domain machinery end to end -- the same DNS resolver, the same six-value status ladder, the same one-transition-per-pass reconciler, the same capability-script provisioner -- and differs in exactly two ways. It checks POINTING ONLY, because record A's TXT walk already proved the parent domain and memqlReservedAt is stamped only on success; and its certificate names THREE hosts, which is what makes activation all-or-nothing without a rule to police (design D8).

Relationships: references -> v1:accounts:account

#v1:platform:automationLoopStop

Virtual projection of one run the LOOP PROTECTION STOPPED (epic memql#5380, D-C). Never persisted as itself -- rows are produced at query time by the automationLoopStops builtin from the latest v1:work:run rows whose errorCode is loop_depth_exceeded, the same shape as v1:platform:dataOrigin. A PROJECTION, NOT THE RUN ROW, and the difference is the point: a run row carries its input, its variables and its triggering event's payload, and none of that is here -- only the chain of automation names and run ids that led to the stop, the bound it passed, and when. It is a concept of its own rather than a v1:work:run node for a second reason: a run row is on the composite owner tier, and a system run has no owner, so a builtin reply carrying it would be filtered to nothing for every reader who is not a cluster owner. The builtin's capability is the wall.

#v1:platform:automationNode

Virtual projection of one AUTOMATION as the static loop graph sees it (epic memql#5380, D-L). Never persisted -- rows are produced at query time by the automationGraph builtin from the automations the answering node's scheduler registered, the same shape as v1:platform:dataOrigin. It is the map half of the OS's Cluster > Automations section: which automation's writes start which other automation, in what order (the strata), and where the loops are. What each automation DID is not here -- no run, no payload, no argument value -- because the question the page answers is how the cluster is wired, and v1:work:run already answers the other one. PER NODE, like dataOrigin. The graph is built from the scheduler that answered, over the tree and bundle that node loaded; two nodes that loaded different bundles would answer differently, and that difference is the truth about them.

#v1:platform:customDomain

Relationships: references -> v1:platform:site

#v1:platform:dataOrigin

Virtual projection of one concept's DATA-ORIGINS declaration (epic memql#4378): what MemQL's relationship to that concept's data is. Never persisted -- rows are produced at query time by the dataOrigins builtin from the live concept registry, the same shape as v1:router:modelCatalog. Lives in the concept registry so the engine can shape results without a database round-trip. This is the INVENTORY half of the Data origins page. The HEALTH half -- backfill cursors, lag, drift counts, outbox depth -- is per-(concept, connector) operational state that accumulates over time and is a persisted row instead. Serving both from one place would make a staleness bug in either look like the other.

#v1:platform:embedderBinding

The cluster's ACTIVE embedder, at the literal row id active (epic memql#5137, D6). WHY A BINDING AT ALL. The embedding model was the string "embedding3Small" in five files and node_vectors was declared vector(1536) -- that model's width, written into the schema. So the cluster could only ever embed with one paid OpenAI model: changing it meant editing five files AND a migration, and doing either without the other produced a table full of vectors of the wrong width. That is not an error anywhere. It is a search space that quietly returns wrong neighbours. THE LITERAL ID IS LOAD-BEARING, the same way v1:cluster:database's is (memql#4766). A re-write is then a new VERSION of one logical row rather than a second row, so "which embedder is active" has exactly one answer to read -- and a query that returned two would have no way to choose. SWITCHING IS NOT AN EDIT. Activating a different embedder opens the reembedLibrary work goal, which fills a new node_vectors_<dims> table and flips this row only when the counts match. Until then every read follows the binding that is still active, so a switch interrupted half way leaves a cluster that still works rather than one whose vectors half mean one thing and half another. TIER: public, requiresIdentity, and the row-authz land gate is what settled it. The first cut said clusterOwner, on the reasoning that the embedder is a property of the DEPLOYMENT rather than of a person -- which is true, and is an argument about ownership, not about secrecy. There is nothing here to protect: a model id, a vector width, and when it changed. Meanwhile a person wondering why their search results changed shape has exactly one row that explains it, and hiding it from everyone but the owner would make that unanswerable for the people most likely to ask. v1:platform:inferenceStatus and v1:models:modelProfile carry the same tier for the same reason. WRITING is a different question and is settled separately: both mutations are @serverOnly, because activating a binding is four ordered steps and not a write.

Relationships: references -> v1:work:run

#v1:platform:externalConnection

A person's saved external resource. Authorization credentials remain with the provider integration; removing this selection never uninstalls it.

#v1:platform:fleetModel

Virtual projection of ONE MODEL the caller's fleet can run right now (epic memql#4676). Never persisted -- rows are produced at query time by the fleetModels builtin from live worker registrations, the same shape as v1:platform:dataOrigin and v1:router:modelCatalog. NEVER PERSISTED, and here the reason is at its sharpest. The answer is which machines are AWAKE right now, so a stored copy could only ever be a second, staler answer -- and its staleness would be indistinguishable from the very condition it describes. A row written four minutes ago saying "llama3.1:8b is available" describes a closed laptop exactly as confidently as an open one. SCOPED TO THE CALLER. A model call carries the caller's prompts and routes only to their own machines (memql#4678), so a catalog showing somebody else's would promise a model the router will never use -- and would enumerate another user's hardware besides. What this read returns is the caller's own machines PLUS the shared-inference set, which every user may legitimately reach for cluster work because their owners opted them in. ATTRIBUTES ARE THE UNION over the machines behind a model: if one machine can do structured output, the model can, because a call needing it routes there. The intersection would hide a capability the fleet actually has whenever one machine under-reports.

#v1:platform:globalSecret

Instance-wide encrypted secret. Lives in the reserved _system partition (via @scope("global")). The cleartext value is NEVER stored -- only a NaCl secretbox ciphertext (base64(nonce||ct)) under MEMQL_MASTER_KEY and a short fingerprint for UI display. Used for instance-level API keys, OAuth client secrets, Azure/Graph credentials, etc. For per-tenant overrides (BYOK) use v1:platform:partitionSecret; the resolver falls back partition -> global automatically.

#v1:platform:globalVariable

Instance-wide plaintext configuration variable. Lives in the reserved _system partition (via @scope("global")) and is visible to every tenant. Used for instance-level defaults like provider names, feature flags, log levels, and tuning knobs. For per-tenant overrides use v1:platform:partitionVariable. For sensitive values use v1:platform:globalSecret.

#v1:platform:inboundRequest

A verified inbound delivery (memql#2957): the durable inbox row the engine's inbound receiver stages when a third party POSTs to /inbound/{source} and the request passes the deployment's source allowlist and signature check. Product DSL reacts with an ordinary automation on node.created -- no product Go. The counterpart to v1:platform:outboundRequest: outbound is the outbox a product stages and the engine drains, inbound is the inbox the engine stages and a product drains. Credentials are NEVER on this row -- the signing secret lives in env/globalSecret and only the verdict is recorded. See docs/internal/design/inbound-delivery-adr.md.

#v1:platform:inferenceStatus

Virtual SINGLE-ROW answer to "can this caller get inference at all, and through which door" (epic memql#4676, design G). Never persisted. The first-run gate reads it. ONE ROW BECAUSE IT ANSWERS ONE QUESTION. The gate needs an answer, not material to compute one -- and eligibility computed in a client is a second implementation that drifts from the one the router actually applies. Every input is named on the row anyway, so a person looking at a gate they do not understand can see exactly what it read.

#v1:platform:missingCapability

A capability the platform itself cannot yet provide -- a missing tool, missing integration, missing connector, missing knowledge domain category, etc. Distinct from the capability-gap signal raised when no agent in the catalog can serve an utterance: missingCapability fires when even creating the right specialist wouldn't solve the problem because the underlying platform surface doesn't exist. Logged by the Planner Agent during its capability-gap detection step before agent creation. Becomes the product backlog -- 'these are the things the platform can't do yet that users actually want.' Global-scoped so it's visible across tenants for prioritization.

Relationships: references -> v1:work:run, references -> v1:agents:agent

#v1:platform:modelEvidence

One model's week at one level, folded from what actually happened. A MEASUREMENT AND AN EVIDENCE ROW ANSWER DIFFERENT QUESTIONS. The probe asks a model to do things nobody needed done, under controlled conditions, and reports how it went. This row is the record of real calls: how many, how many failed the structured contract, how often a repair or a retry followed, how often a run parked. Neither substitutes for the other -- a model can probe well and fail in service, and a model with a bad week can be perfectly capable. IT PROPOSES AND NEVER APPLIES. Above a 0.3 structured failure rate over at least twenty calls, the nightly fold opens a v1:work:approval of kind routingReview carrying a generated rule hashed over its exact text; approving arms it and declining is recorded so the same week's evidence does not re-propose. Automatic demotion was considered and rejected: it violates the never-a-silent-edit rule, and a week of bad luck on one schema is not a reason to route a whole level elsewhere. THE CALL COUNT IS ON THE ROW EVEN WHEN IT IS UNDER THE FLOOR, so an operator asking why nothing was proposed reads the answer rather than inferring it. TIER: clusterOwner. It spans every owner's calls by nature -- the question is how a MODEL behaved across the fleet, not how it behaved for one person -- so there is no owner to scope it to.

Relationships: parent -> v1:work:approval

#v1:platform:modelMeasurement

One probe's figures for one model on one machine, under one suite version. KEYED BY (machineId, modelId, suiteVersion), AND THE THIRD IS NOT METADATA. Two figures scored by different suites are not comparable, so a new suite version produces a NEW row rather than overwriting a figure that meant something else. The row id is a digest of the three, so a re-probe under the same suite is a new VERSION of one logical row and the history stays readable. EVERY FIGURE IS A STAT OR AN ABSENT REASON, never both and never neither. That is component/proving/figure's discipline carried onto a row, and the reason is a page: a machine nobody has probed showing "0 tok/s" reads exactly like a slow machine, and the two lead to opposite actions. Each figure is an object of the shape { measured: true, median, spreadLow, spreadHigh, n } XOR { measured: false, absentReason, absentDetail }, where absentReason is one of unmeasured, refused or failed. refused is NOT a failure -- it is the 32K case put to an 8K model, a question the model never claimed to answer -- and counting it as one would penalise a model in every ranking for a limit it had already declared. A MEASURED ZERO IS A REAL ANSWER. Five structured cases that ran and all failed is 0.0 with n=5, and it says do not route structured work to this model; that is a different sentence from the absence a crashed runtime leaves, and the whole shape above exists to keep them apart. TIER: the composite owner, clusterOwner. A measurement is a fact about somebody's machine -- it says what their hardware does -- so the owner tier is right, and a plain one would hide every machine's figures from the operator who has to explain the routing.

Relationships: parent -> v1:identity:user, parent -> v1:worker:registration

#v1:platform:moduleReadiness

One node's verdict on one module (design record 2026-09-06-configuration-readiness, section 4.4). Rewritten as a new version of the same id, v1:platform:moduleReadiness:<module>--<nodeId>, when this node's verdict changes and at least every ten minutes, so a read collapses to the latest. Carries presence and source only, never a value. TIER: public, requiresIdentity. Any signed-in person reads it -- the setup surface has to tell a viewer "not set up" as honestly as it tells an owner -- and nobody anonymous does. The write is the engine's alone: recordModuleReadiness is @serverOnly. unknown (design record 2026-09-14-readiness-convergence, D1) is the node's word for "I could not evaluate this": a resolver the verdict depends on errored. It is never a vote in the fold and is never written over a known row; reason names which resolver, from a closed vocabulary (fleetReadFailed, integrationProbeFailed), never an error string. ADDITIVE on purpose: dropping an enum value bricks stored rows (root CLAUDE.md). A lane's optional scope: "cluster" marks one computed from cluster rows alone; the fold sets aside a row whose cluster-scoped lanes lag the freshest row's (memql#5259).

#v1:platform:moduleVerdict

Virtual, never persisted: the cluster-wide fold of moduleReadiness rows, one row per module with id = module name. The moduleReadiness builtin answers it; the OS computes the same fold from the live feed with the mirrored function (component/memql/readiness). @displayCard's tertiary names "core" rather than the brief's original "disagreement": the loader rejects an array-typed slot ("disagreement" is []string; only string/enum/bool/datetime/int/float display), and core is the one other scalar this concept carries.

#v1:platform:outboundRequest

A staged outbound delivery (memql#2521): the durable outbox row a product automation or logic body creates when it decides something must leave the cluster (an email, a webhook call). The engine-owned outbound worker drains pending/retrying rows, performs the delivery through the deploy-configured transport (per-medium allowlists, credentials from env/globalSecret -- NEVER from this row), and stamps the status transitions back, so delivery state is ordinary graph state products can query and react to. See docs/internal/design/outbound-delivery-adr.md.

#v1:platform:outboxEntry

One pending outbound delivery for an ORIGIN concept (epic memql#4378, D5). MemQL owns the data; an external system holds a mirror of it; this row is the durable record that a change has to reach that system. Appended by the engine in the SAME TRANSACTION as the row write, one entry per @mirroredTo target, and drained by that connector's worker. The append is transactional because the alternative is a change that MemQL believes it propagated and the mirror never heard of. A write that fails writes no entry; an entry that exists names a row write that committed. clusterOwner: the queue is one deployment's operational state, not any user's rows, and "how deep is the outbox" has to be answerable. The drain worker reads it under the engine's own operator identity -- the campaigns precedent.

#v1:platform:packState

Per-instance pack enablement state (module-registry design, docs/superpowers/specs/2026-08-20-module-registry-design.md section 4). One row per pack at the deterministic id v1:platform:packState:<packDomain>; the append-only version history IS the audit trail of flips. ABSENCE OF A ROW MEANS THE PACK'S DECLARED DEFAULT (epic memql#5532, issue memql#5549), and a pack that declares nothing defaults to ENABLED -- so a fresh database still needs no seeding and every pack that predates the declaration behaves exactly as it did. A STOREFRONT pack declares false, because it carries a shopper write path and a public read and 'absence means enabled' would switch both on for every cluster that ever upgrades with no row anywhere saying so. A ROW ALWAYS WINS over a declared default, in both directions, because it is the operator's explicit act; the default is only what governs in its absence. Read once per node at boot (app phase 3, after the database starts and before the DSL loaders run); a flip takes effect as each node restarts, and the module inventory reports enabled-vs-loaded honestly in between. A row naming no registered pack domain is reported by the inventory and otherwise ignored. clusterOwner tier for the same reason v1:platform:site and v1:campaigns:sendJob carry it: what a cluster RUNS is one deployment's fact, not any individual operator's rows, and "list every pack's state" must be expressible.

#v1:platform:package

A TRACKED SOURCE this cluster can deploy: a memql-project-shaped tree that arrives either as a Git repo or as a zip of exactly the same tree (D1). The two forms are interchangeable and equally validated, which is why sourceKind discriminates provenance and nothing else -- every rule downstream of the fetch reads one tree. Nothing becomes a package by claiming to be one: an analysis decides, offline, before anything deploys (D12, component/packages). A row exists here because an analysis of that source has already succeeded at least once. The COMPOSITE tier, for the reason v1:platform:site records at length: a plain owner tier has no cluster-owner escape on the read path, so "list every package in this cluster" would not be EXPRESSIBLE and an operator would silently read a subset. The composite keeps both statements true -- a person reads their own packages, an operator reads every one. AND THE ACCOUNT ARGUMENT, which is a DEPARTURE from the accounts rule and is recorded as one (memql#5303, design 2026-09-11-app-access-grants D12). The rule -- "an account is a record of who work is for, never a visibility scope" (accounts D1) -- holds for campaigns, and it held here until this line. v1:platform:site left it in epic memql#5165, when account="accountId" became an argument of the owned tier: a person whose group ties them to the account this row names reads it, and may write it if their role holds the verb, without owning it. This finishes that departure for deployables. A package and its runs are what a client's people, and the cluster's own, work on together, and the alternative -- every deployable visible to exactly its creator and the operator -- was two people on one cluster unable to see each other's. Developer rank and above are standing members of every account-kind group by rule, so the staff read every TIED package; an untied one stays its owner's and the operator's, exactly as before. The compose flow ties a new package to the cluster's own account (v1:accounts:account:self) unless a client is picked, which is what makes the departure the default rather than an option.

Relationships: parent -> v1:identity:user, references -> v1:accounts:account, references -> v1:library:artifact, references -> v1:platform:sourceCredential, references -> v1:platform:sourceConnection

#v1:platform:packageDeployment

ONE ATTEMPT to deploy one version of one package -- the append-only timeline (D7). APPEND-ONLY IS THE CONTRACT, and it is what makes the row trustworthy. A row at a terminal status (succeeded / refused / failed) accepts no further writes; a retry is a NEW row. So the timeline of a package is the literal history of what was attempted and what happened, and it cannot be rewritten by the next attempt to look like it always went well. Same composite tier as its package -- the account argument included (memql#5303, D12), so a run is readable by exactly the people its package is -- and broadcast: the OS watches a deploy advance stage by stage, which is only true because each stage's status write is a row change the mesh forwards.

Relationships: parent -> v1:platform:package, references -> v1:accounts:account, references -> v1:library:artifact, references -> v1:platform:packageDeployment

#v1:platform:partitionSecret

Partition-scoped encrypted secret. Holds per-tenant sensitive values (BYOK vendor API keys, per-tenant Twilio/SMTP creds, etc.). Same wire shape as v1:platform:globalSecret, different scope. The cleartext value is NEVER stored -- only a NaCl secretbox ciphertext under MEMQL_MASTER_KEY and a fingerprint. When the partition-scoped resolver (resolveSecret) cannot find a row, it falls back to v1:platform:globalSecret so a tenant's BYOK key wins over the instance default but the instance default is always available.

#v1:platform:partitionVariable

Partition-scoped plaintext configuration variable. Holds per-tenant non-sensitive overrides (default chat provider, default language, feature flags scoped to a single tenant, etc.). Same wire shape as v1:platform:globalVariable, different scope. When the partition-scoped resolver (resolveVariable) cannot find a row, it falls back to v1:platform:globalVariable so a tenant's override wins over the instance default but the instance default is always available.

#v1:platform:providerAuthStatus

Virtual projection of one AI PROVIDER's auth state on THIS node (epic memql#4440). Never persisted -- rows are produced at query time by the owner-only providerAuthStatus builtin from the live provider registry, the same shape as v1:platform:dataOrigin and v1:router:modelCatalog. PER-NODE, and that is the point rather than a limitation. Provider auth resolves once per process at boot, so two replicas genuinely can disagree -- one restarted after a key was seeded and one not. That disagreement is the single most useful thing this read surfaces, and it is why providersReload broadcasts instead of acting on whichever replica the front door picked. NO CREDENTIAL, AND NO FINGERPRINT OF ONE. authSource names a TIER, never a value. The page never reads a key back; "is this key good" is answered by providerVerify making a live call, not by comparing against something rendered here.

#v1:platform:providerConfigResult

Virtual single-row RESULT of seeding AI provider configuration from Settings (epic memql#4440) -- providerFederationSet. Never persisted. THERE IS NO VALUE FIELD, AND THERE IS NO READ-BACK CONSTRUCT. Nothing written through this path is a credential any more (epic memql#5088 removed the key-sealing sibling along with every manually entered vendor key): what an operator supplies is a set of federation ids, and what comes back is the row NAMES the resolver will try. "Is this configuration good" is answered by providerVerify making a live call, not by showing an operator what they typed.

#v1:platform:providerVerifyResult

Virtual single-row RESULT of an owner-only providerVerify (epic memql#4440): whether ONE live, token-free call to the vendor was accepted using the credential THIS node resolved. A REJECTED KEY IS A RESULT, NOT AN ERROR -- verified=false carrying the vendor's own words. The distinction matters to the page: a refusal is something to show the operator in place, and an error is an exception dialog about a question that could not be asked.

#v1:platform:providersReloadResult

Virtual single-row RESULT of an owner-only providersReload (epic memql#4440). Never persisted: an action's outcome is a reply, not a record. What IS recorded is the v1:identity:auditEvent line naming who asked.

#v1:platform:readinessRecomputeResult

Virtual, never persisted: what readinessRecompute answers -- how many modules this node just rewrote, and which node it was. One row, id "current", because it answers one question about one node rather than describing a set.

#v1:platform:site

A web surface this cluster serves at a hostname -- a single-page app, a static website, or the platform's own site. A site is DATA, not infrastructure: deploying one is an upload plus a row write and rolling one back is a row write, so the number of Kubernetes objects does not grow with the number of sites. The graph's own row history IS the version list. Organization-owned sites are shared through current membership and app permissions; writes additionally require data and action rights for the target organization. Creation stamps the authenticated person as ownerUserId. Shared edits preserve that owner and record the current writer separately on each version. Cluster operators retain their standing scope, and historical sites without organization attribution retain their existing owner rules. ownerUserId EMPTY means cluster-owned, and the seeded platform-site row is the case: sameRowAuthzOwner refuses an empty owner outright, so a cluster-owned row is reachable through the admin branch alone -- never by a caller who happens to have no identity resolved.

Relationships: parent -> v1:identity:user, references -> v1:platform:package, references -> v1:library:artifact, references -> v1:accounts:account

#v1:platform:siteHealth

Synthetic current website observation, stored outside append-only graph history. siteHealthRead authorizes every result against the current site under the caller.

#v1:platform:sitePreviewGrant

A client's own domain, bound to one of this cluster's deployables (epic memql#4805). The row is the STATE MACHINE. Nothing else holds it: a scheduled sweep reads these rows, does two DNS lookups per non-terminal one, and writes back what it saw; when both checks pass it dispatches an idempotent capability script that applies the exact-host Ingress + Certificate pair. The engine gains NO Kubernetes client for any of it -- an in-engine client-go reconciler would be a second way to touch cluster objects beside the GitOps/script path, which is the exact thing environment-parity review rejects (design D2). clusterOwner tier, for the reason v1:platform:packState and v1:platform:site's predecessor both carry it: what a cluster SERVES AT ITS FRONT DOOR is one deployment's fact. Certificate issuance and Ingress objects are cluster-level resources with real rate limits, so v1 automates what was already owner territory rather than widening it (D1). Widening is additive -- the v2 shape is a request-and-approve queue, and it needs no change here. ROWS SURVIVE REMOVAL. remove walks the row to removed; nothing deletes. A binding that once existed is the audit trail of what this cluster was serving and when, and a deleted row answers no question anybody asks after an incident. A PREVIEW GRANT: one operator's short-lived permission to be served a deployable's CANDIDATE VERSION on the site's own origin (epic memql#5531, issue memql#5545). WHY A ROW AND NOT A SIGNED TOKEN. A signature would verify on every replica with no read, which is the property that made the app-session credential DB-free -- and the price of it there is stated plainly: it is not revocable. Here the price is not worth paying. A preview is a handful of requests by one person, so the read is nothing; and three things fall out of the row that a signature cannot give. It is REVOCABLE, so "end this preview" is an act rather than a wait. It is LISTABLE, so an operator can see what is open against a deployable rather than guessing. And it is the ANCHOR every v1:platform:sitePreviewObservation hangs off -- without a session id there is nothing to gather four observations of one exercise under. IT NAMES THE VERSION IT WAS ISSUED FOR, and that is what keeps it honest. The edge compares candidateRef against the site row's, so a grant stops resolving the moment the candidate is withdrawn or republished -- a person previewing version N+1 is never silently shown N+2, and clearSiteCandidate is therefore also how every open preview of a version ends at once. The same rule the work spine's approvals use, for the same reason: a decision about one specific artifact must not carry to a different one. THE TOKEN IS HASHED AND RETURNED ONCE, exactly as a worker token is (component/identity/ workertoken): the plain mql_prv_<43> goes back to the caller in the mutation reply and only its SHA-256 is stored, so a row read -- by an operator, by a support session, out of a backup -- hands nobody a working preview. THE TIER IS COMPOSITE, and the cluster-owner half is what lets an operator see and end a preview somebody else opened. The EDGE reads these rows under its own synthetic cluster-owner actor, the same one it resolves a site and a store with, which is why it can honour a grant belonging to any operator without holding anybody's credential.

Relationships: parent -> v1:platform:site, references -> v1:identity:user

#v1:platform:sitePreviewObservation

WHAT THE ENGINE CAN OBSERVE OF A PREVIEW, said plainly and not one thing more (epic memql#5531, issue memql#5547, design D8). The owner wants the sandbox to prove a storefront works "for real", payment included. Four of those steps are the engine's to observe and the fifth is not, and this concept is where that line is drawn rather than blurred: catalog_read the development store answers a catalog read cart_accepted a cart accepts a line checkout_url a checkoutUrl comes back order_mirrored an order arrives in the mirror under that store's storeId THE PAYMENT WALK IS NOT HERE. It happens in a browser on Shopify's hosted checkout, and no row this cluster writes can witness it; the test that does is the product's (znasllc-io/memql-fylo#28). A fifth value naming it would be a field nothing could ever honestly write -- and a declared field with no writer reads as a measurement that came back empty. THE FIRST THREE ARE ACTIVE, THE FOURTH IS PASSIVE, and they are one concept because they answer one question. The first three are the engine ASKING the bound store, through the Storefront API, under the preview binding's token (integrations/shopify/storefront.go); the fourth is the engine NOTICING that the mirror received an order under the preview store's id. ok is what separates them from silence: a row here is an answer, and the absence of a row is not a failure but an exercise nobody has run. AN UNMEASURED OBSERVATION IS NOT A FAILED ONE. There is deliberately no row written to say "we did not look", because the OS draws the absence itself and drawing it from a row would make "nobody asked" and "we asked and got nothing" the same shape on the screen.

Relationships: parent -> v1:platform:sitePreviewGrant, references -> v1:platform:site

#v1:platform:sourceConnection

A person's saved GitHub installation access grouping. It carries no token and no MemQL owning account. Removing it affects new selections only; packages retain their credential and deployed sites remain untouched.

Relationships: parent -> v1:identity:user, references -> v1:platform:sourceCredential

#v1:platform:sourceCredential

A PERSON'S credential for reading a private source (epic memql#4885, D10). One row is one token on one host, sealed once, server-side, and named by the packages that fetch under it. It replaces the cluster-wide globalSecret a package used to NAME: any package owner could name any secret, so the fetcher could be made to fetch under an owner's token by whoever knew the name. Here the credential belongs to the person, the composite tier decides who reads it, and the fetcher resolves it under the PACKAGE OWNER's actor -- so a package naming somebody else's credential resolves zero rows and is refused by name, before any request leaves the cluster. The COMPOSITE tier, for the reason v1:platform:site and v1:platform:package record: a plain owner tier has no cluster-owner escape on the read path, so "every credential in this cluster" would not be EXPRESSIBLE and an operator would silently read a subset. A cluster owner reads every row's METADATA -- host, label, fingerprint, last used -- which is the oversight the tier exists for, and can decrypt none of it from a browser: sourceCredentialCard projects everything but the ciphertext, and decryption happens only inside a fetch. A REVOKED ROW IS NEVER DELETED. It is the audit history of what fetched under it -- every deployment whose source arrived through this token is a fact about this row -- and a deleted row answers no question anybody asks after an incident. Revocation flips status and stamps revokedAt; rotation is adding a new credential and switching a source to it.

Relationships: parent -> v1:identity:user

#v1:platform:syncState

Per-(concept, connector) SYNC HEALTH (epic memql#4378, D7). Health is a ROW, not a log line: an operator asking "is the Shopify mirror current" needs an answer that survives a restart and can be read from a page, not a grep over one replica's stdout. Written ONLY by the sync runtime -- the inbound dispatcher, the backfill and reconciliation runners, and the outbox drain worker. Deterministic id per (concept, connector, direction), so the append-only version history IS the health timeline. clusterOwner for the same reason outboxEntry is: this is the deployment's operational state.

#v1:rbac:capability

A single authorization GRANT: the right to apply one primitive verb to one resource type, attached to a role. Capability = (verb x resourceType) for a role. This is the atomic unit of the consolidated RBAC model (epic memql#2062). The five verbs (read/create/update/delete/execute) are UNIFORM across every resourceType, including principal -- applying a verb to the principal resource is how user-management governance is expressed (E1.3): e.g. update on a principal, gated by a rank+self predicate, means 'edit a user'; create on a principal means 'add a user' WITHOUT necessarily being able to edit existing ones (the create != update split). A role's effective grants are the union of its capability rows. Global / immutable reference data: authored as seed rows materialized into _system, readable by every principal, never per-user-owned. PUBLIC per-row-authz tier -- it is deployment-wide config, not user data. roleSlug points at the role this grant belongs to; the role rows themselves land in E1.2 (memql#2070), so until then capabilities reference a role purely by its stable slug string.

#v1:rbac:grant

A GRANT TO A PERSON OR A GROUP: one (verb x resourceType) decision, allow or deny, whose subject is a v1:identity:user or a v1:identity:group rather than a role (epic memql#5294, the app access grants record, decision D6). It sits BESIDE the role catalog and never inside it: capability says what a ROLE holds and grant says what a PERSON or a GROUP holds over and above their role, and the two have different lifecycles and different caches -- the catalog is loaded once and reloaded on its events, a grant is read per request and never cached. A ROLE IS NEVER A SUBJECT HERE. A role's abilities are edited on the role, as capability rows, and putting them in two places is how they drift: a deny on a role written here and an allow written there would be two answers to one question with nothing to say which wins. subjectKind is therefore a closed two-value set, and a resolver that met a third would have no level to place it at (the record's rule is person over group over role). THIS ROW IS THE DEPLOYMENT'S, NOT ANYONE'S PROPERTY, and that is why the tier is @rowAuthz(clusterOwner, rankFloor="admin") with no owner field at all. The obvious owner would be the subject -- and an owned row admits its owner's INSERTS, so scoping a grant to the person it names would hand every signed-in person a primitive for granting themselves an app. The granting user is not the owner either: a grant outlives the person who wrote it and is revoked by whoever holds the authority then, not by whoever held it once. So the row belongs to the deployment, is READABLE from admin rank (the floor relaxes the read and leaves the write at clusterOwner, memql#5216), and is WRITTEN only by Go under internal origin through the two @serverOnly mutations below -- exactly as v1:identity:group and groupMembership are. THE ROW ID IS DERIVED from (subjectKind, subjectId, verb, resourceType), the way groupMembership derives its id from (group, user): re-granting writes a new VERSION of one logical row rather than a second row, and revoking writes active: false at the same id so history survives. Every reader collapses to the newest version per id first, because MemQL rows are append-only. subjectId IS POLYMORPHIC AND STORED BARE, discriminated by subjectKind -- the v1:identity:auditEvent targetType / targetId shape. A single field cannot carry two @relationship targets, and a relationship declared for one kind would canonicalize the other kind's id under the wrong concept; two nullable typed fields would make the derived id and the resolver branch on which one is set. So the field is exempted from the id-bearing-field gate by name, and the resolver matches it against both spellings of the actor's ids. RESOLUTION (component/auth.CapableFor): the role catalog answers first, with its own deny-wins inside that level; the actor's active GROUP grants overlay it, deny winning if the actor's groups disagree; the actor's own USER grants overlay that. Most specific wins across levels, deny wins within a level. No expiry: a stale grant is revoked by a person, not by a clock.

Relationships: references -> v1:identity:user

#v1:rbac:role

A named, RANKED bundle of capabilities -- the role half of the consolidated RBAC model (epic memql#2062). A role's effective authorization is the union of its v1:rbac:capability grants (joined by roleSlug). E1.2 (memql#2070) authors the FOUR base roles as immutable seed rows: owner (400) > developer (300) > admin (200) > user (100). The rank ordering is the locked decision -- developer OUTRANKS admin (the power axes differ: developer is engineering authority, admin is user-management authority) and owner is self-managed only. Ranks are spaced integers (not 1/2/3/4) precisely so E1.4 (memql#2072) custom roles can SLOT BETWEEN existing ranks (e.g. a 'lead' at 250 sits above admin but below developer) without renumbering. The governance predicates in E1.3 (memql#2071) compare actor.rank vs target.rank to decide who-can-manage-whom. Base roles are IMMUTABLE at runtime: predefined=true rows are re-materialized from this DSL on every boot and a Go pre-insert guard (validateRbacBaseRoleImmutable) rejects any non-system-actor write to them, so a base role can never be redefined as data to escalate privilege. Custom roles (predefined=false) are addable as DATA via the rank-bounded createRole path in E1.4. Global / _system reference data: readable by every principal so any node resolves a rank locally; PUBLIC per-row-authz tier.

Relationships: references -> v1:accounts:account

#v1:router:budget

Spend limit for a partition or a specific agent within a partition. The router checks the current-period spend against this cap before every AI call; over-budget calls are refused with a typed error that surfaces in the UI as a clear 'budget reached' state. Rolls over at periodType boundary (UTC day, week, or month).

Relationships: references -> v1:agents:agent

#v1:router:call

One AI invocation recorded by the MemQL AI Router. Every call through the router -- agent replies, prompt renders, suggest endpoints, TTS, transcription -- produces exactly one row here with attribution, token counts, latency, and cost. Partition-scoped usage ledger; the time-series axis rides the shared MemoryNodes hypertable. @rowAuthz(public, requiresIdentity) -- THE TIER THAT IS TRUE OF THIS ROW, and it is not the one memql#5162 recommended. The issue asked for an unowned RANK FLOOR; measuring the readers showed a rank floor cannot serve them. userId here is ATTRIBUTION -- the person whose call was served -- and not ownership. The row is the DEPLOYMENT'S: nobody can delete it, nobody can edit it, and it exists whether or not that person still does. So owner="userId" was the obvious declaration and the wrong one; it asserts a guarantee nothing provides, and TestDeclaredOwnerFieldsAreServerStamped refuses it, correctly -- recordRouterCall writes the field from CALLER ARGS. It cannot be server-stamped either, because the writer's actor IS system:router, so stamping actor.userId would make the router the owner of every row. THREE CONSTRUCTS READ THIS CONCEPT AND THEIR AUTHORIZATIONS ARE THREE DIFFERENT KINDS. That is the measurement memql#5162 did not have, and it is what rules a rank floor out: routerDecisionsRecent @requiresRank("admin") admin and above routerCallsInWindow actor.isClusterOwner==true the maintenance principal routerCallsOnMachine NO rank gate -- fleetSharingLedger proves the caller owns the machine first, and the surface argument is derived from a registration already proven theirs ANY rank The Fleet app carries no role floor, so the third reader is a plain writer who paired a laptop, asking how busy their own machine has been. A rank floor on the ROWS would empty that surface for exactly the person it is for -- and with no error, which fleetSharingLedger's own description refuses by name: a read that fails answers readable: false rather than zero, because telling somebody who lent their machine that nobody used it is a specific claim and a failed read is not evidence for it. So the honest tier is the one that says there is no row-level distinction this concept can draw, AND that this is not an invitation to the internet. That is what requiresIdentity is for in its own words, and its documentation prescribes what comes next: authorization for such a concept lives at the SURFACE, where @requiresRank puts it. All three gates above are already there. WHAT THIS CHANGES, since a tier that changed nothing would be the failure memql#5162 is about: the concept leaves the undeclared population, where it admitted EVERY caller on the read path and on the subscription path -- including an anonymous one, because rowAuthzAdmits answers ADMIT for an undeclared concept. An anonymous caller is refused now. What it does not change is which signed-in callers reach it through an unbound read; that stays the surfaces' business, and saying so plainly is the point.

#v1:router:modelCatalog

Virtual projection of a registered AI provider entry. Never persisted -- rows are produced at query time by the integration.router.listModels capability from the live provider registry. Lives in the concept registry so the engine can shape results without a database round-trip.

#v1:router:policyCatalog

Virtual projection of a registered AI Router policy. Never persisted -- rows are produced at query time by the integration.router.listPolicies capability from the live policy registry. Lives in the concept registry so the engine can shape results without a database round-trip.

#v1:safety:approvalRequest

One row per Ask-verdict approval request. The Gate's ApprovalSink creates a pending row on first encounter (keyed by correlationKey for idempotency), then resolveApprovalRequest flips it to approved / denied. The Gate's bypass check queries by correlationKey: an approved non-expired row returns proceed=true on the next retry of the same gated action; otherwise the refusal text references the request id so a human can resolve it. Distinct from v1:safety:classification -- classification is the per-decision audit row (one per evaluation); approvalRequest is the per-(surface, action, payload) bypass token (one per unique action, reused across retries).

#v1:safety:classification

One row per safety-classifier decision. Captures what the Gate decided, the verdict source (rule / model / cache), the surface + action it was deciding about, and the (redacted) payload. Retention is governed by the MEMQL_SAFETY_CLASSIFICATION_RETENTION_DAYS env var (default 90); the daily purge automation hard-deletes rows whose createdAt + retentionDays < now. This concept covers the safety-classifier verdict + final gate decision per command. (It used to be contrasted here with v1:platform:policyTrace, which covered the decision-policy evaluation tree; that whole subsystem was removed in memql#4114 -- the decision-policy tier it belonged to was retired in #984 and nothing ever wrote a row.)

#v1:safety:outputScreening

One row per output-screening decision. Captures what the OutputGate decided about a single piece of incoming content before the model re-ingested it. Distinct from v1:safety:classification: classification covers agency (should this command run?); outputScreening covers ingress (should this string land in the model's context?). Retention is governed by MEMQL_SAFETY_OUTPUT_SCREENING_RETENTION_DAYS (default 90).

#v1:shopify:abandonedCheckout

Shopify AbandonedCheckout, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:article

Shopify Article, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:blog

#v1:shopify:articleComment

Shopify Comment, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:article

#v1:shopify:blog

Shopify Blog, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:businessEntity

Shopify BusinessEntity, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:catalog

Shopify Catalog, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:channel

Shopify Channel, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:collection

Shopify Collection, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:company

Shopify Company, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:companyContact

Shopify CompanyContact, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:company

#v1:shopify:companyLocation

Shopify CompanyLocation, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:company

#v1:shopify:complianceJob

One queued Shopify privacy request. A job rather than an immediate action, because both windows are measured in days: customers/redact has thirty and shop/redact a 48-hour hold, and the receiver has five seconds. Running on receipt would also override a merchant's own grace period if one is configured. It is deliberately NOT a v1:platform:outboxEntry. The outbox is for MemQL-authored rows the connector PUSHES, and its drain hands every entry to Propagate -- a compliance job handed to Propagate would try to write a customer's export into Shopify. Same shape of work, different destination, so a different queue.

#v1:shopify:customer

Shopify Customer, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:customerPaymentMethod

Shopify CustomerPaymentMethod, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:customer

#v1:shopify:deliveryCarrierService

Shopify DeliveryCarrierService, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:deliveryCustomization

Shopify DeliveryCustomization, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:deliveryProfile

Shopify DeliveryProfile, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:discountNode

Shopify DiscountNode, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:draftOrder

Shopify DraftOrder, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:fulfillment

Shopify Fulfillment, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:order

#v1:shopify:fulfillmentOrder

Shopify FulfillmentOrder, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:giftCard

Shopify GiftCard, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:inventoryItem

Shopify InventoryItem, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:inventoryLevel

Shopify InventoryLevel, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:inventoryItem

#v1:shopify:inventoryShipment

Shopify InventoryShipment, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:inventoryTransfer

Shopify InventoryTransfer, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:location

Shopify Location, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:market

Shopify Market, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:marketWebPresence

Shopify MarketWebPresence, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:market

#v1:shopify:marketingActivity

Shopify MarketingActivity, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:marketingEvent

Shopify MarketingEvent, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:menu

Shopify Menu, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:metafieldDefinition

Shopify MetafieldDefinition, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:metaobject

Shopify Metaobject, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:metaobjectDefinition

Shopify MetaobjectDefinition, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:onlineStoreTheme

Shopify OnlineStoreTheme, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:order

Shopify Order, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:orderLineItem

Shopify LineItem, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:order

#v1:shopify:orderTransaction

Shopify OrderTransaction, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:order

#v1:shopify:page

Shopify Page, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:paymentTermsTemplate

Shopify PaymentTermsTemplate, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:priceList

Shopify PriceList, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:priceListPrice

Shopify PriceListPrice, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:priceList

#v1:shopify:product

Shopify Product, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:productFeed

Shopify ProductFeed, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:productVariant

Shopify ProductVariant, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:product

#v1:shopify:publication

Shopify Publication, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:quantityRule

Shopify QuantityRule, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:priceList

#v1:shopify:refund

Shopify Refund, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:order

#v1:shopify:reverseDelivery

Shopify ReverseDelivery, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:reverseFulfillmentOrder

#v1:shopify:reverseFulfillmentOrder

Shopify ReverseFulfillmentOrder, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:shopifyReturn

#v1:shopify:segment

Shopify Segment, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:sellingPlan

Shopify SellingPlan, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:sellingPlanGroup

#v1:shopify:sellingPlanGroup

Shopify SellingPlanGroup, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:shop

Shopify Shop, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:shopLocale

Shopify ShopLocale, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:shopPolicy

Shopify ShopPolicy, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:shopifyPaymentsBalanceTransaction

Shopify ShopifyPaymentsBalanceTransaction, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:shopifyPaymentsDispute

Shopify ShopifyPaymentsDispute, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:shopifyPaymentsPayout

Shopify ShopifyPaymentsPayout, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:shopifyReturn

Shopify Return, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:order

#v1:shopify:staffMember

Shopify StaffMember, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:store

A configured Shopify store. NATIVE, not a mirror: this is MemQL's own record of how to reach a store, and Shopify has no corresponding object. One connector, many stores -- every mirrored row carries the storeId of the row it came from, and every read is scoped by it. Readable by developers and cluster owners, writable by cluster owners (Connect Shopify, decision D3). rankFloor widens the READ only: a developer sees every store, and changing one that exists stays owner-only. Below developer, a read answers zero rows rather than an error.

Relationships: references -> v1:shopify:store

#v1:shopify:storeCreditAccount

Shopify StoreCreditAccount, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

Relationships: parent -> v1:shopify:customer

#v1:shopify:subscriptionContract

Shopify SubscriptionContract, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:tenderTransaction

Shopify TenderTransaction, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:shopify:urlRedirect

Shopify UrlRedirect, mirrored. Cluster-owner tier: commerce data is business data, not per-user data (design D5).

#v1:skills:skill

First-class capability bundle: a named unit of (knowledgeDomains + toolSlugs) that the Planner Agent attaches to agents in createSpecialist / extendSpecialist. It also carries liveSourceIds, which has been inert since the live-knowledge mechanism was retired (memql#5432). After the full skills rollout (#157 -> #158 -> #159) the agent factory pulls skills off the catalog rather than threading parallel flat lists; this concept is the spine of that surface. Phase 1 (this PR) lands the schema + a 13-row predefined catalog; consumers don't read skills yet. Phase 2 migrates roles + agents to skillIds[]; Phase 3 lands the mintSkill authority + approval card.

Relationships: parent -> v1:identity:user, references -> v1:work:goal, references -> v1:work:run

#v1:skills:skillEdge

A typed relationship between two skills. Compile may propose an edge; a run that succeeds commits it (the propose-then-commit protocol, spec section C). Selection reads committed edges beside vector matches.

Relationships: references -> v1:skills:skill, references -> v1:skills:skill

#v1:todos:todo

A user-owned to-do item: a titled task with a done flag plus optional due date, priority, and a back-pointer to the responsibility that spawned it. The standalone source-of-truth to-do concept the assistant manages on the user's behalf. Per-row authz: owned -- ownerUserId is stamped from actor.userId on every write and every read gates on row.ownerUserId == actor.userId.

Relationships: parent -> v1:identity:user

#v1:work:approval

One human gate. Every kind of gate is this concept; an approval never carries to a modified artifact, because resume compares artifactHash. It broadcasts.

Relationships: parent -> v1:identity:user, parent -> v1:work:run

#v1:work:feedbackPolicy

The VALUES epic memql#5414 decides by (design record docs/superpowers/specs/2026-09-13-app-session-recording-and-learning-program-design.md, D22 and D24, and section 5 "Values, not constants"): whether the answer validator runs at all, and how many distinct goal signatures make a construct reusable. They are rows rather than constants so a person can read the numbers the system is applying, and so the Go that applies them carries the same numbers only as component/work.DefaultFeedbackPolicy() for an absent or unreadable row. ONE ROW, AT A LITERAL ID: v1:work:feedbackPolicy:primary, written by seed feedbackPolicy feedbackPolicyPrimary (dsl/work/seeds.memql) through createFeedbackPolicy. A global seed is re-asserted on every boot on every node, fields the seed declares winning, so an edit made anywhere else does not survive a restart. Every read pins the literal id, so a stray row at any other id is never mistaken for the policy. TIER: @rowAuthz(clusterOwner, rankFloor="reader"), exactly as v1:authoring:ladderPolicy: every signed-in person READS it, and the WRITE stays with the cluster owner or trusted server-side Go stamping internal origin (the seed materializer), with createFeedbackPolicy @serverOnly in front of that. There is no owner field because the values are the deployment's. The floor names reader, viewer's alias, because the load-time floor check runs before the rbac catalog is readable and viewer would rank 0 there.

#v1:work:goal

The intent, owned by a person. Execution state does not live here: it lives on the run, so a goal that has been re-run, forked or repaired still reads as one thing.

Relationships: parent -> v1:identity:user, references -> v1:planner:responsibility

#v1:work:modelCall

One model request, journaled so a replay can serve it without a provider. Owner tier, a hypertable with retention (epic A2), never broadcast.

Relationships: parent -> v1:identity:user, parent -> v1:work:run

#v1:work:observation

What a step observed beyond its result: a tool result, an error, a note, a decision. The embedding source for recall, so the journal is the episodic memory. Never broadcast.

Relationships: parent -> v1:identity:user, parent -> v1:work:run

#v1:work:run

One execution against a goal, or -- in epic A1 -- one automation execution with no goal. Created the moment the run starts so every later write has a home. The node and heartbeat fields follow the deployment-run pattern (exactly-once per replica, the abandoned sweep in A2).

Relationships: parent -> v1:identity:user, parent -> v1:work:goal, references -> v1:authoring:construct

#v1:work:step

A node of a run. A retry is a NEW VERSION of the same row with attempt incremented; the intent is the running version written before the body executes and the receipt is the done or failed version written after. Resolved step arguments are deliberately NOT recorded here (they may carry resolved secrets); call names what ran, result is the trimmed result shape.

Relationships: parent -> v1:identity:user, parent -> v1:work:run

#v1:workbench:workspace

Per-Plan workbench workspace. Tracks the persistent filesystem mounted into every per-Task container running under the run. Created lazily on first workbenchHost call; released when the parent Plan transitions to a terminal status (succeeded / failed / cancelled). Universal authorization -- no scope grants, no kill switch, no per-agent gating; the workbench is sandboxed inside the cluster and the blast radius is contained to the per-Plan directory tree. TIER: the composite owner, clusterOwner (memql#4312). A workspace is a directory of one person's working files -- whatever their plan wrote -- so it is theirs; the operator who has to answer "why is this workbench node full" needs to see all of them. ownerUserId is stamped from the parent plan's requestedBy at provision time and never from a caller argument.

Relationships: parent -> v1:work:run, parent -> v1:identity:user

#v1:worker:appSession

One delegated run of a local app on a cockpit machine (memql#4360). A session is the unit because a headless claude -p can run for an hour: the row is created at start, its transcript appends from streamed chunks while the run is live, and it reaches a terminal status at end. The transcript on the row is BOUNDED -- the full one is pushed to the Library as a produced artifact when the session ends, so the row stays a readable summary rather than growing without limit. Owner-tier with the cluster-owner gate ORed in: an operator debugging a delegated run must be able to read it, and a plain owner tier would hide every other user's sessions from them.

Relationships: parent -> v1:identity:user, parent -> v1:worker:registration, parent -> v1:work:run, references -> v1:work:run, references -> v1:library:file, parent -> v1:work:step

#v1:worker:delegationPolicy

Per-user preference deciding when the planner delegates a task to a local app instead of running it in-process (memql#4362). Delegation is a PREFERENCE with a fallback, never a requirement: the planner asks whether a machine with an allowed, signed-in app is online, and runs in-process when none is. A plan never waits for a laptop to wake up.

Relationships: parent -> v1:identity:user

#v1:worker:invocation

Per-call telemetry for worker tool invocations. Written once on call completion (success / failure / cancelled / timeout / denied). Operator reads these for plan debugging; auditor reads identity:auditEvent for the security timeline. Linkage between the two layers is via correlationId. Retention default 90 days, tunable via WORKER_INVOCATION_RETENTION_DAYS; the workerInvocationRetentionSweep cron soft-deletes rows past their TTL. TIER: the composite owner, clusterOwner (memql#4406). It carries argsRedacted and outputPreview, and outputPreview's own field doc says the quiet part out loud -- "Sensitive tokens are NOT scrubbed here -- preview is for owner eyes". That sentence described an intent the schema did not enforce: with no tier declared, every row was admitted to every caller on the read path. The composite rather than a plain owner tier for the same reason v1:worker:registration takes it -- a plain owner tier hides every other user's calls from the operator who has to support them. What it cost, recorded because the issue was filed to STOP it being discovered: the retention sweep is a system-actor path, and contextWithSystemActor stamps RoleReader, so an owned tier makes it read zero rows and retire nothing -- silently, with WORKER_INVOCATION_RETENTION_DAYS quietly ceasing to mean anything. That is now decided rather than found: workerInvocationRetentionSweep runs under the cluster's maintenance principal (component/automations/maintenance_actor.go) and expiredWorkerInvocations carries actor.isClusterOwner==true so the arrangement is legible at the read.

Relationships: parent -> v1:identity:user, parent -> v1:worker:registration, parent -> v1:agents:agent, parent -> v1:work:run, parent -> v1:work:step

#v1:worker:modelProbe

One probe in flight, and the record of how it went (epic memql#5146, D3). v1:worker:modelPull's SIBLING, deliberately, down to the claim field and the stale sweep. A probe runs a suite of generations and takes minutes, which is the same shape of problem a download is: a person presses a button, something long happens on hardware the cluster does not own, and the only honest way to watch it is a row that moves. IT IS NOT THE MEASUREMENT. The figures land on v1:platform:modelMeasurement, and the split is what keeps a measurement clean: this row carries a status, a case counter and a failure sentence -- the mechanics of one attempt -- where a measurement carries only what was measured, keyed by the suite that measured it. A probe that crashed leaves a failed row here and no measurement at all, which is exactly right: nothing was measured. A ROW LEFT AT requested OR running is one whose replica died holding it, and workerModelProbeStaleSweep marks those failed. A spinner that never resolves is the one outcome this surface must not produce, and a probe is more exposed to it than a pull: it holds somebody's GPU, so a request nobody picked up costs them nothing but a request nobody FINISHED might. TIER: the composite owner, clusterOwner, matching the pull and the registration it names.

Relationships: parent -> v1:identity:user, parent -> v1:worker:registration, references -> v1:platform:modelMeasurement

#v1:worker:modelPull

One request to pull a model onto a fleet machine, and the record of how it went (epic memql#5103, design D3). PERSISTED, DELIBERATELY, and it is the one row in this file whose persistence needs defending. Its siblings v1:platform:fleetModel and v1:platform:inferenceStatus are VIRTUAL because they answer "what is true right now" and a stored copy could only be a staler second answer. A pull is the opposite kind of fact: it is an EVENT WITH A DURATION that somebody started and is watching, so there is no live source to re-derive it from -- the download exists only in one process on one replica, and if that process dies the row is the only thing that can say a pull was ever asked for. IT IS ALSO THE PROGRESS FEED. A pull runs for minutes to hours and the person who pressed Pull is watching, so progress has to reach a browser. A virtual concept is produced at query time and cannot stream; a graph row broadcasts, and the OS's live surfaces are already fed that way. So the row is written at request, updated on a throttle while the download runs, and finalised at the end -- and the same rows answer "why is this model here" long after anyone stopped watching. THE COUNTERS DESCRIBE ONE LAYER, NEVER THE WHOLE PULL. Ollama fetches a model as a set of blobs and reports completed/total PER BLOB, restarting at zero for each. There is no whole-pull denominator anywhere in the protocol, so this row does not invent one: a reader renders progress WITHIN the current step and reads statusLine for where the pull as a whole has got to. A percentage across layers would be a number this cluster made up, and it would be wrong in a way nobody could see.

Relationships: parent -> v1:identity:user, parent -> v1:worker:registration

#v1:worker:registration

Operational registration of a worker -- the runtime record for a memql-cockpit instance running in worker mode and connected to this cluster. Persists stable identity + capabilities + last-seen state. The currently-connected gRPC stream + per-call concurrency live in-memory on whichever agent node holds the stream; this concept is for everything that needs to survive disconnect and binary restart. Per-user routing: every registration is owned by exactly one v1:identity:user; only agents in sessions owned by that user can dispatch tools to this worker. TIER: the composite owner, clusterOwner (memql#4312). A registration is one person's machine -- it carries their hostname, their platform, the IP it last connected from -- so the owner tier is the right one, and a plain owner tier would hide every machine from the operator who has to support them. The engine ANDs (row.ownerUserId == actor.userId || actor.isClusterOwner == true) onto every read and refuses a write onto a row failing the same test. The tier is why component/worker's store stamps auth.ContextWithUserActor(ctx, ownerUserId) on its registration reads and writes: the worker authenticates as worker:<id>, not as its owner, so an unstamped read of the row the register handshake needs would be refused for having no actor at all. The owner id it stamps comes from the worker_token's identity row, resolved by the interceptor before any of this runs -- never from the Register message.

Relationships: parent -> v1:identity:user, parent -> v1:identity:identity, parent -> v1:identity:user

#v1:worker:routingPolicy

The owner's routing policy: which of their machines gets a piece of work, and what happens when the first choice refuses. ONE ACTIVE ROW PER USER -- createRoutingPolicy and updateRoutingPolicy enforce it, and the router reads the active one through routingPolicyForOwner. ABSENT IS A VALID STATE and the common one. A user who never opened the Fleet page has no row, and the router applies firstFit + nextMatching: today's behaviour plus a re-pick. The default is deliberately the safest pair rather than the cleverest -- firstFit is what Registry.PickWorker did, and nextMatching only ever moves past a candidate that refused BEFORE running anything (design D5). THE AGENT NEVER WRITES THIS, and cannot name a machine at all: the dispatch builtins take requireLabels / preferLabels and no workerId (design D4). An agent expresses what the work needs; the policy decides where it lands. That is what makes a hallucinated machine id a failure mode this design does not have.

Relationships: parent -> v1:identity:user