Blueprint runtime boundary

Blueprint is split by runtime ownership, not by generated application target.

Declaration and assembly

vyuh_blueprint owns the pure Dart language for modules, entities, facets, fields, relationships, lifecycles, actions, rules, policies, evidence, audit, projections, tasks, descriptors, DB hints, UI hints, and seed metadata.

Blueprint.bootstrap() assembles descriptor contributions into the effective entity graph and preserves origin information. Every downstream layer consumes that same effective graph.

Database generation

vyuh_blueprint_server generates the Postgres-compatible persistence layer:

• domain schemas, enums, identity and facet tables;
• version and audit tables;
• indexes, joined read views, and outbox infrastructure;
• runtime schemas for manifests, projections, action/query records, plans, failures, results, and effects;
• a physical database plan and diagnostics.

This is the only code-generation boundary. Security policies, grants, migration planning, and production data transforms belong here as the database generator grows.

Fixed server runtime

vyuh_blueprint_protocol owns transport DTOs and uses vyuh_query for collection requests and results. vyuh_blueprint_server owns capabilities, planning, preflight, execution, records, failures, results, explanations, and the bindings to vyuh_server, database, policy, telemetry, outbox, and authentication adapters. Protocol, entity facade, and explorer routes are fixed route modules that derive behavior from the assembled Blueprint. They are not generated per application. The generic server OpenAPI plugin documents the mounted routes.

Assembled application UI

vyuh_blueprint derives product routes, collections, action surfaces, navigation, workspace, and shell surfaces from the effective entity graph plus application descriptors.

vyuh_blueprint_ui maps those descriptors into vyuh_studio_ui. Standard surfaces are interpreted at runtime. Products contribute typed client bindings for custom detail tabs, dashboard widgets, action forms, routes, and field editors. No legacy vyuh_entity_system or vyuh_entity_system_ui generation path remains.

Seeds

Seed and scenario metadata may remain on declarations, but executable seed data is owned by the consuming application. It should be deterministic, reviewed, and installed with that application's database workflow rather than emitted by a generic AI seed compiler.

Execution flow

Blueprint definition
  -> validation and bootstrap
  -> database generation/install
  -> fixed server route registration
  -> BlueprintApp assembly
  -> Blueprint UI / Studio UI interpretation
  -> authenticated user invokes an action
  -> server plans, validates, and commits the action
  -> audit, evidence, runtime ledger, and outbox records persist
  -> client refreshes declared projections