June 10, 2026. I am adding a deposit service because ingestion makes material searchable while a governed deposit has a stricter responsibility. It must refuse a record when the information needed to manage it is missing, place an accepted record where the file plan expects it, and leave enough lineage for a later reviewer to trace the result. The service implements that contract in a fail-closed form. Its tests and today’s planning record give the work a defined starting point; they do not demonstrate an enterprise records program operating at scale.
The record arrives with its context
The service accepts a PDF, a profile, and a governance envelope. The envelope requires a title, record type, an APQC (American Productivity & Quality Center) process code or approved client extension, a registered file-plan folder, retention class, accountable owner, execution state, and source-of-truth path. Intellectual-property-bearing material also requires a Human Expressive Control Ledger (HECL) reference, which records the human authorship decision. Validation returns all detected violations and refuses the deposit when the contract is incomplete. A simple marker check for PDF/A, an archival PDF format, is part of the gate. A document without that marker is refused unless the caller supplies a recorded exception. Full PDF/A conformance verification remains planned.
For an accepted deposit, the service resolves a deterministic Alfresco path under the configured site and document library. It does not create missing site structure, though it can create a registered file-plan folder. When a file with the same record name already exists there, it uses the same node so version history can accrue on it. The service uploads the PDF, stores the governance envelope on the node, records a hash, creates or reuses the file record, writes canonical Alfresco and source-filesystem lineage, grants the owner read and administrator access, and returns a receipt. These are service behaviors. They do not make an operator’s classification or source material correct.
Today’s tests establish the refusal contract
Today’s validation record includes 17 deposit-service refusal and validation tests and reports a repaired suite with 265 passing tests. The repaired test environment matters because earlier work could not clear the full suite. The reported pass count supplies a broader check of the codebase, while the deposit-specific tests support a narrower conclusion. The deposit tests concentrate on validation and refusal conditions, including paths that deliberately prevent the client write. They therefore do not demonstrate a live, accepted Alfresco write. They do establish that missing classification, ownership, retention, provenance, and PDF/A evidence are visible before a file can present itself as a complete record.
Compute is still a plan
The same revision adds a plan for a GPU (graphics processing unit) arbiter as ingestion grows. Embeddings, contextual retrieval, classification, and interactive image work contend for one GPU host. The plan proposes claims, priorities, cooperative interruption, and resumable ingestion batches. It does not establish any of those operating outcomes. The next deposit test is a controlled deployment with a real file-plan registry and a review of receipts, lineage, and exception records. It builds on the earlier same-day ingestion lane in Opening a Dual Ingestion Lane. The arbiter’s test begins only when scheduled or continuous ingestion makes manual sequencing inadequate.
Historical basis: 2026-06-10 repository milestone, commit 6aa8cf8.