What does this office hold in the document store?

Office documents by issuing body. Part of what the twin can answer. Every figure below is the value the route serves, with its source; the raw response is at /api/twin/brain/objdocs/body/dpdt.

Descriptive, sourced: no model

Basis: sourced records (URL, sha256 or locator per row), no model.

stored files, documents and chunks, and counts over them

dpdt.gov.bd: files by type

Type	Files	Bytes
pdf	Files: 379	Bytes: 3,209,374,767
docx	Files: 1	Bytes: 104,779

Manifest line	Type	Bytes	Upload folder
27,148	Type: pdf	Bytes: 336,640	Upload folder: 2024/12
27,151	Type:

Source	Publisher	Unit	Caveat
Stored files from government portals	Publisher: Uploading offices of the national portal (stored copies)	Unit: one row per stored file: manifest line, URL, sha256 at fetch, bytes, office, upload folder, file type; source file is relative to the archive disk root	Caveat: upload folder is the object store's <year>/<number> folder exactly as it appears in the URL, not the document's own date; under 2026 the number runs 0 to 8, so it may be a zero-based month, which is not verified. The issuing body is the office-<slug> URL segment; its portal host is the slug with hyphens read as dots. Body and Place links are exact-domain matches only. sha256 verified is set only for re-hashed files (the random sample and the pilot); the rest carry the harvest's own sha256.

Document and chunk text: Never stored in the lake or served; chunks are located by page range and pinned by the sha256 of their extracted text so a reader re-extracts them.
Documents about a person: CVs, personal data sheets, rosters and beneficiary lists are screened out of the pilot; their printed dates and memo lines would describe individuals.
Phone numbers: Counted per chunk and document at the build (phones_detected), never stored.
A2 oracle_wave spec values: LLM-derived; used only to order pilot candidates, never served.