DECK / 01 OF 17

Model the business.
Connect the work.

Blueprint describes the things your business knows, the rules they follow, and the changes people can make.

Shared masters → business operations → committed transactions → connected systems.

Conceptual application composition. Each product still supplies its declarations, bindings, and integrations.

02 / CONNECTED MASTERS

Start with the things
the business shares.

People, equipment, places, and procedures keep their own identities. Operations link to them.

Know the things

Equipment belongs to an area. A person holds a qualification.

Keep the rules

Only a qualified person can complete an operation on available equipment.

Keep the context

The operation records the exact procedure revision it followed.

03 / CORE OBJECT MODEL

A few building blocks.

Primitive	Meaning	Example
Entity	A thing with its own identity.	Person · Document · Operation
Facet	One aspect of that same thing.	Contact details on a Person
Field	A value or reference.	Name · quantity · document ID
Relationship	A meaningful link between things.	Operation governed by Procedure
Association entity	A link with its own history and rules.	Qualification · Assignment
Action	A change with rules and permissions.	Approve · Assign · Complete
Lifecycle	A facet’s states and allowed transitions, triggered by actions.	Draft → Approved → Retired

Modules define entities. Descriptors extend them with facets, behavior, queries, and UI.

Explore entities and facets

04 / THE MODEL SKELETON

How the building blocks connect.

An entity holds the identity. Facets organize its data and behavior. Links connect it to the rest of the business.

One identity, several facets

Physical profile and service status describe the same equipment. Each facet owns its fields.

Change follows rules

Actions make permitted changes. Lifecycle actions move a facet between allowed states.

Give rich links an identity

Equipment links directly to an area. An assignment is its own entity because the link has a role and validity dates.

05 / BUSINESS OPERATIONS

Describe what happens
in the business.

An equipment inspection connects a person, equipment, and a procedure. Actions move it from start to completion.

The requirement

The procedure defines the checks and acceptable results.

The operation

An actual inspection records who did it, which equipment was used, and what was observed.

The transaction

Completing the inspection checks the rules and commits its result and evidence.

One operation can span several actions and transactions.

Apps provide the screens and journeys. Blueprint carries the shared business meaning and rules behind them.

06 / THREE PLANES

Define. Configure. Execute.

Declaration

Entities, relationships, actions, and rules.

What does the system mean?

Configuration

Settings, permissions, and providers for this installation.

What applies here and now?

Execution

Actions, outcomes, and their evidence.

What happened, and why?

One contract, carried through three planes.

Explore the three planes

07 / HOW IT BUILDS

Define once.
Extend together.

Descriptors let features extend entities owned by other modules.

OWNING MODULE

Equipment

One shared identity

Calibration

Details + actions

Maintenance

Settings + actions

ASSEMBLED EQUIPMENT

Descriptors add capabilities to the same entity.

Extend with modules

01 · Author & assembleBase entities + feature contributions
02 · Validate & linkCheck references, conflicts, and origins
03 · Compile & inspectGenerate storage, APIs, and UI metadata
04 · Install & operateConnect providers and run the application

08 / A COMPILER PROBLEM

Change the Blueprint.
Reuse the machinery.

The Blueprint is the program. The compiler turns it into the artifacts used by the shared server, database, and UI.

Describe the difference

Your masters, relationships, constraints, and permitted actions belong in the Blueprint.

Compile one contract

Derive storage and metadata from that model. Server and client share a consistent way to query and act.

Reuse the process

The runtime checks, commits, records evidence, and delivers effects using the same execution process.

Model the business. Compile the artifacts. Run the shared system.

Add custom behavior and integrations where your business needs them.

09 / TRANSACTIONS

A business action becomes
a reliable change.

“Complete inspection” is more than updating a status field.

Check

Is this person allowed? Are the required results present? Is completion valid now?

Commit

Save the business change, its evidence, and pending delivery in one transaction.

Deliver

Contact external systems after commit. Track delivery attempts and retry failures.

Follow a business action →

10 / THE ECOSYSTEM

A change should travel
beyond the app.

An inspection completes. Connected views refresh, people are notified, and other systems can respond.

Outbox

Durably records work to deliver after commit. A failed delivery does not erase the completed operation.

Subscriptions

Applications observe query results. Relevant changes refresh the data they display.

Realtime

Configured transports notify connected clients sooner. Clients still read through authorized queries.

Choose the adapters and integrations for your deployment. Consumers must handle repeat delivery safely; a notification is not the authoritative record.

Queries and subscriptions →

11 / EVOLUTION

Change the model.
Understand the consequences.

Classify impact

Identify what stays compatible and what needs migration.

Plan the migration

Declare the steps, checks, and recovery path.

Require evidence

Verify the change in the environment where it will run.

Migrations and seed files

12 / COMPOSING BLUEPRINTS

A shared foundation.
Many business blueprints.

Start with Blueprint. Reuse capabilities such as IAM and workflows. Compose industry blueprints from modules that describe their business.

Build upward. Reuse across. Extend what already exists.

Each industry blueprint combines its own modules with shared capabilities. Descriptors can contribute facets and behavior to existing entities.

Industry modules shown here are examples of composition, not a catalog of shipped products.

13 / INTELLECTUAL INFLUENCES

Borrow useful ideas.
Keep a clear authority.

Operational ontology

Palantir: connect business objects, relationships, and actions.

Palantir action types

Provenance

PROV-O: trace what happened, who acted, and where facts came from.

W3C PROV-O

Shared meaning

RDF connects facts. OWL gives concepts and relationships explicit meaning.

W3C RDF
W3C OWL

Conceptual influences, not claims of formal conformance.

Why Blueprint

14 / TECH STACK

Built on Dart and Flutter.

One typed language across the system. Rich, responsive applications across platforms.

Dart

Shared types, from server to screen.

Sound typing and null safety keep models and contracts consistent across servers, clients, CLIs, and background workers.

Compile services and tools to native executables. Deploy servers and workers in Docker containers.

Why Dart →

Flutter

Expressive UI, built with the same types.

Rich widgets, fluid animations, and a shared codebase for mobile, desktop, and web—all using Dart’s type safety.

Native machine code on mobile and desktop. WebAssembly or JavaScript on the web, for high-performance interactive experiences.

Why Flutter →

Share the model. Keep the types. Reach more platforms.

Edge-worker deployments depend on the host runtime and supported libraries.

15 / PACKAGES

One model. A shared toolkit.

Define

vyuh_blueprint

Model entities and compose contributions.

Run & connect

vyuh_blueprint_server
vyuh_blueprint_protocol
vyuh_blueprint_client

Execute actions and connect clients.

Present

vyuh_blueprint_ui

Turn the model into shared application UI.

Explore the package map →

16 / DEVELOPER WORKFLOW

Check. Start. Iterate.

Request a pub.vyuh.tech token from Vyuh Technologies, then install the CLI.

Check your setup

blueprint init
blueprint doctor

Run in two terminals

blueprint dev — servers
blueprint app — interactive app

Keep moving

blueprint restart
blueprint logs --follow

Local development →

17 / BUILD WITH PROOF

Start with one real operation.

Connect its masters. Define its rules. Commit a result. Let another application react.

Model → act → commit → connect.

Pre-production. Readiness requires proof in the target environment.

Build your first slice

Model the business.Connect the work.

Start with the thingsthe business shares.