Continuous Ingestion API

Ingestion brings an artifact into governed ENTITY state while preserving source, controller, rights-holder, evidence and provenance boundaries. v3.4.2 adds BTDU repository/object ingestion without converting topology into ownership.

Required concepts

Before ingesting, establish the acting Entity, the authorization scope, the source Entity, the controller, any explicit rights holder, the provenance reference and the media type. Do not infer those fields merely from filesystem ownership or the machine performing the ingest.

BTDU object ingestion

BlackmoreTechnologyDataUniverse.ingest_bytes() verifies a mutation authorization receipt, computes content SHA-256, creates evidence, produces an exact-byte compound, creates a governed BTDU object and bonds it to source/controller/rights/evidence/provenance references. Boundary metadata explicitly states that topology does not create ownership or economic entitlement.

Repository ingestion

The v3.4.2 operator CLI exposes ingest-repo. Repository manifests record repository path, Git commit/tree where available, tracked-file count, aggregate SHA-256 and the resulting atomic root. For a release or qualification ingest, use a pinned commit/tag in the provenance reference rather than a moving branch name.

python tools/entity_btdu_cli.py --entity-state STATE --btdu-state BTDU --adam-root ADAM --git-bin git ingest-repo PATH --provenance git://owner/repo@COMMIT

Idempotence and history

Content-addressed atoms/compounds should be reused where the canonical identity is identical. A changed artifact is a new state/derivation, not permission to mutate the historical record into pretending the old bytes never existed.

Continuous workflows

For directories, repositories or long-running pipelines, record checkpoints, source hashes, rejected/failed records, and the resulting state/evidence roots. If a later ingestion changes authoritative material, create a new derivation/event and preserve the earlier evidence.

Real-world qualification

For post-release REAL_WORLD_TRAINING validation, the frozen v3.4.2 artifact can ingest appropriately licensed real-world data and accumulate evidence outside the release artifact. If the exercise changes release-critical code, executable artifacts, model weights, schemas or protocol behavior, that result belongs to a subsequent candidate rather than rewriting v3.4.2.