BlueDocumentation
repo.blue ↗
Core concepts

How Blue documents connect

Use Process Embedded, exact references, separate Roots, subscriptions, and typed requests to compose bounded business realities through time.

Five relationships solve different problems#

Process Embedded#

A value marked Process Embedded becomes an owned process occurrence inside its Root. Its active Timeline Channels—and those recursively discovered from embedded descendants—join the Root's feeder surface. The occurrence can therefore evolve from histories published by different accepted Timeline providers while its state remains part of this Root's committed reality.

This is more than visual nesting or code reuse. It defines ownership, deterministic processing scope, recursive discovery, and the temporal evidence the Root must include.

Referenced exact content#

A BlueId reference pins exact semantic content: a type, terms node, policy version, or known snapshot. Materialization changes representation, not meaning, when the resolved content verifies. A reference alone does not follow future process history.

Separate Root plus subscription#

A separate Root has its own participants, authority, lifecycle, provider trust, visibility, retention, and processing lineage. A subscription lets another Root observe selected events or snapshots without owning the source process.

Typed Request and Response#

One process can ask another process to act. The target remains authoritative for its own eligibility, authority, and state. This is usually safer than pretending one Root can mutate another directly.

One lineage in several portals#

Different portals may render and operate the same managed document lineage. That is a presentation and operator relationship, not a reason to create duplicate Roots.

Policy through time#

A regulator can publish an initial Policy document and subsequent changes through a public Timeline. An Agreement embeds the Policy process. Its feeder includes the regulator history through the embedded occurrence.

A 2021 Agreement first reconstructs the Policy through its 2021 verified frontier. When that Agreement advances into 2024, the 2022 policy entry is ordered before later dependent actions. When it crosses the 2025 position, Policy v3 becomes part of its reality. A current Agreement may already be at v3.

The regulator does not physically rewrite every Agreement. The precise guarantee is temporal: every Root that claims readiness beyond a canonical policy-change position must include that change. Physical catch-up may be distributed or lazy; the logical result is reproducible.

One Root is one committed reality#

The processor applies one eligible entry to one authoritative Root. Embedded reactions may cascade internally, but one successful invocation commits one coherent new Root. This prevents half-applied reality inside that ownership boundary.

An embedded occurrence is not an independently mutable shared object. Many Roots may contain their own occurrences derived from the same initial Policy and public Timeline; each independently reconstructs the correct state at its verified frontier.

When to use Process Embedded#

Embed when another active process must become part of the Root's exact reality; its Timeline dependencies should participate in feeder readiness; owned state and synchronous deterministic reactions are valuable; and the Root can accept the resulting processing, visibility, and availability boundary.

The fact that histories come from different providers does not by itself require separate Roots. Provider choice and process ownership are different decisions.

When to use a separate Root#

Use a separate Root when the object is independently shared, governed, retained, transferred, or scaled; its lifecycle and authority should survive the parent; participant access differs materially; or it should be operated and addressed on its own.

Agreement → Order is commonly a separate-Root boundary at scale. A Policy occurrence or bounded internal counter may be embedded. The profile—not visual proximity—should decide.

Attaching an already-running process#

Starting with an initial process and consuming its histories from activation is distinct from attaching a process that has already been running for years. Historical catch-up needs explicit admission, cursors, completeness, provenance, recursive discovery, chunking, and side-effect rules.

Use the exact published capability status for this path. The current Playground explains the intended temporal model; it is labelled a concept model rather than production runtime proof.

Composition should remain explicit#

  • Process Embedded — owned occurrence and recursive feeder reality.
  • PINS BLUEID — exact immutable meaning.
  • SUBSCRIBES — selected observation from a separate Root.
  • REQUESTS / RESPONDS — one process asks another to act.
  • CREATES — authorized bootstrap of a new independent Root.