Architecture

Open this section when the question is structural: where run authority lives, how acceptance and persistence flow through the package, and how runtime stays narrower than “whatever happens last.”

Structural Shape

Runtime architecture is the authority layer above lower-package work. Contracts describe what a run may contain, execution modules resolve and run steps, policy modules decide how nondeterminism and budgets are handled, observability captures durable evidence, and verification turns traces into acceptability decisions.

flowchart LR
    contracts["contracts"]
    model["execution model"]
    execution["runtime execution"]
    policy["authority policy"]
    observability["capture and storage"]
    verification["verification rules"]
    verdict["governed run verdict"]

    contracts --> model --> execution --> policy --> verification --> verdict
    execution --> observability --> verification
    policy --> observability

Runtime architecture should explain how authority is applied, not just how code is arranged. Contracts define what a run can contain, execution resolves the lower-package work, policy records the governing decisions, observability keeps the evidence durable, and verification turns that record into a verdict.

Read These First

• open Module Map first when you need the owning code area for a runtime authority concern
• open Execution Model when you need the real path from lower-package output to governed run artifact
• open Integration Seams when a change could blur lower-package semantics with final authority

Structural Risk

The main architectural risk here is broadening runtime until execution order replaces explicit authority design.

First Proof Check

• packages/bijux-canon-runtime/src/bijux_canon_runtime/contracts for flow, step, dataset, and artifact contracts
• packages/bijux-canon-runtime/src/bijux_canon_runtime/runtime/execution for step, retrieval, reasoning, and agent execution adapters
• packages/bijux-canon-runtime/src/bijux_canon_runtime/core/authority.py for explicit runtime authority rules
• packages/bijux-canon-runtime/src/bijux_canon_runtime/observability for capture, storage, replay, and drift analysis
• packages/bijux-canon-runtime/tests for acceptance, replay, and persistence evidence

Pages In This Section

• Module Map
• Dependency Direction
• Execution Model
• State and Persistence
• Integration Seams
• Error Model
• Extensibility Model
• Code Navigation
• Architecture Risks

Leave This Section When

• leave for Interfaces when the structural question is already a public contract question
• leave for Operations when the issue is running, diagnosing, or releasing the package rather than explaining its shape
• leave for Quality when the structure is clear and the real question is whether the package has proved it strongly enough

Design Pressure

If runtime is described only as the place where everything ends, it will gradually absorb behavior that should stay elsewhere. The architecture page has to keep execution, policy, observability, and verification visibly distinct.