Equipment and Activity Model

This is the concrete shape behind the abstract runtime model: a complex master plus a performed operational transaction.

Concrete blueprint

Equipment master. Activity transaction. One runtime brain.

The model has seven vocabulary layers today. The first five are declaration, the sixth is configuration, and the seventh is the execution surface that turns requests into effects.

01Declaration

Field types

Closed interpretation core for codecs, DDL, validation, and row decoding.

TextType / DecimalType / EnumType / JsonbType

02Declaration

Field tokens

Typed, named atoms that carry meaning, storage hints, UI hints, and seed intent.

CodeField / StatusField / IdentifierField / FileField

03Declaration

Structure

The assembled business shape: modules, entities, facets, relationships, lifecycle, projection.

Blueprint / Module / Entity / Facet

04Declaration

Logic brain

Composable truth and authority primitives evaluated by the common runtime.

FieldPredicate / ActorSet / Rule / Invariant

05Declaration

Work and proof

What can be attempted, what must be captured, and which declared effects may leave the action.

Action / TaskTemplate / Evidence / AuditEnvelope

06Configuration

Configuration

Scoped values and witnesses that specialize the declaration without inventing new behavior.

Policy / Grants / Qualifications / Bindings

07Execution + Intelligence

Runtime effects

Requests resolve the model, run checks, stage writes, record proof, and emit observable effects.

ActionRequest / ExecutionPlan / Records / Realtime

Master entity

Equipment

Entity

mfg.equipmentVersioned master with one identity anchor.

Identity fields

code, name, descriptionStable lookup and display vocabulary.

Operational facets

tenancy, governance, physical_profileEach facet owns its fields, lifecycle, projection, and actions.

Relationships

area, line, room, categoryThe equipment sits inside the manufacturing graph.

Lifecycle

draft -> active -> retiredState changes are actions, not ad hoc updates.

Derived view

area_name, status, document countRelated fields and projections make the master queryable.

fieldsrelationshipsactionslogiceffects

Transactional entity

Activity

Entity

ops.equipment_activityQueryable transaction when performed work needs its own lifecycle.

Target

equipment_id, activity_typeThe activity points back to the master and the declared work kind.

Payload

checklist, readings, result, commentsAction payload is typed by field tokens.

Lifecycle

planned -> in_progress -> completed -> reviewedReview, reject, void, and rework are declared transitions.

Proof

evidence, signature, reason, audit linkRegulated capture is declared before execution.

Outputs

records, equipment projection, outbox, realtimeEverything leaves as planned runtime effects.

Logic composition

These primitives form the declarative brain. Execution interprets them right before, during, and after the action.

FieldPredicateData truth

Payload complete, reading in range, result present, status not void.

ActorSetWho may act

Operator, QA, qualified technician, initiator exclusion, locked SoD.

RuleAction gate

Availability, before commit, after commit, async, blocking or warning.

InvariantAlways true

Pre or post, engine or DB tier, blocking failure or problem fact.

EffectDeclared output

Database write, audit write, action record, outbox, realtime, dry run.

Activity action read

The activity does not get a private server. Each action is a declared request shape plus checks and effects.

ActionChecksEffects

createactor set + required payloadactivity row, action record

startstate predicate + qualificationactivity state, equipment busy projection

completereadings + checklist + evidencecompletion proof, audit, outbox

reviewQA actor set + SoD + post invariantreview record, equipment released or rejected

Declaration

Equipment and Activity declare fields, facets, relationships, lifecycle, actions, predicates, actor sets, invariants, evidence, audit, and allowed effects.

Configuration

Sites bind grants, qualifications, policies, thresholds, templates, document sources, numbering masks, and external systems to the declared vocabulary.

Execution + Intelligence

A request resolves effective configuration, checks the logic brain, stages writes, verifies postconditions and invariants, commits, then emits effects and traces.

validatereadinesspreflighttransactionobserve

Modeling Stance

Equipment is the master. It is versioned, governed, searchable, and reused by many operational processes.

Activity is the performed work against that master. Cleaning, calibration, maintenance, inspection, dispensing setup, and IPQC checks can all be activity types. Activity is not a custom mini-server. It is an entity plus declared actions, interpreted by the same runtime.

The universal runtime still writes ActionRecords for every action. An equipment_activity entity is added only when the business needs the activity itself to be queryable, assignable, reviewable, reported, or linked to evidence.

Today the model should be read as seven vocabulary layers across three planes:

1. Field types
2. Field tokens
3. Structure
4. Logic brain
5. Work and proof
6. Configuration
7. Runtime effects

The first five layers describe what can exist and what can be attempted. Configuration supplies scoped witnesses and values. Execution turns requests into records and effects.

The developer build workflow for this example is captured in the Developer Guide. This page stays focused on the model shape; the guide covers responsibility boundaries, readiness, simulation, execution tests, and what the runtime owns.

Equipment Master Blueprint

Vocabulary	Equipment use
Entity	equipment, schema mfg, versioned
IdentityFacet	code, name, description
Facet	tenancy, governance, physical_profile
Field	tenant/site, status, category, material, surface area, documents
Relationship	belongs to area, category, line, or room
RelatedField	projected area_name or room/class labels
Lifecycle	draft -> active -> retired
Action	activate, retire, update_profile, link_document
Rule	grant required, policy allows, required documents present
Invariant	active equipment must have tenant, area, status, and valid profile
AuditEnvelope	signature/reason on activate and retire

Equipment answers: what is this asset, where is it, what state is it in, what can be performed on it, and what must always be true about it?

Activity Transaction Blueprint

Vocabulary	Activity use
Entity	equipment_activity, schema ops or elog
IdentityFacet	activity_no, equipment_id, activity_type
Relationship	belongs to equipment, may link SOP/document/template
Lifecycle	planned -> in_progress -> completed -> reviewed, with reject/void branches
Action	create, start, complete, review, reject, void
Payload	checklist ref, readings, result, comments, reason
Evidence	checklist, signature, photo, controlled document, instrument capture
ActorSet	operator, QA, qualified technician, reviewer, initiator exclusion
FieldPredicate	required payload, measured value bounds, result present
Rule	actor allowed, state legal, policy allows, evidence present
Invariant	completed activity has performer, time, result, evidence, and immutable proof
Effect	update activity state, update equipment projection, write audit, enqueue outbox

Activity answers: who did what, against which equipment, under which declared rule, with which evidence, and what effects were produced?

Complete Vocabulary Stack

Layer	Equipment/activity read
1. Field types	TextType, DecimalType, EnumType, UuidType, JsonbType, and other sealed primitives.
2. Field tokens	CodeField, StatusField, ReferenceIdField, IdentifierField, QuantityField, FileField, and row access.
3. Structure	Blueprint, Module, Entity, Facet, Relationship, Lifecycle, Projection, and descriptors.
4. Logic brain	FieldPredicate, ActorSet, Condition, Rule, Invariant, and evaluator refs.
5. Work and proof	Action, TaskTemplate, Evidence, AuditEnvelope, declared Effect, and subscriptions.
6. Configuration	Policy, EffectivePolicy, grants, qualifications, source bindings, templates, thresholds, locks, and external bindings.
7. Runtime effects	QueryRequest, ActionRequest, preflight, execution plan, records, database/audit/outbox/realtime/dry-run effects, and traces.

The separation matters: fields do not contain domain behavior, and activities do not get their own server runtime. The declaration plane describes the brain. Configuration supplies witnesses and scoped values. Execution interprets the same model for humans, APIs, workflows, schedules, simulations, and agents.

Three-Plane Read

Declaration: Equipment and Activity declare their fields, facets, relationships, lifecycle, actions, actor sets, predicates, invariants, evidence, audit, and possible effects.

Configuration: Site policy says who may perform or review activities, what templates apply, what evidence sources are bound, which thresholds are active, and which grants/qualifications satisfy the declared actor sets.

Execution + intelligence: A request enters. The runtime resolves effective policy and actor eligibility, checks preconditions and pre-action invariants, stages writes, evaluates postconditions and post-action invariants, commits, then emits effects through records, outbox, realtime, projections, dashboards, and advisory traces.

Verification Path

1. BlueprintValidator checks declaration closure.
2. SystemReadinessReport checks configuration and state witnesses.
3. Preflight explains whether this actor/payload/state can proceed now.
4. Execute repeats the checks inside the transaction.
5. Post-action invariants check the candidate state before commit.
6. Outbox, realtime, analytics, and deferred watcher invariants run after commit.

Simulation uses the same path with effects marked wouldApply. That is how Blue can detect configuration inconsistencies, preview operational impact, and show a DevTools-style trace without inventing another execution model.