Primitives catalog
A primitive is a building block Blueprint owns, so that an application in any industry is expressed as declarations plus a small set of domain plug-ins. This page lists every primitive, grouped by family, with an honest status.
DRAWING 003 / PRIMITIVES CATALOGSTATUS · ● ◐ ◇ ○
Status marks
| Mark | Meaning |
|---|---|
| ● | Runs. Declared, executed by the runtime, and used by an application. |
| ◐ | Partial. Executed, but with a known gap. The gap is named. |
| ◇ | Designed. Designed, not implemented. |
| ○ | Declared only. The vocabulary exists, but nothing executes it yet. |
A declaration is not counted as runtime support. Verify behaviour in your target environment.
What makes a primitive
- It is industry-neutral. It serves, unchanged, a batch deviation, an aircraft part nonconformance, a loan approval, a food-safety log, and an ordinary CRM. Anything that fits only one domain is configuration or a plug-in.
- Rigor is a setting, not a concept. Audit depth, signatures, retention, witnesses, separation of duties, and immutability are settings on the same primitives. There is no "regulated entity" next to an entity.
- There is one way to change. Every state change, including a workflow step and a person's answer to a task, is an action with a ledger record.
- Developers declare meaning; customers author definitions. Meaning is declared in Dart. Processes, forms, checklists, and reports that customers design at runtime are versioned definitions, validated, published, and activated.
- Extension is a declared slot. Custom SQL, endpoints, renderers, and evaluators have a typed contract. A missing binding is a readiness failure, never a silent fallback.
- Declared means executed. A primitive ships with its runtime and a test, or it is not exported.
A. Model: what exists
| Primitive | What it means | |
|---|---|---|
| ● | Entity, facet, descriptor | An identity plus coherent aspects; another module can contribute facets. |
| ● | Field tokens and semantic fields | Typed values that carry wire, validation, and storage meaning. |
| ● | Relationship | Typed graph edges with cardinality and cascade rules that preserve history. |
| ◐ | Versions and revisions | Immutable versions on save; governed revisions from draft to effective to superseded. Not yet: retiring a revision through its approval workflow. |
| ◐ | Temporal validity | Effective-from and effective-until windows, and reads as of a date. Not yet: as-of reads are unverified. |
| ◐ | Invariant | A truth over a whole set, such as "one active per site", held as a ModelInvariant.expression (an Expr<bool>). Not yet: aggregates and conditional unique keys. |
| ○ | Identifier | Human numbering with masks, reset scopes, and a gap-free option. |
| ◐ | Measured values | Quantity, unit, money, and currency. Not yet: unit conversion is unverified. |
| ◐ | Artifact | Binary content: a module's StorageBucket and a FileField bound to it, resumable chunked uploads, SHA-256 digest, MIME and size rules, signed downloads, and an append-only audit per file; see File storage. Not yet: retention rules, write-time verification of a file reference, S3 or Supabase byte stores, and a Studio picker and preview. |
| ◐ | Controlled vocabulary | Governed classification lists with revisions and activation. Not yet: retirement that checks what still uses a term. |
| ◇ | Runtime schema | Typed values whose schema is a customer-designed form, validated on the server. |
| ◇ | Cross-application reference | A reference to a record in another application, pinned to a revision. |
| ◇ | External system | An inventory of external systems and the identities of their records. |
| ◇ | Deferred effectivity | A revision approved now that takes effect on a future date. |
| ◇ | Derived value | A value computed from fields and policy values, by the server or in SQL. |
| ◇ | Relationship aggregate | Count, sum, min, max, exists, all, and none over a relationship. |
B. Change: how state moves
| Primitive | What it means | |
|---|---|---|
| ● | Action | The one mutation boundary: plan, preflight, ordered locks, expected version, idempotency, write, record. |
| ◐ | Rule and Rule.test | Gates that decide availability and check before and after commit. A rule keeps its phase, severity, structured error, and provenance; its test is an Expr<bool> that passes only on a known true. Not yet: deferred rules and tests over other records. |
| ● | Actors | Builders for an actor expression, one Expr<bool> over the acting user (role, group, department, user, initiator, inField, allowedAction, qualified, anyone, noOne, allOf, anyOf, noneOf). One expression serves a gate, an assignment, and an IAM access check. |
| ● | Facts and blueprintFactPorts | Builders for the host facts a test reads (grant, qualified, policyAllows, evidencePresent, evaluator, stateIs), and the registry of the fact ports behind them (FactPortNames). The host pins each fact before the test runs; an unresolved fact is unknown and fails closed. |
| ● | ActorTargets | Reads an actor expression for enumeration: a user, a role, a group, an in-field fact, or an Or of them. Assignment requires it. |
| ● | FieldOf | A typed, const read of a declared field, so FieldValue<T>(FieldOf<T>(field)) keeps the field token. |
| ● | Lifecycle | A state machine on a facet, moved by actions and guarded in the database. |
| ◇ | Correction and amendment | A documented pattern: correct a recorded fact through an action that keeps the original. |
| ◐ | Bulk action | An action over a selection of records. Not yet: declared atomicity. |
| ◐ | Effect | Ordered follow-up work through one channel. Actions and workflows run. Not yet: task, notification, and integration targets. |
| ● | Subscription | React to another facet's state change. |
| ◐ | Domain event publication | Committed facts published to consumers. Not yet: publication outside the application. |
| ◇ | Edit session | An exclusive, expiring lease on a record for long edits. |
| ◐ | Approval-gated change | A revision declared under approval, with History.revisions(approval:), follows its effective approval policy: zero approvals let an authorized actor submit, publish, or retire by hand, recorded as no approval required; one or more leave it to the approval workflow; a missing or ambiguous policy is refused. Not yet: approval of changes other than revisions. |
| ◐ | Background job | Durable long-running work with claim, progress, completion, and failure. Not yet: a declared job kind. |
| ◇ | Reference guard | Block deactivation or deletion while active references exist. |
| ◇ | Cross-record test | A test over a related record, or over all, any, or none of its children. |
| ◇ | Actor-context stamp | The server stamps the actor's department, site, or role at the time of the action. |
| ◇ | Conditional effect | An effect that runs only when a test holds. |
| ◇ | Trigger | What starts an action: a request, a schedule, a record change, an inbound event, or a workflow step, recorded on every ledger record. |
| ◐ | Expression language | One typed language, the package vyuh_expression, for tests, filters, and derived values: three-valued (true, false, unknown), exact numbers and dates, a versioned JSON envelope, and facts pinned by the host. Rule tests, actor expressions, invariants, list filters, and DB row rules use it. Not yet: derived values and aggregates in every Blueprint surface. |
C. Accountability: who, under what authority, with what proof
| Primitive | What it means | |
|---|---|---|
| ◐ | Identity provider port | Login, session, recovery, site selection, and revocation through an adapter. Not yet: a ready-made adapter. |
| ◐ | Tenancy and scope | Tenant, site, and area hierarchy with row-level security. Not yet: every scope shape without hand-written policies. |
| ● | IAM | Principals, roles, groups, grants, and dated membership. |
| ◐ | Policy | Configurable values on a scope ladder with traced resolution. Not yet: locks and delegation. |
| ◐ | Entitlement | Which tenants and sites may use which application or feature. Not yet: inside Blueprint. |
| ◐ | Qualification | "Competent", kept separate from "allowed". Not yet: a resolver beyond the contract. |
| ● | Separation of duties | The person who starts, claims, and approves work are kept independent. |
| ● | Electronic signature | Re-authenticated intent bound to the action, a meaning, and a reason. |
| ● | Audit trail | The action ledger, facet audit tables, and history. |
| ◐ | Evidence | Proof an action requires, such as files, readings, or checklists. Not yet: verification beyond presence. |
| ○ | Retention and legal hold | Retention classes, holds, archival, and disposal as recorded actions. |
| ● | Replay | Reconstruct what happened, in order, for a scope. |
| ◐ | Service principal | A non-human caller, such as a service or an instrument, recorded as acting for a party. Not yet: the principal mapping. |
| ◇ | Record comparison | A typed difference between two revisions, kept as reviewable evidence. |
| ◇ | Standard reasons | Governed reason lists for change, rejection, correction, and signature meaning. |
| ◇ | Policy value operand | A policy value, such as a hold time, used directly in tests, deadlines, and assignments. |
| ◇ | Qualification provenance | Completing a record, such as training, produces the qualification facts rules check. |
Two questions remain open and are not planned for now: recording reads, views, and prints as ledger facts, and masking individual fields by grant.
D. Work: obligations people and systems discharge
| Primitive | What it means | |
|---|---|---|
| ◐ | Task | Assignable work: claim, release, separation of duties, completed through an action. Not yet: transfer, delegate, escalate, and quorum. |
| ◐ | Submission | Immutable content presented against an exact revision. Not yet: adoption beyond tasks. |
| ◐ | Decision | An attributed judgment with a declared outcome and reason. Not yet: decisions with tests. |
| ◐ | Approval | Multi-level, multi-approver gates on an action or revision, counted by stored policy. The submitter never approves. Not yet: resolution without a host resolver. |
| ◐ | Workflow contract | Workflow definitions referenced by version; steps run actions and tasks complete through actions. Not yet: run events as triggers. |
| ◇ | Authored definition | A versioned document with a validator and compiler: draft, publish, activate. |
| ◇ | Spawn and gate | Create child records from one action, and gate the parent on its children. |
| ◐ | Checklist | Ordered instructions with capture, timing, and repetition. Not yet: shared with task, submission, and evidence. |
| ◇ | Obligation and schedule | Due dates, recurrence, escalation, and missed occurrences as facts. |
| ◇ | Commitment | A target date or quantity whose changes are governed. |
| ◇ | Calendar | Working time, holidays, and site time zones. |
| ◇ | Notification | Audiences, channels, templates, delivery receipts, and acknowledgement. |
| ◇ | Comment and annotation | Threaded, attributable remarks on records and fields. |
| ◇ | Organisational assignment | Assign work to, for example, the head of the initiator's department. |
| ◇ | Response draft | A saved, resumable working answer to a task before it is submitted. |
E. Read: knowing what is true
| Primitive | What it means | |
|---|---|---|
| ◐ | Named query and projection | Server-authoritative, tenant-scoped filters over projections. Not yet: joins across projections. |
| ○ | Aggregation | Group and measure: count, sum, average, min, max, distinct. |
| ◇ | Search | Full-text and faceted search that respects scope. |
| ◇ | Register | A declared table of a population with columns, filters, and grouping. |
| ○ | Report and controlled output | A parameterised document with an audit stamp, issued as a record. |
| ○ | Dashboard | A saved layout of widgets bound to queries. |
| ◇ | Traceability graph | Navigate a record's relationships, effects, and links over time. |
| ◇ | Metric and trend | Aggregation by time period, with comparison between periods. |
F. Surface: how people and systems reach it
| Primitive | What it means | |
|---|---|---|
| ● | Protocol API | Manifest, capabilities, query, action plan, preflight, execute, history, and replay. |
| ◇ | Declared endpoint | A custom route with typed input and output, mounted with Blueprint authorization and records. |
| ◇ | API description and typed client | An OpenAPI description and a typed Dart client generated from the manifest. |
| ● | Generic UI | Collections, detail, editor, actions, history, and inbox. |
| ◐ | Typed UI slot | Renderers, editors, and routes with a typed data contract. Not yet: the data contract. |
| ◇ | Visualization kit | Diagram, timeline, kanban, calendar, chart, and tree bound to queries. |
| ● | Shell | Branding, navigation, workspace, sign-in screens, and site switcher. |
| ● | Localization | Keys, locales, and formatting. |
| ◐ | Live updates | A scoped change feed to clients. Not yet: beyond client invalidation. |
G. Operate: installing, evolving, and proving the application
| Primitive | What it means | |
|---|---|---|
| ● | Schema emission | Tables, facets, history, roles, grants, and row-level security from declarations. |
| ◐ | Database extension slot | Hand-written SQL with declared ownership and dependencies. Not yet: declared. |
| ● | Migration | Typed, planned, rehearsed upgrades. |
| ◐ | Reference data and tenant provisioning | Structured seed packs and per-tenant provisioning files. Not yet: reference rows declared in the model. |
| ◐ | Readiness | Proof at configuration time that every predicate, slot, and binding has a witness. Not yet: every slot. |
| ◐ | Conformance observations | Executable witnesses for capability claims. Not yet: a validation package. |
| ◐ | Governed configuration | Changes to policies and definitions go through approval and audit. Not yet: beyond some master data. |
| ◇ | Data import | Validated bulk load with per-row results, as a recorded action. |
H. Integrate: other systems
| Primitive | What it means | |
|---|---|---|
| ◐ | Outbound integration effect | An idempotent call to another system with receipt, retry, and dead letter. Not yet: a declared integration effect. |
| ◇ | Inbound event | An authenticated, deduplicated external event that runs an action. |
I. Adaptive evolution: learning from the record
This family changes what the application does from its own evidence. It adds no new way to change data: anything it changes goes through an ordinary action.
| Primitive | What it means | |
|---|---|---|
| ◇ | Trend trigger | A trigger over an aggregate across a time window, such as deviations on one piece of equipment in 90 days. |
| ◇ | Observer module | A module that reads the ledger and may only propose actions. |
| ◇ | Process mining | Compare the paths the ledger records with the designed workflows. |
What stays in your domain
These are never Blueprint primitives. You express them with the primitives above.
| Domain logic in batch production | Expressed with |
|---|---|
| Batch, product, equipment, and material lot | Entity, facet, relationship |
| Batch states from planned to released | Lifecycle, action |
| Cleaning details on shared equipment | Descriptor |
| QA batch release with an e-signature | Task, decision, electronic signature |
| The master batch record | Versions, revisions, and approval |
| Deviations raised during a batch | Action, relationship, separation of duties |
If something cannot be expressed this way, it is a gap in the catalog, not a reason to build a framework inside your application.
See core concepts for how these pieces fit together.