Artifact Contracts¶

Produced artifacts are part of the package contract whenever another package, operator, or replay workflow depends on them.

That means artifacts are not just outputs. They are promises about names, layout, or semantics that downstream readers may already rely on. This page should make those promises visible.

Treat the interfaces pages for bijux-canon-reason as the bridge between implementation detail and caller expectation. They should show what the package is prepared to defend before a dependency forms.

Visual Summary¶

flowchart TB
    page["Artifact Contracts<br/>clarifies: identify contracts | see caller impact | review compatibility"]
    classDef page fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a,stroke-width:2px;
    classDef positive fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef caution fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    classDef anchor fill:#ede9fe,stroke:#7c3aed,color:#4c1d95;
    classDef action fill:#fef3c7,stroke:#d97706,color:#7c2d12;
    surface1["CLI app in src/bijux_canon_reason/interfaces/cli"]
    surface1 --> page
    surface2["HTTP app in src/bijux_canon_reason/api/v1"]
    surface2 --> page
    surface3["schema files in apis/bijux-canon-reason/v1"]
    surface3 --> page
    proof1["apis/bijux-canon-reason/v1/pinned_openapi.json"]
    page --> proof1
    proof2["reasoning traces and replay diffs"]
    page --> proof2
    proof3["apis/bijux-canon-reason/v1/schema.yaml"]
    page --> proof3
    review1["tests/unit for planning, reasoning, execution, verification, and interfaces"]
    review1 -.raises compatibility pressure on.-> page
    review2["tests/e2e for API, CLI, replay gates, retrieval reasoning, and smoke coverage"]
    review2 -.raises compatibility pressure on.-> page
    review3["tests/perf for retrieval benchmark coverage"]
    review3 -.raises compatibility pressure on.-> page
    class page page;
    class surface1,surface2,surface3 positive;
    class proof1,proof2,proof3 anchor;
    class review1,review2,review3 caution;

Current Artifacts¶

reasoning traces and replay diffs
claim and verification outcomes
evaluation suite artifacts

Concrete Anchors¶

CLI app in src/bijux_canon_reason/interfaces/cli
HTTP app in src/bijux_canon_reason/api/v1
schema files in apis/bijux-canon-reason/v1
apis/bijux-canon-reason/v1/schema.yaml

Use This Page When¶

you need the public command, API, import, schema, or artifact surface
you are checking whether a caller can safely rely on a given entrypoint or shape
you want the contract-facing side of the package before building on it

Decision Rule¶

Use Artifact Contracts to decide whether a caller-facing surface is explicit enough to depend on. If the surface cannot be tied back to concrete code, schemas, artifacts, examples, and tests, treat it as unstable until that evidence is visible.

What This Page Answers¶

which public or operator-facing surfaces bijux-canon-reason is really asking readers to trust
which schemas, artifacts, imports, or commands behave like contracts
what compatibility pressure a change to this surface would create

Reviewer Lens¶

compare commands, schemas, imports, and artifacts against the documented surface one by one
check whether a seemingly local change actually needs compatibility review
confirm that examples still point to real entrypoints and not to stale habits

Honesty Boundary¶

This page can identify the intended public surfaces of bijux-canon-reason, but real compatibility depends on code, schemas, artifacts, examples, and tests staying aligned. If those disagree, the prose is wrong or incomplete.

Next Checks¶

move to operations when the caller-facing question becomes procedural or environmental
move to quality when compatibility or evidence of protection becomes the real issue
move back to architecture when a public-surface question reveals a deeper structural drift

Purpose¶

This page marks which outputs need stable review when behavior changes.

Stability¶

Keep it aligned with the package outputs that are actually produced and consumed.