Authority Decision Matrix — DRAFT (after Baseline Reconciliation)

Nature: decision matrix DRAFT for owner/GPT/Codex review. NOT implementation, NOT a plan-to-build, NOT cleanup, NOT a reconciliation mutation. It turns the BASELINE_READY_FOR_AUTHORITY_DECISION ledger into reviewable, approvable authority decisions. Production mutation: NO. No install, no registry edit, no PG mutation, no Directus update, no tool/schema/runner created, no FIX7 resumed, no denominator collapsed, no authority decided by assumption. Source of every count below: reports/dot-registry-directus-text-as-code-baseline-reconciliation-2026-06-09.{md,json} (live read 2026-06-09 07:11–07:30 UTC, role context_pack_readonly, READ ONLY). Counts are carried, never merged. Strict rule applied: "Không chắc đúng = sai." Every recommendation states its confidence; anything not read this session is marked UNVERIFIED/BLOCKED, not filled with judgment. A single canonical DOT number is treated as a disguised hardcode — decisions designate contracts, not constants.

1. Final verdict

AUTHORITY_MATRIX_READY_FOR_GPT_REVIEW

The baseline supplies enough separated, dated, sourced evidence to draft a complete recommendation for all ten authority domains (A–J). The matrix does not resolve the conflicts — it frames each as an approvable decision with a recommended option, a confidence, and an explicit prohibition envelope. Four domains carry decisions that only an owner/Codex can seal (C, D, G, H); five carry safe conservative defaults that can be adopted now (A, E, F, I, J); one (B) is a measurement-authority decision blocked only on a fresh read. None of this is blocked by a conflict in the matrix itself — the conflicts are inputs the matrix is designed to surface.

Why not …PARTIAL_NEEDS_MORE_READS: the matrix is complete and reviewable as drafted; the residual fresh-reads (CAT-006 actual_count filter, /opt/incomex/scripts "42", direct OS listing, Đ23 inverse-check) are named as decisions, not gaps that prevent drafting the matrix. Why not …BLOCKED_BY_CONFLICT: the denominator conflict is the matrix's subject matter, not an obstacle to it. Nothing prevents the owner from reviewing and approving.

2. Input baseline summary (denominators carried, NOT collapsed)

Restated from the baseline ledger. Each line is a distinct denominator on a distinct surface at a distinct date — they are not alternative measurements of one quantity.

Axis	Surface	Denominator	Count	Date/Mode	Conf
Registry	`dot_tools` rows	catalog rows (system of record)	309	live 07:11; frozen since 2026-04-02	HIGH
Registry mirror	`meta_catalog` CAT-006 `record_count`/`active_count`	catalog claim	309 / 309	scan 06:00	HIGH
Registry pivot	PIV-007 total / PIV-104 group-sum	pivot of registry	309 / 309	refreshed 07:07, fresh	HIGH
Registry scan field	CAT-006 `actual_count`	scan result (filter undefined)	163	scan 06:00	HIGH value / UNVERIFIED definition
Registry scan field	CAT-006 `baseline_count`	baseline	151	scan 06:00	HIGH
Filesystem	`wf_fs_dot_bin_snapshot` total / operational / backup	`/opt/incomex/dot/bin` objects	289 / 214 / 75	snapshot 06-09 02:10 (freshest FS)	HIGH
Reg∩FS	`wf_fs_dot_bin_snapshot` mapped / `v_dot_reconciliation_reliability` CONFIRMED	operational mapped to a registry code	186	snapshot 02:10	HIGH
Reliability strata	`v_dot_reconciliation_reliability`	309 stratified	186 CONFIRMED + 100 REGISTERED + 19 HELPER + 4 MISSING_FILE	live	HIGH
Reg→FS diff	`v_dot_registry_no_file`	registry rows w/ no file	41	live (own match-base)	HIGH
FS→Reg diff	`v_dot_fs_reconciliation` / derived	file-no-registry	16 pure (26 w/ backup) @06-03 · 28 derived @06-09	live	HIGH-for-base
Registry shape	`dot_tools` file_path / script_path / classification='real'	populated cols	228 / 119 / 0	live	HIGH
Execution layer	`dot_iu_command_catalog` (mutating 39 / reversible 41)	IU↔DOT command bridge	54	live	HIGH
Execution layer	`dot_iu_command_run` / `dot_operations` / `dot_iu_runtime_lease`	runs / op-codes / lease	55 / 20 / exists	live	HIGH
Law binding	`law_dot_enforcement`	law↔DOT bindings (≠ old "272 dot_tools")	272	live	HIGH
Directus	`directus_flows` total / active / DOT-named	flows	128 / 111 / 36	live	HIGH
Directus control	flow evidence	100% DOT-control	PARTIAL_EVIDENCE_ONLY	live	—
Repo/local	`…/web-test/dot/bin`	local checkout (not prod, not registry)	163	live local	HIGH
Text-as-Code	`information_unit` / `tac_logical_unit`	two parallel corpora	219 / 102	live	HIGH
Text-as-Code bridge	`pg_views` joining both	DB compat/bridge view	NONE (0)	live	HIGH

BLOCKED/UNVERIFIED carried forward: /opt/incomex/scripts "42" (BLOCKED — not reachable read-only); direct OS listing of /opt/incomex/dot/bin (BLOCKED — PG mirror used instead); CAT-006 actual_count=163 filter (UNVERIFIED definition); Đ23 inverse-check unmonitored/unregistered (UNVERIFIED — not run); TAC↔IU corpus authority (UNRESOLVED — owner decision); Directus 100%-control (PARTIAL_EVIDENCE_ONLY).

3. Authority domains

Each domain below carries: recommended option · confidence · supporting evidence · risks · prohibited-until-resolved · Codex review required? · blocks Implementation Package DOT spec?

Convention used throughout: a load-bearing set is defined by a runtime query against a named surface, never by a literal constant or a hand-maintained list (that would be the disguised-hardcode failure class the baseline warns of). "186-confirmed", "214-operational" etc. name queries, not magic numbers the tool would bake in.

A. DOT registry / catalog / listing authority

Question: which denominator should be used for registry/catalog/listing? Candidates: 309 dot_tools/PIV-007 · 214 operational files · 186 registry-confirmed/mapped · 163 CAT-006 actual_count/local · other.

Recommended: 309 dot_tools is the canonical registry / catalog / listing denominator — it is the system of record for "what DOTs are registered", and is internally consistent across meta_catalog (309), PIV-007 (309), PIV-104 (309). Listing is always the live SELECT … FROM dot_tools, never the literal 309. 214/186/163 are not catalog denominators — they answer different questions (FS presence, reg∩FS, scan-actual) and belong to domains B/C.
Confidence: HIGH (for "the registry is the catalog of record"). MEDIUM that 309 is currently accurate — it is frozen since 2026-04-02 while FS scans are fresh.
Evidence: A1/A8/A9/A13/A14 all = 309 and mutually consistent + fresh pivot (07:07). A7 freeze flag. A6 classification='real'=0 (catalog does not self-certify runnability).
Risks: registry freeze means the catalog may overstate live reality; 142/309 have no category; 41 registry-no-file. Using 309 for listing is correct; using it for runnability is the trap (see B/C).
Prohibited until resolved: treating 309 as the count of runnable or file-backed DOTs; baking any constant into a tool.
Codex review required? Light — to ratify "309 = catalog of record, frozen, listing-only" wording.
Blocks IP DOT spec? No (definitional). The freeze is handled by domain D's reconciliation contract.

B. DOT runtime executable authority

Question: which surface proves a DOT can actually run? Candidates: /opt/incomex/dot/bin operational files · dot_tools registry · command catalog · local checkout · other.

Recommended: /opt/incomex/dot/bin operational files (214, wf_fs_dot_bin_snapshot status=OPERATIONAL) is the runtime-presence authority; proof-of-run is the union of (operational presence) + an actual-run record in dot_iu_command_run (55) / governance in dot_iu_command_catalog (54). The registry does NOT prove runnability (no executable flag: classification='real'=0, frozen). The local checkout (163) is explicitly NOT production and must never be cited as runtime proof.
Confidence: MEDIUM. "OPERATIONAL" proves the file exists and is live/non-backup; it does not prove the file executes cleanly with a 0 exit code. That stronger proof needs the run-ledger or an actual dry-run.
Evidence: B2 operational=214; A6 classification unused; A4/A5 file_path 228 / script_path 119 (≈190 rows are DB/non-file → not runnable as files); C1 local=163 not prod; E1/E2 command catalog 54 / run-ledger 55.
Risks: operational≠successfully-runs; B8 direct OS listing is BLOCKED so 214 rests on the PG mirror; CAT-006 actual_count=163 (a competing "actual" claim) has an UNVERIFIED filter.
Prohibited until resolved: asserting any DOT "runs" from registry presence alone, or from the local checkout; treating 214 as proven-runnable rather than proven-present.
Codex review required? Yes (defines what "can run" means for the verifier).
Blocks IP DOT spec? Yes, for the execution-claim portion — and partly blocked on a fresh read (direct OS listing / actual_count filter) to settle 214 vs 186 vs 163.

C. DOT safe-reuse authority for a future Implementation Package DOT

Question: which subset is safe for a new checker to call directly? Candidates: all 309 registry rows · 214 operational files · 186 registry-confirmed/mapped · only command catalog 54 · manually whitelisted profile.

Recommended: a computed safe-reuse profile = 186 fs-confirmed (v_dot_reconciliation_reliability = DOT_EXECUTABLE_CONFIRMED) ∩ command-catalog-governed (dot_iu_command_catalog, reversible/lease-bound), evaluated by query at runtime. For v0.1 (read-only) the verifier should read, not invoke; if it must invoke, route only through the existing command-catalog + dot_iu_runtime_lease governance. Reject all 309 (190 DB/non-file, 41 no-file, frozen). Reject raw 214 (28 unmapped, unknown provenance). Reject a manually whitelisted literal — a hand-list is the disguised-hardcode failure class; the profile must be a runtime intersection of named surfaces.
Confidence: MEDIUM.
Evidence: F1 (186 CONFIRMED / 100 REGISTERED / 19 HELPER / 4 MISSING); B5 (28 operational-not-mapped); E1/E6 (command catalog + runtime lease govern execution with reversibility flags).
Risks: 186 rests on the 02:10 PG mirror; the 41-vs-4 reg→FS drift (domain D) means "confirmed" depends on the chosen FS base; invoking anything in v0.1 contradicts read-only scope.
Prohibited until resolved: any checker calling/executing a DOT outside the sealed safe profile; any static whitelist constant; any execution at all in v0.1 read-only mode.
Codex review required? Yes (this is the safety boundary for a tool that could call code).
Blocks IP DOT spec? Yes, for the call/execute portion. The read-only reporting skeleton is not blocked.

D. Registry ↔ filesystem reconciliation contract

Question: how should registry-no-file (41) and file-no-registry (16–28) be treated? Options: block all new tool design · allow design but block runtime calls to unmatched entries · read-only warning only · require cleanup before any tool work.

Recommended: allow design + block runtime calls to unmatched entries + emit read-only warning — i.e. a fail-closed call boundary (unmatched = NON-CALLABLE) combined with read-only reporting on the mismatch. Do not require cleanup first (cleanup is mutation, out of scope) and do not block all design (over-restrictive; the reconciliation surfaces already exist and should be reused). The contract must also designate the canonical reg→FS diff base: v_dot_registry_no_file=41 and v_dot_reconciliation_reliability.DOT_MISSING_FILE=4 disagree because they use different FS bases/match-keys — owner must pick which is canonical.
Confidence: MEDIUM (the treatment policy is clear; the canonical diff base is an unresolved owner sub-decision).
Evidence: F1/F2/F3/F4; the 41-vs-4 drift; B5 (28) vs F4 (16) file-no-registry by date. The reconciler surfaces (wf_fs_dot_bin_snapshot, _recon_dot_fs_inventory, v_dot_fs_reconciliation, v_dot_registry_no_file, v_dot_reconciliation_reliability) are already deployed — reuse, do not rebuild.
Risks: choosing the wrong canonical diff base mislabels "confirmed"/"missing"; date skew (registry frozen 04-02 vs FS 06-09) inflates apparent drift.
Prohibited until resolved: any tool treating registry-no-file or file-no-registry entries as callable; any reconciliation mutation (rebirth/cleanup); rebuilding a reconciler.
Codex review required? Yes — to seal the canonical diff base + the call boundary.
Blocks IP DOT spec? Yes — this contract is a prerequisite for C's safe-call set.

E. Directus mutation authority

Question: can Implementation Package DOT or future tools touch Directus directly? Options: no direct mutation until 100% DOT-control proven · only via existing DOT Sync/Utility flows · only via approved Directus DOT tools · unresolved.

Recommended: no direct Directus mutation until 100% DOT-control is proven. Any future write routes only through the existing [DOT-REG] sync / [WATCHDOG] dot_tools→Changelog flows. For v0.1 (read-only) this is free — the verifier does not write Directus.
Confidence: HIGH (conservative default, matches the read-only scope and the unproven control state).
Evidence: §6 Directus control = PARTIAL_EVIDENCE_ONLY; 128 flows / 36 DOT-named incl. ~21 [DOT-REG] mirror + 3 [WATCHDOG]; manual-mutation block NOT proven.
Risks: none for read-only v0.1. The risk is future scope-creep into direct CRUD before control is proven.
Prohibited until resolved: any direct Directus MCP/API CRUD by the tool; assuming the estate is already 100% DOT-controlled.
Codex review required? No for the read-only stance; Yes if/when any mutation path is ever proposed.
Blocks IP DOT spec? No (v0.1 is read-only).

F. Checker / logger authority

Question: which logger/checker issue sink is authoritative? Candidates: fn_tac_log_checker_issue → system_issues · existing DOT issue flow · file-report-only for v0.1 · new logger prohibited.

Recommended: the authoritative sink is the deployed fn_tac_log_checker_issue → system_issues (per Đ23 "findings → system_issues"); a new logger is PROHIBITED (would fork authority). But v0.1, being read-only, uses file-report-only and DEFERS the system_issues write until the verifier is approved to mutate. So: authoritative sink named now, write deferred.
Confidence: HIGH.
Evidence: fn_tac_log_checker_issue→system_issues is deployed (memory S183); Đ23 routes findings to system_issues; writing to system_issues is a mutation, excluded from read-only v0.1.
Risks: writing to system_issues in v0.1 would breach read-only; building a parallel logger would duplicate authority.
Prohibited until resolved: creating any new logger/sink; writing to system_issues from a read-only v0.1.
Codex review required? No (reuse of a deployed function under Đ23).
Blocks IP DOT spec? No.

G. Graph / duplicate / orphan authority

Question: which system owns duplicate/orphan/impact detection? Candidates: universal_edges / v_kg_edges_all · entity_dependencies · Đ23 inverse-check · Đ19 orphan scanners · duplicate engine (if exists) · new resolver prohibited unless proven gap.

Recommended: reuse existing, new resolver prohibited until a gap is proven by running the existing engines. Mapping: DOT orphan/missing = v_dot_reconciliation_reliability + v_dot_registry_no_file (deployed); general orphan = Đ19 scanners; unmonitored/unregistered inverse = Đ23 inverse-check; impact/graph = universal_edges / v_kg_edges_all + entity_dependencies. The "doc-level duplicate-authority resolver" the first plan listed as new work is NOT yet a proven gap — the Đ23 inverse-check (F5) was not run this session.
Confidence: MEDIUM (existence of engines is known from memory/baseline; whether a dedicated duplicate engine already exists is UNVERIFIED, and the inverse-check was not run).
Evidence: F5 UNVERIFIED (Đ23 inverse-check not run); memory: universal_edges (CAT-130) + v_kg_edges_all, Đ8/Đ19/Đ14 engines deployed.
Risks: building a new duplicate/graph resolver would fork authority and repeat the very anti-duplication failure this initiative exists to prevent.
Prohibited until resolved: authoring any new duplicate/orphan/graph resolver before running the existing Đ19/Đ23/universal_edges engines read-only and proving a true gap.
Codex review required? Yes — to confirm no fork and to authorize the gap-proving read-only runs.
Blocks IP DOT spec? Partial — blocks the new-resolver work item only; reuse-reporting is not blocked.

H. Text-as-Code corpus authority

Question: how to treat information_unit=219 vs tac_logical_unit=102? Options: IU canonical / TAC legacy · TAC canonical until bridge · dual-corpus unresolved (tool must not choose) · require compat/bridge view before tool work · allow read-only dual reporting.

Recommended: dual-corpus unresolved — the tool must NOT choose — combined with: allow read-only dual reporting now, and require a bridge view (or an explicit owner decree) before any tool consumes either as the canonical package corpus. The evidence does not support declaring either canonical or legacy.
Confidence: HIGH (for the "must not choose / dual reporting / require bridge" stance — it is the only evidence-safe option).
Evidence: G1 IU=219; G2 TAC=102 (+ tac_unit_version 102 / tac_publication_member 102 / tac_publication 4); G4 no DB compat view (pg_views=0); the IU↔DOT bridge (dot_iu_command_catalog 54) does not reconcile corpus authority.
Risks: picking one corpus by assumption would silently de-authorize 219 or 102 rows and bake a wrong SSOT into the verifier.
Prohibited until resolved: any tool consuming IU or TAC as the canonical corpus; any silent merge; any assumption of legacy/canonical without an owner decision or bridge view.
Codex review required? Yes — corpus authority is an owner+Codex decision.
Blocks IP DOT spec? Partial — blocks the corpus-consumption portion; read-only dual reporting is not blocked.

I. Evidence / report storage authority

Question: where should future checker evidence be written? Options: file-report-only under knowledge/dev/laws/tool-kiem-thu/ · system_issues · context_pack reports · Directus registry tables · unresolved.

Recommended: v0.1 = file-report-only under knowledge/dev/laws/tool-kiem-thu/ (read-only-safe, no mutation). Escalation path: confirmed issues → system_issues via fn_tac_log_checker_issue (domain F) once approved to mutate. Directus registry tables = NO (mutation; domain E). context_pack reports = read-only consume only.
Confidence: HIGH.
Evidence: consistent with E (no Directus mutation) and F (system_issues is the eventual authoritative sink, deferred); the initiative's own folder is the established report home.
Risks: none for v0.1; only risk is premature mutation.
Prohibited until resolved: writing evidence to system_issues / Directus / any DB table from read-only v0.1.
Codex review required? No.
Blocks IP DOT spec? No.

J. Runtime mirror authority

Question: where can future executable DOT code live? Options: /opt/incomex/dot/bin only · KB design under knowledge/dev/dot/ + runtime mirror /opt/incomex/dot/bin · repo dot/bin then deploy · unresolved.

Recommended: design-in-KB (knowledge/dev/…) + runtime mirror in /opt/incomex/dot/bin, matching the already-deployed pattern (Đ43 paired build/verify on VPS cron; dryrun.py template in iu-cutter). The local checkout (…/web-test/dot/bin, 163) is NOT a runtime and must not be treated as one. This decision only bites when executable code is actually written, which is post-spec.
Confidence: MEDIUM-HIGH.
Evidence: C1 local 163 not prod; B1/B2 /opt/incomex/dot/bin is the runtime surface; memory: Đ43 build rev11/verify rev5 on VPS cron; dryrun.py runnable template deployed.
Risks: none now (no code written in v0.1); future risk is divergence between KB design and runtime mirror if not gated by Đ43 verify.
Prohibited until resolved: treating the local checkout as production runtime; deploying runtime code before the spec exists.
Codex review required? Light (ratify the design↔mirror pattern when code is first proposed).
Blocks IP DOT spec? No (deferred; v0.1 writes no runtime code).

3.Z — Domain decision summary

Dom	Recommended	Conf	Codex?	Blocks spec?
A	309 `dot_tools` = catalog of record (listing = live query; frozen 04-02)	HIGH	light	No
B	`/opt/incomex/dot/bin` operational (214) = presence; +run-ledger = proof-of-run	MED	Yes	Yes (exec claim) + fresh read
C	computed profile = 186-confirmed ∩ command-catalog-governed; no static whitelist	MED	Yes	Yes (call portion)
D	allow design + block calls to unmatched + warn; owner picks canonical diff base (41 vs 4)	MED	Yes	Yes
E	no direct Directus mutation until 100% control proven	HIGH	No (now)	No
F	sink = `fn_tac_log_checker_issue→system_issues`; v0.1 file-only; new logger prohibited	HIGH	No	No
G	reuse Đ19/Đ23/`universal_edges`; new resolver prohibited until gap proven	MED	Yes	Partial
H	dual-corpus, tool must not choose; read-only dual reporting; require bridge before consume	HIGH	Yes	Partial
I	v0.1 file-report-only; escalate to `system_issues` post-approval	HIGH	No	No
J	KB design + `/opt/incomex/dot/bin` mirror; local checkout ≠ runtime	MED-HIGH	light	No

4. Proposed closure plan (minimal sequence)

4.1 — Can be decided NOW (safe conservative defaults, adoptable on this matrix's approval):

A — 309 dot_tools = catalog of record (listing always a live query; freeze noted).
E — no direct Directus mutation until 100% control proven.
F — authoritative sink = fn_tac_log_checker_issue→system_issues; v0.1 file-only; no new logger.
I — v0.1 file-report-only under tool-kiem-thu/.
J — KB design + /opt/incomex/dot/bin runtime mirror pattern (binds only when code is written).

4.2 — Need Codex review (sealed only by owner/Codex):

C — the computed safe-call profile (186-confirmed ∩ command-catalog-governed) and the "no execution in v0.1" boundary.
D — the canonical reg→FS diff base (41 vs 4) and the call-boundary contract.
G — confirmation that no duplicate/graph resolver may be built before the existing engines prove a gap.
H — TAC↔IU corpus authority (or a mandate to build a bridge view first).
B — the definition of "can run" for the verifier (presence vs proof-of-run).

4.3 — Need a fresh read (read-only, explicitly authorized) before sealing the above:

CAT-006 actual_count=163 filter definition (settles the 309-vs-163 in-row gap).
Direct OS listing of /opt/incomex/dot/bin (settles 214 vs 186 vs the 41-vs-4 drift) — currently BLOCKED by allowlist.
/opt/incomex/scripts "42" surface — currently BLOCKED.
Run the Đ23 inverse-check / Đ19 read-only (F5) to prove/disprove the duplicate-authority gap (feeds G).

4.4 — Should be deferred (not on the critical path):

J runtime-mirror specifics (post-spec, only when executable code is authored).
B proof-of-run deepening via dot_iu_command_run history (after presence authority is set).

4.5 — Should NOT block Implementation Package DOT spec:

A, E, F, I, J, and the read-only dual-reporting half of H — all have safe defaults. The read-only reporting skeleton of the verifier can be specified under these without waiting on C/D/G/H seals.

5. Impact on Implementation Package DOT

5.1 — What can be reused safely (deployed + confirmed live this session):

Registry/catalog/pivot: dot_tools, meta_catalog (CAT-006), pivot_definitions/pivot_results (PIV-007/PIV-104).
Reconciliation (the DOT↔FS reconciler — do not rebuild): wf_fs_dot_bin_snapshot, _recon_dot_fs_inventory, v_dot_fs_reconciliation, v_dot_registry_no_file, v_dot_reconciliation_reliability.
Execution layer: dot_iu_command_catalog/_run/_runtime_lease, dot_operations; template iu-cutter/.../dryrun.py.
Logging/findings: fn_tac_log_checker_issue → system_issues (Đ23) — named authoritative sink (write deferred in v0.1).
Graph/orphan: universal_edges/v_kg_edges_all, entity_dependencies, Đ19/Đ23 engines.
Directus integration: directus_flows [DOT-REG]/[WATCHDOG] sync/watchdog (read-only observation).
Law binding: law_dot_enforcement.

5.2 — What must NOT be touched:

No registry edit; no Directus mutation (E); no PG mutation; no system_issues write in v0.1 (F/I); no new logger (F); no new duplicate/graph/orphan resolver until a gap is proven (G); no choosing a canonical TAC/IU corpus (H); no static DOT-count constant anywhere (A/C); no execution of any DOT in read-only v0.1 (C); no FIX7 resume; no install.

5.3 — True gaps that may remain (narrow, and each conditional on the open decisions):

A command-runner-with-exit-codes (the noted dryrun.py "refuses to run" limitation) — gap status conditional on B + a fresh read confirming no existing runner covers it.
A claim↔test binder (binds a prose claim to an executable check) — likely a true gap, but to be confirmed against the command-catalog/run-ledger first.
The canonical-DOT-denominator contract itself (a contract, not a number) — D.
The canonical reg→FS diff base (41 vs 4) — D.
A generic package_manifest.json + schema, --selftest/module_sha256, audit_dead_links() — proposed in the first plan; each must be re-checked for an existing equivalent before counting as a gap (anti-duplication discipline).

5.4 — May the scope spec begin after this matrix, or still blocked? PARTIAL — conditionally yes. On this matrix's approval, the spec may begin only for the read-only reporting skeleton (a verifier that queries the named surfaces and reports set + timestamp + source + both-direction diff, file-report-only), governed by the now-decidable defaults A/E/F/I/J. The call/execute surface (C), the reconciliation contract (D), the new duplicate/graph work (G), and the corpus consumption (H) remain BLOCKED pending Codex review + the authorized fresh reads. No tool/schema/runner is created by this matrix; "spec may begin" is a recommendation for the owner to approve, not an action taken here.

6. Questions for GPT / User / Codex (only those NOT answerable from the baseline)

(A/D) Canonical denominator contract. Confirm 309 dot_tools = catalog of record (listing = live query, freeze acknowledged). Then designate which surface is canonical for "runnable" (214 operational vs 186 confirmed) and for "actual" (163 actual_count), as a contract — not a single collapsed number.
(D) Canonical reg→FS diff base. v_dot_registry_no_file=41 vs v_dot_reconciliation_reliability.DOT_MISSING_FILE=4 disagree on FS base/match-key. Which is canonical for the reconciliation contract?
(C) Safe-call profile. Is the computed 186-confirmed ∩ command-catalog-governed profile acceptable as the safe-call set, or must execution be restricted further (command-catalog 54 only), or forbidden entirely in v0.1?
(H) TAC↔IU corpus authority. Which is canonical (IU 219 / TAC 102), or is a bridge/compat view required before any tool consumes a corpus? (The tool must not choose by assumption.)
(G) Duplicate/graph authority. Confirm that no new duplicate/orphan/graph resolver may be built until the existing Đ19/Đ23/universal_edges engines are run read-only and a true gap is shown. Authorize those read-only runs.
(B + fresh read) Measurement authority. Authorize a read-only fresh read to settle (a) CAT-006 actual_count=163 filter, (b) direct OS listing of /opt/incomex/dot/bin, (c) the /opt/incomex/scripts "42" surface — or accept the PG mirror (wf_fs_dot_bin_snapshot) as canonical and close these as UNVERIFIED-by-design.
(E) Directus stance. Confirm "no direct Directus mutation until 100% DOT-control proven," or name the approved Directus-DOT tool path that would be permitted instead.
(scope) Spec start. Approve beginning the read-only reporting skeleton spec under defaults A/E/F/I/J, while C/D/G/H remain blocked — or hold all spec work until every domain is sealed.

7. Cross-references

Baseline: reports/dot-registry-directus-text-as-code-baseline-reconciliation-2026-06-09.{md,json}
Codex cross-check: reviews/codex-crosscheck-text-as-code-reuse-audit-2026-06-09.md (10 authority gates — domains here map onto those gates)
Superseded plan: planning/implementation-package-dot-v0-1-feasibility-plan-2026-06-09.md
This draft's checkpoint: checkpoints/checkpoint-authority-decision-matrix-draft-after-baseline-2026-06-09.md
Machine summary: reports/authority-decision-matrix-draft-after-baseline-2026-06-09.json