BCE / BLUEPRINT ENGINEERINGContext at every scaleDownload film ↗

BCE / THE CONTEXT SPECTRUM

One intent. Context at every scale.

Follow a governed change from the system’s purpose to code, then bring its evidence back.

Context narrows

C1 / System context

Drag to orbit · select a node to inspect
Start with the approved intentILLUSTRATIVE REFERENCE DESIGN · NOT LIVE TELEMETRY
Guided loop0:00 / 1:30

FOLLOW THE MECHANICS

A closer view carries its context.

This is a spatial explanation of the supplied platform blueprint reference design. The example follows one architectural constraint through scope, work, observations, repair and review. C1–C4 are views into the same change.

The full loop shown here is reference architecture. The public BCE repository is a smaller conformance engine; this animation does not claim that the whole platform platform loop is shipped.

Explore BCE on GitHub ↗
Previous architecture walkthrough ↗
Explore the node responsibilities
C1 / Outcome owner
Defines the desired outcome and participates in the review decision.
C1 / Approved blueprint
The reference fixture carries an approved blueprint version; its constraints remain traceable at every closer view.
C1 / Customer intelligence
The system context frames the chosen customer-intelligence example.
C1 / Connected systems
Context sources remain distinct from the authority to change architecture.
C1 / Other systems
These branches remain in the wider system, but are not included in the illustrated change scope.
C2 / Command Center
The supplied example permits the UI to call the context service and forbids direct UI-to-store access.
C2 / Context service
The example routes the UI through this service; the context service may access the brain store.
C2 / Brain store
A direct connection from the UI is forbidden by the inherited architectural rule.
C2 / Signal engine
A related component in the supplied blueprint; dimming represents this film’s selected change scope.
C2 / Connector service
Another blueprint component, retained in the system but outside this illustrated change.
C3 / Resolve + inherit
Resolve the selected blueprint and materialise inherited rules with their effective versions.
C3 / Context compiler
A presentation label for Blueprint Compiler and execution-policy compilation in the supplied reference design, not a new product API.
C3 / Scoped work order
Carries file scope, acceptance criteria, permitted tools and stop conditions.
C3 / Observation
Collects attributable evidence about the subject repository and revision.
C3 / Coverage
Incomplete coverage remains explicit and can request additional observation.
C3 / Decision readiness
Assembles the context needed for a decision. It does not substitute for approval authority.
C4 / Implementation
The concrete code change is the subject, not a new source of policy authority.
C4 / Observed facts
Facts describe the observed source. They do not automatically prove missing or unobserved parts.
C4 / BCE evaluation
The reference evaluator checks constraints against repository facts and preserves unknown coverage.
C4 / Finding
A finding explains which rule was violated, supported or left unknown for this subject.
C4 / Evidence bundle
Links findings, subject and blueprint references so evidence can return to a decision.

  1. Follow a governed change from the system’s purpose to code, then bring its evidence back.

  2. The parent architecture forbids direct UI access to the data store. A closer view cannot silently remove that rule.

  3. Keep the UI, context service and data store in focus. The other branches remain in the system, outside this change.

  4. Scope, allowed tools, required evidence and stop conditions become explicit inputs to execution.

  5. Compare the implementation’s observed dependency with the relationship authorised by the blueprint.

  6. A direct UI → data-store edge breaks the boundary. Pull back to see which relationship the finding violates.

  7. The work returns with a concrete finding. Correct the implementation while preserving the governing rule.

  8. The corrected relationship, source revision and evaluation become evidence about this specific change.

  9. With no violation observed, incomplete coverage still leaves the result unknown. Request the missing observation; an observed violation still fails.

  10. Bring the scoped change, its inherited boundaries, findings and evidence back together for review.

  11. A different architecture requires a reviewed blueprint change. The next loop starts with explicit intent and authority.