Skip to content

Change Principles

An ingest change is acceptable when it makes source preparation more explicit without silently changing identity, offsets, ordering, failure visibility, or the meaning of persisted artifacts. Convenience is not sufficient if a downstream consumer can no longer explain how prepared material was produced.

Invariants To Preserve

Invariant Why it matters
source identity precedes transformation normalization must not invent a different document owner
chunk identity binds source, span, and content citations and deduplication depend on addressable preparation output
ordering and partial failure remain visible streaming success must not conceal loss or reordering
embedding identity qualifies every vector dimension alone cannot identify model semantics
codecs reject unknown contracts readable bytes are not automatically valid package artifacts
local retrieval remains a bounded seam governed vector execution belongs to index
evidence interpretation stays downstream ingest prepares support; reason evaluates claims

Route The Change

flowchart TD
    proposal["proposed behavior"]
    prepare{"changes source preparation?"}
    local["change ingest contract and evidence"]
    retrieval{"changes shared index policy or replay?"}
    index["route to bijux-canon-index"]
    meaning{"interprets evidence or claims?"}
    reason["route to bijux-canon-reason"]
    runtime["route scheduling or admission to runtime"]

    proposal --> prepare
    prepare -->|yes| local
    prepare -->|no| retrieval
    retrieval -->|yes| index
    retrieval -->|no| meaning
    meaning -->|yes| reason
    meaning -->|no| runtime

A feature may cross packages, but each decision remains with its owner. For example, ingest may emit a richer chunk fingerprint while index changes how it records that identity and reason changes how citations refer to it. One package must not reimplement the others to make the integration appear local.

Change Evidence

Changed surface Evidence required before the new claim is credible
cleaning or parsing accepted/rejected input cases, normalization examples, and cache impact
chunking or deduplication span, identity, ordering, tail-policy, and round-trip tests
streams or effects backpressure, scheduling, termination, resource, and partial-failure tests
embedding adapter model specification, dimension, fingerprint, and deterministic baseline tests
persistence format versioned codec tests, loading failure cases, and migration posture
CLI or HTTP model interface mapping, schema drift, exit/error semantics, and end-to-end handoff
retrieval-quality claim named corpus, queries, relevance judgments, parameters, and offline metrics

Update public examples and artifact descriptions in the same change when an observable contract moves. A passing unit test does not excuse documentation that still describes the old identity, offset, or persistence semantics.

Refusal Conditions

Do not merge a change that turns an expected partial failure into empty success, weakens an artifact version check, makes model identity optional for a reproducibility claim, or expands local retrieval into shared indexing policy. Resolve the owning boundary first.

Use domain language for precise terms and test strategy for the package evidence layers.