08 — Adapter / Source Coverage (the count-reliability root)

Census of sources (v_universal_workflow_census_v2, 16 sources, computed LIVE 2026-06-05 02:10)

layer	source	raw	mapped	adapter_status	coverage_status
DB	approval_requests	230	–	LIVE_DB_FN	PARTIAL_DB
DB	dot_family_pairs	131	–	LIVE_DB_FN	COVERED_NO_RP
DB	dot_iu_command	54	–	LIVE_DB_FN	PARTIAL_DB
DB	dot_tools	309	–	LIVE_DB_FN	COVERED_NO_RP
DB	event_type_registry	52	–	LIVE_DB_FN	PARTIAL_DB
DB	job_queue	8	–	LIVE_DB_FN	PARTIAL_DB
DB	orphan_components	84	–	LIVE_DB_FN	COVERED_NO_RP
DB	pg_proc_functions	571	–	LIVE_DB_FN	PARTIAL_DB
DB	pg_trigger	410	–	LIVE_DB_FN	PARTIAL_DB
DB	workflows	2	–	LIVE_DB_FN	COVERED_NO_RP
FS	fs_dot_bin	287	186	LIVE_ADAPTER	HOST_INGESTED_PARTIAL_MAP
FS	fs_scripts	42	0	LIVE_ADAPTER	HOST_INGESTED_NO_DOT_LINK
HOST	docker_containers	11	0	LIVE_ADAPTER	HOST_INGESTED_INFRA
HOST	host_crontab	54	7	LIVE_ADAPTER	HOST_INGESTED_PARTIAL_MAP
HOST	systemd_timers	22	0	LIVE_ADAPTER	HOST_INGESTED_OS_LEVEL
KB	kb_sop_docs	2	0	LIVE_ADAPTER	KB_PARTIAL_ENUM (evidence LIVE_PARTIAL)

wf_source_adapter_health_v2: 10 LIVE_DB_FN + 5 LIVE_ADAPTER + 1 LIVE_ADAPTER_PARTIAL (KB).

Coverage verdict by layer

• DB layer (10 sources): full, native, LIVE. Counts reliable. This is where every reconciling number in docs 01–07 comes from.
• Host/FS layer (5 sources): raw ingest is LIVE and reliable; process/DOT mapping is very partial — fs_dot_bin 186/287, host_crontab 7/54, systemd 0/22, docker 0/11, fs_scripts 0/42. Object counts trustworthy; "mapped to a process/owner" counts are not.
• KB layer (1 source): PARTIAL, count UNKNOWN. Only 2 SOP docs enumerated; the note warns "Count UNKNOWN (needs KB adapter). FP-risk: doc mentions process ≠ process." → least reliable source.

Adapter blind spots (the 6 v_workflow_discovery_source_missing_adapter rows)

These 6 host/KB sources have ingestion snapshots but remain governance-blind, per their own notes:

• host_crontab (54, 49 active): "The TRUE schedule for dot- runners lives HERE, not dot_tools.cron_schedule. DB-invisible."* → any UI showing dot_tools.cron_schedule may show the WRONG schedule.
• fs_dot_bin (287): "dot_tools has 309 rows but only 119 script_path. Reconciliation gap."
• systemd_timers (22): 21 timers incl process-discovery-policy-scan.timer. DB-invisible.
• fs_scripts (42): 31 maintenance shell workflows. DB-invisible.
• kb_sop_docs (2): count UNKNOWN, FP-risk.
• docker_containers (11): infra hosting workflow behavior.

Scanner / timer health

wf_scanner_run_log: 5 scanners (UNIVERSAL_CENSUS, ORPHAN_DETECTOR, RP_VISIBILITY_PROOF, SOURCE_ADAPTER_HEALTH, CLASSIFICATION_DRIFT), all last SUCCESS at 2026-06-04 09:53. No 2026-06-05 run logged — server time at audit was 02:36 UTC, before the armed 04:10 daily slot, so this is expected, NOT a failure. However the prior run was at 09:53 (not 04:10), so the automated daily schedule's first real fire is still unproven. Mitigation: the census/coverage views recompute LIVE on query (computed_at stamped 02:10), so live surfaces are fresh regardless of digest staleness. The persisted wf_*_digest_v2 tables are the ~1-day-old 06-04 snapshots — UI must read the live views, not the digest tables.

Classification

• DB sources → OK.
• Host mapping partial → ADAPTER_BLIND_SPOT (counts of "managed" objects undercount).
• KB enumeration → ADAPTER_BLIND_SPOT (count unknown, FP-risk) — the single biggest reliability hole.
• Scanner first-fire unproven → NEEDS verification (non-blocking; live views compensate).

Score: 62/100

DB coverage excellent; host coverage ingest-only with partial mapping; KB coverage essentially unknown. This layer is the principal reason no count that touches host/KB can be fully trusted yet.