Foundation

Open this section when the dispute is about authority: what makes a run acceptable, durable, replayable, and governed instead of merely executable. These pages should make bijux-canon-runtime defensible as the final authority layer rather than a convenient place for leftovers from lower packages.

Boundary Model

flowchart LR
    lower["lower-package outputs"]
    package["runtime boundary"]
    policy["authority policy"]
    record["durable run record"]
    verdict["accepted or replayable run"]
    blur["convenience behavior drift"]

    lower --> package --> policy --> record --> verdict
    package --> blur

The runtime foundation pages need to make authority visible before a reader touches execution detail. Lower-package work arrives here as input, policy is applied here, and only then does a governed record and verdict exist. That is the line that keeps runtime from becoming a general-purpose sink.

Read These First

• open Ownership Boundary first when the change could be explained as lower-package behavior instead of runtime authority
• open Package Overview when you need the shortest stable description of the package role
• open Lifecycle Overview when the question is how governed execution becomes persisted and replayable

The Mistake This Section Prevents

The most common mistake here is broadening runtime with convenience behavior that never changes run authority, which makes the package larger without making its role clearer.

First Proof Check

• packages/bijux-canon-runtime/src/bijux_canon_runtime/application/execute_flow.py for execution authority entrypoints
• packages/bijux-canon-runtime/src/bijux_canon_runtime/observability for durable replay and trace surfaces
• packages/bijux-canon-runtime/tests for acceptance, persistence, and replay proof

Pages In This Section

• Package Overview
• Scope and Non-Goals
• Ownership Boundary
• Repository Fit
• Capability Map
• Domain Language
• Lifecycle Overview
• Dependencies and Adjacencies
• Change Principles

Leave This Section When

• leave this section for Interfaces when the question is already about commands, APIs, schemas, or artifacts
• leave this section for Operations when the problem is running, diagnosing, or recovering runtime behavior
• leave this section for Quality when the authority story is understood and the open question is whether the package has proved it well enough

Design Pressure

If a behavior never changes authority, persistence, or replay, it probably does not belong here. This section has to keep runtime narrow enough that a reviewer can still explain why the package exists at all.