Blueprint

Blueprint is the declarative model for building regulated software from connected entities. It is intentionally portable: pure Dart, JSON-safe, and free of Flutter, server, Supabase, and runtime dependencies.

The goal is to let a domain package describe what the application is before any specific surface is generated or mounted:

• the business entities and relationships
• the actional facets that own state and lifecycle
• the actions users and systems can perform
• the composable rules and conditions that govern those actions
• the evidence and audit posture required for regulated execution
• the DB, API, UI, seed, and app intent required by compilers
• the module lineage for every contributed item

The same model should be useful for CVS, ELog, WMS, IPQC, BRM, LIMS-like surfaces, batch manufacturing, transport, inventory, and other manufacturing solutions.

Philosophy

Blueprint is not a UI model, a database schema, or a server runtime. It is the shared language underneath all of them.

1. Business language first. Use entities, facets, actions, policies, evidence, and audit. Avoid implementation suffixes in the domain vocabulary.
2. Modules compose the application. A module defines entities or contributes descriptors to entities exported by another module.
3. Entities are stable business types. manufacturing.product is the same product whether CVS, ELog, or IPQC contributes more facets to it.
4. Facets own actional dimensions. Tenancy, identity, governance, physical profile, cleaning profile, execution history, calibration posture, and assignment are facets.
5. Actions are always facet-scoped. Actions that feel entity-wide belong to the IdentityFacet. Entity headers, routes, and command palettes may expose those actions, but ownership stays with the facet.
6. Actions change state. Regulated software should not rely on direct writes when a lifecycle, policy, workflow, evidence, or audit rule applies.
7. Every action request has context. Runtime execution captures who, when, why, what, and where through RequestContext and persists the outcome in action records.
8. Projection is state shape. Facet projection explains how facet state is read from and written to storage/API/client state. Derived values are computed values, not projections.
9. Server enforcement is authoritative. UI hints control affordances, but server policy checks, lifecycle checks, evidence checks, and audit writes are the enforcement boundary.
10. Runtime surfaces share one graph. Database generation, fixed server routes, App Blueprint assembly, and Blueprint UI consume the same effective blueprint.
11. Lineage is first-class. Every effective node can be traced to the module and descriptor that contributed it.

End-to-End Flow

blueprint.bootstrap() is the implicit assembly boundary. Callers define modules with entity descriptor contributions; bootstrap assembles the entity graph that database generation, validators, explorers, app assembly, and runtime adapters consume.

Object Model At A Glance

Model	Meaning	Primary owner
Blueprint	Complete application definition.	Application package
Module	Package-level boundary that defines or contributes domain content.	Domain package
ModuleExport	Explicit export of entities, derived values, or triggers.	Module
EntityDescriptor	Contribution to an entity type, identified by target and aspect.	Same module or dependency module
Entity	Assembled business object and facet composition boundary.	Bootstrapper
Facet	Active dimension of an entity.	Entity or descriptor
Field	Typed state member.	Facet
Relationship	Entity-to-entity connection.	Facet
Lifecycle	Facet-owned state machine.	Facet
Transition	Allowed lifecycle move.	Lifecycle
Action	Facet-scoped transactional action surface.	Facet
RequestContext	Actor, scope, time, reason, source, and correlation envelope.	Runtime protocol
ActionRecord	Durable runtime truth for a request.	Runtime protocol
ActionResult	Factual output produced by an action record.	Runtime protocol
ActionFailure	Typed failure produced during planning, preflight, or execution.	Runtime protocol
RuleDefinition	Composable action rule for access, policy, lifecycle, data, evidence, audit, snapshot, effect, or custom decisions.	Action
Condition	Declarative rule logic vocabulary.	Rule
Evidence	Required or captured proof.	Facet/action/runtime
AuditEnvelope	Regulated audit posture.	Facet/action/runtime
DerivedValue	Computed value from DB or server.	Facet/entity/module
FacetProjection	Facet-owned projection.	Facet
EntityProjection	Union of all facet projections.	Effective entity
EntityUIOverride	Descriptor-level UI posture for icon, category, route/list visibility, route prefix, and table columns.	Entity descriptor
Effect	Downstream action emitted by transitions or actions.	Facet/action
Trigger	Runtime trigger descriptor.	Module
Subscription	Cross-facet or cross-entity reaction declaration.	Facet/module
ModuleDb / EntityDb / FieldDb	DB and performance hints.	Module/entity/field
ModuleUI / EntityUI / FacetUI / FieldUI / ActionUI	Flutter-free UI hints.	Module/entity/facet/field/action
ModuleSeed / EntitySeed / FieldSeed	Seed generation hints.	Module/entity/field
DartRef	Static code reference without runtime dependency.	Any model that delegates logic
EntityOriginGraph	Lineage for every effective node.	Bootstrapper

Application and Module Composition

A Blueprint is made from modules. A module can define entities, declare policies, expose DB/UI/seed hints, export reusable items, and contribute descriptors to entities defined elsewhere.

final blueprint = Blueprint(
  name: 'manufacturing_super_app',
  version: '1.0.0',
  modules: [
    manufacturingModule,
    iamModule,
    cvsModule,
    elogModule,
  ],
);

final effective = blueprint.bootstrap();
final product = effective.entity('manufacturing.product');

The base manufacturing module defines shared entities such as product, equipment, area, material, method, and equipment train. CVS and ELog should not create competing product types. They contribute descriptors to manufacturing.product.

Entity

An entity is a stable business object and composition boundary. It carries a schema type, title, description, facets, aggregate projections, DB hints, UI hints, and seed hints. It does not own actions directly.

Examples:

• manufacturing.product
• manufacturing.equipment
• manufacturing.area
• iam.user
• iam.user_group
• iam.role
• cvs.protocol
• elog.logbook

The entity is the unit users think about, APIs route around, tables list, and permissions often target. The descriptor is the unit modules contribute. The facet is the unit that owns state dimensions and behavior. Every assembled entity must have exactly one IdentityFacet. If an action feels entity-wide, model it on the IdentityFacet.

Entity Descriptor

An EntityDescriptor contributes facets to an entity address. It is the mechanism that lets modules layer into the same stable type. target says which entity receives the contribution; aspect says which named module/domain aspect made the contribution.

manufacturing.product
  identity
  tenancy
  governance
  composition

cvs descriptor -> manufacturing.product
  cleaning profile
  MACO participation
  protocol impact

elog descriptor -> manufacturing.product
  execution history
  logbook applicability

After bootstrap, the effective entity is one product:

manufacturing.product
  identity
  tenancy
  governance
  composition
  cleaning profile
  MACO participation
  protocol impact
  execution history
  logbook applicability

Identity is also facet-owned. The assembler/validator requires exactly one IdentityFacet across the base module and all descriptor contributions. A generic Facet(name: 'identity') is invalid because identity is a typed facet, not just a reserved string.

Descriptors may contribute new facets or merge into an existing facet. Shared facets such as governance and tenancy are expected to accept contributions from many modules.

Descriptors may also describe entity-level UI posture through EntityUIOverride. This is how a module gives an entity an icon, category, menu/list visibility, route prefix, table columns, and default sort without creating an app descriptor. UI descriptors are assembled into Entity.ui; they are not storage facets and do not imply lifecycle, audit, or action ownership. Unique UI posture must be singular and conflict-free. Table columns are the one additive part, because multiple descriptors can safely add visible columns.

Facet

A facet is an actional dimension of an entity. It is the main extensibility unit in the blueprint.

A facet can contain:

• title and description
• fields
• relationships
• lifecycle
• actions
• rules and conditions
• evidence declarations
• audit envelope
• derived values
• subscriptions and effects
• facet projection
• UI hints

This lets the blueprint say that an equipment entity has several independent regulated dimensions:

equipment
  identity
  tenancy
  governance
  physical profile
  cleaning status
  calibration posture
  maintenance posture
  execution usage

Not every facet needs a lifecycle. Some facets are mostly state and relationships. Others are actional and define transitions, actions, evidence, rules, and conditions.

Facet or association entity?

Use a facet when the state is one dimension of the same entity instance. A user profile, tenancy defaults, authentication metadata, governance status, or geo snapshot can be facets because each facet row is at most one-to-one with the user.

Do not model a repeatable relationship as a facet just because it is "about" the entity. If the relationship can have multiple rows per entity, its own validity window, approval state, revocation, scoped grants, evidence, audit, or lifecycle, make it a separate association entity. Examples include iam.membership, iam.role_assignment, and a possible iam.user_site_membership.

The decision rule is:

Question	Prefer a facet when...	Prefer a separate entity when...
Cardinality	There is at most one row of this state per owning entity.	There can be many rows per owning entity, or the same other entity can be linked many times under different scopes.
Identity	The state has no useful identity apart from the owner.	The link or child needs its own id, natural key, record page, API route, or references from other records.
Lifecycle	The state changes with the owner or one facet lifecycle.	The link can be drafted, activated, suspended, revoked, expired, reapproved, or corrected independently.
Audit and evidence	Changes can be audited as changes to the owner facet.	The link itself needs approval evidence, reason codes, signatures, or a review trail.
Permissions	Access follows the owner.	Access depends on the link's scope, role, site, department, or assignment state.
Query shape	Users mostly read it as part of the owner detail.	Users list, filter, approve, revoke, or report on the relationship records themselves.

iam.user
  identity
  tenancy          # primary/default org context, home site hints
  profile
  authentication
  governance

iam.user_site_membership
  identity         # user_id + site_id + membership_type
  scope            # department, valid_from, valid_until
  governance       # draft -> active -> suspended -> revoked

The iam.user.tenancy facet can say "this user has these defaults or home sites." The iam.user_site_membership entity says "this specific user-site assignment exists, is active, was approved, expires later, and can be revoked without changing the rest of the user." That difference is the boundary.

Cardinality is necessary but not the only reason. A single optional relationship can still become a separate entity if it has independent lifecycle or regulated evidence. Conversely, a small list such as home_site_ids can stay on a facet when it is only a hint or default, not the system-of-record for access.

For a single assignment table that maps users to products at sites, model the assignment itself as the entity. Declare the physical FK fields first, then bind each relationship to the field that stores it:

const userId = ReferenceIdField('user_id');
const siteId = ReferenceIdField('site_id');
const productId = ReferenceIdField('product_id');

final userSiteProductAssignment = Entity(
  name: 'user_site_product_assignment',
  tableName: 'user_site_product_assignments',
  schema: 'iam',
  uniqueKeys: const [
    [TenantIdField(), userId, siteId, productId],
  ],
  facets: const [
    IdentityFacet(
      fields: [
        userId,
        siteId,
        productId,
        TextField('assignment_type'),
      ],
      relationships: [
        Relationship(
          name: 'user',
          targetEntity: 'user',
          kind: RelationshipKind.belongsTo,
          field: userId,
        ),
        Relationship(
          name: 'site',
          targetEntity: 'site',
          kind: RelationshipKind.belongsTo,
          field: siteId,
        ),
        Relationship(
          name: 'product',
          targetEntity: 'product',
          kind: RelationshipKind.belongsTo,
          field: productId,
        ),
      ],
    ),
  ],
);

This emits one identity table with user_id, site_id, product_id, a unique tuple over those fields, and foreign keys from those fields to the target tables. The relationship does not invent a second column when field is provided.

Fields and Field Types

Fields are typed members owned by facets. Titles and descriptions are core metadata, not UI-only data, because DB, API, UI, docs, localization, seed, and analytics all need human-readable semantics.

The type model is portable and maps cleanly to Postgres, API schemas, and UI widgets:

• text, integer, bigint, double, decimal
• boolean
• date, timestamp, interval
• UUID
• JSONB
• enum
• decision

Fields may carry DB hints, UI hints, and seed hints. For example, a field can declare that it is indexed, commonly filtered, visible in a table, editable only under a policy, or seeded from a regulated synthetic distribution.

Relationships

Relationships declare how entities connect:

• belongsTo
• hasOne
• hasMany
• manyToMany

They also declare cascade rules, embed hints, join semantics, and lineage. This is where manufacturing graph structure starts: products use equipment trains, equipment belongs to areas, sampling locations belong to equipment, protocols reference methods, and assignments bind actors to scoped resources.

For simple ownership or containment, a relationship usually lowers to a foreign key. The preferred explicit form is: declare a ReferenceIdField on the same facet, then bind the relationship with field: thatReferenceField. The relationship supplies graph meaning, target entity, cascade behavior, embed hint, and requiredness; the field supplies the physical column name.

If field is omitted, generators preserve the older convention and derive a foreign-key column named <relationship_name>_id. Use that only for simple cases where the conventional column name is exactly what you want.

The validator enforces that an explicit relationship field is declared on the same facet and is a ReferenceIdField. It is not valid to bind a relationship to a text, enum, JSON, or other scalar field.

For rich many-to-many membership, prefer an explicit association entity whose identity facet points at both sides. This keeps lifecycle, approval, validity, scope, and audit on the assignment record instead of hiding them in a generic join table or overloading one side's facet.

Lifecycle and Transitions

Lifecycle belongs inside a facet. A single entity can have many state dimensions, but each dimension should have one clear owner.

Examples:

equipment.cleaning_status
  dirty -> cleaned -> sampled -> released

protocol.approval
  draft -> reviewed -> approved -> effective -> superseded

material.quality_status
  quarantine -> released -> blocked

Transitions reference rules and declare effects. When a workflow is required, the transition is still the business state change; the workflow is the orchestration used to reach it.

Actions, Requests, and Records

An action is the transactional surface of a facet. It may create, update, approve, release, calculate, assign, sample, review, reject, rework, or retire state. The owning facet represents the intent:

• identity owns create, publish, archive, restore, purge, and other actions that establish or retire the entity record.
• assignment owns assign, reassign, delegate, claim, and release assignment.
• lifecycle or execution owns start, pause, resume, submit, complete, and cancel operational work.
• evidence owns capture, replace, verify, and reject proof.
• policy_snapshot owns resolve, refresh, freeze, and explain effective policy.
• exception owns raise, triage, remedy, clear, and reopen exceptions.

Actions declare:

• payload fields
• rules
• evidence requirements
• audit envelope
• effects and triggers
• UI hints

Rules are the complete declarative decision surface for an action. Use RuleKind to name the concern and RulePhase to name when it runs:

• RuleKind.access with ActorHasGrantCondition for grants and permissions.
• RuleKind.policy with PolicyAllowsCondition for effective policy checks.
• RuleKind.lifecycle with StateIsCondition or an evaluator for state moves.
• RuleKind.data with field/path conditions or an evaluator for payload and entity invariants.
• RuleKind.evidence, audit, snapshot, and effect for regulated proof, capture, and downstream work.
• RulePhase.availability, beforeCommit, afterCommit, and async to place a rule in the transaction timeline.

Conditions are the vocabulary of logic. AllCondition, AnyCondition, and NotCondition compose smaller checks. Built-in conditions cover common entity work, while EvaluatorCondition gives runtimes a stable hook for logic that must be implemented in Postgres, Vyuh Policy, or application code.

At runtime, an ActionRequest carries RequestContext:

• who: actor, roles, groups, delegation, signature principal
• when: timestamp and clock source
• why: reason, justification, change control, deviation, or ticket
• what: action, payload, target entity, previous state, intended state
• where: tenant, site, area, workstation, device, session, IP, correlation ID

The blueprint declares what must be captured and which rules must pass. The runtime captures, validates, plans, executes, and persists the outcome as an ActionRecord. Records can contain ActionResult values, ActionFailure values, rule records, command records, effect records, and integrity records.

Runtime Execution on Postgres

Blueprint execution should compile to a Postgres-backed transaction contract. The runtime owns execution, but the declaration should be specific enough that Postgres can enforce and explain the important invariants.

A facet action execution should generally follow this shape:

1. Resolve the effective entity, owning facet, action, lifecycle, and projection metadata.
2. Authenticate the actor and build a RequestContext with tenant/site, device, request, correlation, reason, and signature metadata.
3. Open one Postgres transaction.
4. Lock the target host/facet rows with SELECT ... FOR UPDATE.
5. Evaluate availability and before-commit rules, including access grants, effective policy decisions, lifecycle state, typed facet state, related entities, generated views, policy reads, evidence, and action payload.
6. Capture required snapshots, including policy/config versions and relevant master/entity values.
7. Apply lifecycle and data changes to the owning facet and any declared write targets.
8. Insert immutable action records, result facts, audit, evidence, and decision-trace rows.
9. Insert outbox/effect rows for downstream facet actions, workflow tasks, realtime notifications, projections, and analytics work.
10. Commit, then let outbox runners process eventual effects idempotently.

Postgres concepts are central to that runtime:

• facet tables keep state normalized and lockable
• generated columns and check constraints encode cheap invariants
• foreign keys and explicit association entities encode entity relationships
• RLS and security-definer/invoker functions protect scoped access
• action record tables hold canonical action attempts, failures, results, and outcomes
• audit/evidence tables preserve immutable regulated history
• outbox tables bridge strict commits to eventual cross-facet effects
• views/materialized views/projected read models keep API/UI queries efficient
• advisory locks or idempotency keys protect high-contention actions

The portable blueprint types do not execute any of this. They declare the contract that lets compilers and runtime adapters produce it consistently.

Policies, Rules, and Access

Policy is a first-class configuration language owned by vyuh_policy. It is not hidden under rules.

A Policy defines:

• domains
• sections
• typed parameters
• scope ladders
• PolicyScope addresses
• scoped policy values
• domain, section, and parameter locks
• source lineage

Policy scope is broad-to-specific. The standard cascade is global, tenant, site, module, entity, facet, action, and instance, with additional domain scopes allowed by a policy's scope ladder. Nearer scope normally overwrites farther scope. A PolicyLock can protect a domain, section, or parameter so a nearer policy cannot override it.

PolicyScope scopes the entire policy contribution: values, locks, and source lineage. The effective-policy trace records each contribution as scope plus source plus values plus locks plus result.

The policy resolver does not decide whether an action is allowed. It only produces EffectivePolicy. Action/rule evaluation consumes that effective policy with the ActionRequest, actor, payload, entity state, and evidence. If custom runtime logic is needed, it belongs to a rule/condition evaluator, not to the policy object itself.

At runtime, Vyuh Policy resolves an EffectivePolicy for the current request scope and records a trace of each scoped contribution. That effective policy becomes part of the execution plan and decision trace.

Blueprints reference policies through RuleDefinition values with RuleKind.policy and PolicyAllowsCondition. The rule does not define the policy; it asks the runtime to evaluate the already-resolved effective policy. Access uses a related rule mechanism: RuleKind.access and ActorHasGrantCondition.

Policy rules are not projections. They are named decisions computed from effective policy, request context, actor, state, and declared policy reads.

Evidence and Audit

Evidence and audit are related but not identical.

Evidence is proof. It can be a checklist, signature, reason, artifact, photo, instrument file, log excerpt, training acknowledgement, external reference, or other record.

Audit is the immutable history and compliance envelope. It records the action, actor, request context, previous state, new state, evidence links, policy decisions, exceptions, signatures, failures, results, and runtime trace.

In GMP/ALCOA+ terms, the runtime must make actions:

• attributable
• legible
• contemporaneous
• original
• accurate
• complete
• consistent
• enduring
• available

Blueprint declares evidence requirements and audit posture. Runtime packages capture and enforce the actual records.

Derived Values

DerivedValue represents computed values. It supports several tiers:

• generated column
• SQL view
• materialized view
• server evaluator
• server evaluator

Derived values are useful for MACO calculations, equipment surface summaries, readiness scores, exception counts, overdue-review flags, search labels, effective status, and impact summaries.

Use a derived value when the value is computed from other facts. Use a facet projection when describing how facet state is exposed, flattened, indexed, read, and written.

Facet Projection and Entity Projection

Facets own state, so facets also own projection.

FacetProjection describes how the state inside one facet is exposed:

• which field path is projected
• whether it is read-only or read-write
• whether it is stored inline, in a facet table, in JSONB, in a view, or in a derived source
• how it should behave for filtering, sorting, search, grouping, and aggregation
• whether it is visible or editable through generated UI surfaces

EntityProjection is the union of all facet projections for an effective entity. It provides the bridge between normalized facet storage and simple client-side state.

Facet state
  identity.code
  identity.title
  tenancy.tenant_id
  tenancy.site_id
  physical_profile.surface_area_cm2
  cleaning_status.current_state

Entity projection
  code
  title
  tenant_id
  site_id
  surface_area_cm2
  current_cleaning_state

The runtime and compilers can preserve facet boundaries internally while giving client code a simple property surface:

entity.property('surface_area_cm2');
entity.property('current_cleaning_state');

The projection model also gives the DB compiler enough intent to create typed columns, indexes, JSONB columns, views, and read models without forcing the UI or API to understand every storage split.

Supabase/Postgres Mapping

The default storage strategy is relational and facet-aware:

• the IdentityFacet becomes the host table
• non-identity facets become facet tables
• facet tables use entity_id as primary key and foreign key to the host table
• fields become typed columns
• lifecycle state fields become typed columns on the owning facet table
• simple relationships become foreign keys; rich many-to-many relationships become explicit association entities such as membership or assignment tables
• audit rows are written to audit tables
• evidence rows link back to action/audit records
• derived values become generated columns, SQL views, materialized views, or server-evaluated read fields
• the full read model joins identity plus facet tables into a stable API shape

Performance intent is declared through DB hints:

• module-level schemas, RLS, realtime, outbox, triggers, cross-entity indexes, and views
• entity-level row scale, write rate, partitioning, retention, audit mode, and realtime posture
• field-level indexes, index kind, cardinality, query patterns, uniqueness, and nullable posture

This lets manufacturing apps stay normalized and indexable while still exposing a coherent entity model to APIs and clients.

UI Mapping

Blueprint UI hints are Flutter-free. They describe what should be generated, not how Flutter renders it.

UI hints can express:

• menu and route visibility
• list columns
• form sections
• field widgets
• field visibility and editability
• action placement
• action availability
• evidence prompts
• signature and reason prompts
• redaction, hide, disable, placeholder, and read-only fallbacks
• icons and categories through portable references

BlueprintAssembler derives the standard product surfaces from these hints. vyuh_blueprint_ui maps them into vyuh_studio_ui, while typed client bindings provide specialized Flutter renderers. The server remains authoritative for enforcement.

See the complete UI hint vocabulary, including the entity → module → Blueprint override cascade.

Seed Mapping

Seed hints describe the data a module needs for smoke tests, demos, validation, and load scenarios. They are separate from DB hints because seeds can be served through SQL, API fixtures, generated JSON, AI-generated packs, or scenario scripts.

Seed hints can express:

• dataset size
• realism level
• required entities and relationships
• field value strategy
• distributions and examples
• uniqueness and reference behavior
• validation scenario intent

Origin Graph

Every effective node has lineage.

The origin graph records:

• source module
• descriptor source
• aspect
• parent path
• contributed item
• merge target
• effective path

This is important for regulated manufacturing because a user should be able to ask:

• Which module added this field?
• Which descriptor contributed this policy requirement?
• Which facet owns this lifecycle transition?
• Which module changed the evidence requirement?
• Why does this entity have this DB index?
• Which package made this UI action visible?

The origin graph supports blueprint explorer views, diagnostics, impact analysis, compiler reports, and governance reviews.

Generation and Runtime Responsibilities

Blueprint is the declarative input. Only the database layer is generated.

Owner	Output
DB compiler	Postgres schemas, tables, joins, indexes, views, audit/evidence tables, outbox infrastructure, and runtime tables
Fixed server runtime	Query, action, capability, explorer, and entity-facade behavior derived from the assembled Blueprint
App Blueprint assembler	Routes, effective entity UI plans, action UI, navigation, workspace, and shell descriptors
Blueprint UI / Studio UI	Runtime interpretation of application descriptors plus typed custom client bindings
Product	Deterministic seeds and domain-specific integrations

Every owner consumes blueprint.bootstrap().assembledEntities, not raw base entities. Descriptor-contributed facets therefore participate in database, runtime, and application surfaces without parallel target compilers.

Runtime Boundary

Blueprint describes. Runtime enforces.

The runtime owns:

• authenticated actors
• IAM principals, roles, groups, permissions, grants, assignments, and scopes
• effective policy resolution and policy evaluation
• action request planning, command execution, records, results, and failures
• lifecycle enforcement
• evidence capture
• audit writes
• exception and remedy handling
• realtime events and subscriptions
• storage adapters
• telemetry and correlation

The client may render disabled or hidden actions, but every mutation must be validated on the server with the current actor, scope, entity state, lifecycle, policy, evidence, and request context.

Manufacturing Layering Example

manufacturing module
  product
    identity
    tenancy
    governance
    composition
  equipment
    identity
    tenancy
    governance
    physical profile
  area
    identity
    tenancy
    hierarchy

cvs module
  descriptor -> manufacturing.product
    cleaning profile
    MACO participation
  descriptor -> manufacturing.equipment
    cleaning status
    sampling locations
  entities
    protocol
    assessment
    result

elog module
  descriptor -> manufacturing.product
    execution history
  descriptor -> manufacturing.equipment
    usage history
  entities
    logbook
    log entry

The result is not three disconnected applications. It is one effective graph where shared manufacturing entities accumulate regulated dimensions from each solution package.

Direct Dart Authoring

Blueprint is authored directly as a Dart object graph:

final cleaningProfile = Facet(
  name: 'cleaning_profile',
  title: 'Cleaning Profile',
  fields: [
    Field(
      name: 'worst_case_rank',
      title: 'Worst Case Rank',
      type: IntegerType(),
    ),
  ],
);

The direct Dart declaration is the only authoring source. Blueprint does not require annotations, generated authoring classes, build_runner, YAML, or a parallel serialized definition. Manifests, canonical definition documents, SQL, protocol values, and UI models are derived from the Dart program.

Package Boundaries

The portable Blueprint package owns the direct Dart declarations, validation, bootstrap, canonical definition document, runtime artifact models, and platform-neutral UI intent. Database compilation and execution remain in vyuh_blueprint_server; protocol records remain in vyuh_blueprint_protocol; generic enterprise composition remains in vyuh_studio_ui; and Blueprint-to-Studio mapping remains in vyuh_blueprint_ui.