# Master Index Thread Opening Operational Clarification v1.0

Status: ACTIVE OPERATIONAL CLARIFICATION; REPOSITORY-SETTLED WHEN
COMMITTED; NOT CONSTITUTIONAL AMENDMENT.

Purpose:
Prevent newly opened Master Index threads from advancing materially
before their Conversation Procedural Record, Working Procedural
Companion, and Open-Ended Whatnots companion exist.

## I. Authority And Scope

This clarification extends existing operational practice. It does not
create a new constitutional object and does not amend QCEP.

Nearest absorbed machinery:

- Existing CPR and working-procedural-companion pattern in
  `docs/archaeology/`.
- OEW establishment-design pass:
  `docs/archaeology/mi-6.4.4.1a-oew-establishment-design-pass-20260904.md`.
- Ordinary thread closure operational discipline in
  `docs/operations/ordinary-thread-closure-operational-clarification-v0.2.md`.
- Codex SOP for Master Index hook behavior in
  `docs/operations/codex-sop.md`.
- Governance hook declaration in
  `docs/operations/governance-hook-declaration.md`.
- MAS-001 in
  `governance/registers/mutating-authority-surfaces.md`.
- Master Index validation through `tools/validate-master-index.js`.

This clarification authorizes the reusable thread-opening helper,
templates, validator, and operator instruction identified below. It
does not authorize final deposition, thread closure, governance
amendment beyond this procedural opening rule, implementation beyond
the thread-opening mechanism, publication, deployment, corpus mutation,
database mutation, or resolution of unrelated active surfaces.

## II. Operating Rule

Every newly declared Master Index thread must, before substantive
corridor work proceeds:

1. verify repository baseline and worktree state;
2. search for that thread's CPR, working companion, and OEW companion;
3. instantiate all three immediately if absent;
4. record the thread-opening state;
5. report their exact paths and lifecycle state;
6. maintain them through the life of the thread;
7. checkpoint them during extended or materially divergent work;
8. perform the standing OEW procedural check for sufficiently
   substantive operations;
9. finalize and deposit them only at actual thread closure.

The procedural trinity must remain DRAFT AND IN-PROGRESS while the
thread is open. Checkpoint commits make the records repository-
retrievable as active-thread records; they do not constitute final
deposition, closure, final settlement, or completion.

OEW is mandatory for every newly opened Master Index corridor. It is
mandatory because unresolved continuity is an enduring project
condition, not an exceptional occurrence that must first be rediscovered
before a custody surface is created. An OEW file containing zero entries
is valid only when the applicable parent, predecessor, CPR, WPC, and
explicit carry-forward sources have been reviewed and support that
zero-entry state.

## III. Canonical Paths

The canonical active-thread paths are derived from the Master Index
identifier:

- CPR:
  `docs/archaeology/mi-<identifier-slug>-conversation-procedural-record.md`
- Working companion:
  `docs/archaeology/mi-<identifier-slug>-working-procedural-companion.md`
- OEW:
  `docs/archaeology/mi-<identifier-slug>-open-ended-whatnots.md`

The identifier slug is lowercase, prefixed with `mi-`, and removes
parentheses while preserving dots. Example:

- Master Index `6.3.8(b)`
- CPR:
  `docs/archaeology/mi-6.3.8b-conversation-procedural-record.md`
- Working companion:
  `docs/archaeology/mi-6.3.8b-working-procedural-companion.md`
- OEW:
  `docs/archaeology/mi-6.3.8b-open-ended-whatnots.md`

## IV. Minimum Opening-State Content

The CPR, companion, and OEW must initially record:

- Master Index identifier;
- thread title;
- opening timestamp;
- repository HEAD;
- remote alignment status;
- worktree state;
- inherited operational state;
- immediate objective;
- active dependencies;
- known unresolved surfaces;
- current authorized scope;
- excluded scope;
- CPR lifecycle state;
- companion lifecycle state;
- OEW lifecycle state;
- thread state: OPEN;
- repository-settlement state;
- final-deposition state;
- statement that future updates remain expected.

OEW entries, when admitted, must preserve identifier, status, title,
opening date, opening corridor, custodian, custody class, category,
statement, non-blocking rationale, origin/provenance, evidence links,
scope boundaries, related surfaces, affected corridors, review triggers,
current handling, updates, disposition authority, and closure or carry-
forward record.

When an active Master Index thread is used as the steward surface for a
daily release boundary, the WPC is the primary inventory surface. The
WPC may contain a fenced
`quasantum-master-index-daily-release-inventory/v1` JSON block recording
the named daily thread set, terminal source evidence list, and proposed
closure-admitted set. This block is operational inventory only; it does
not duplicate CPR custody, does not create an OEW item, and does not
authorize closure, publication, deployment, evidence settlement,
scheduling, morning-report generation, GrokBot authority, or project-
specific CPR/WPC/OEW requirements. Every governed working thread
actually touched during the day belongs to the required daily set and
must satisfy the terminal release gate. Exclusion support is reserved
only for surfaces that existing repository semantics place genuinely
outside the governed touched-thread set; it is not an ordinary escape
hatch from the daily clean-slate equality contract.

For the one-time supervised Full-Estate Normalization Pilot only, the
daily inventory may distinguish `admission_basis: "touched"` from
`admission_basis: "pilot_exception"`. The release gate operates over
the admitted set: touched governed threads union explicitly steward-
authorized pilot-exception threads. A pilot exception must be marked as
non-precedential, must not be represented as touched today, and must
satisfy the same terminal-source and closure-admission equality
requirements. This distinction does not create ordinary future O-night
scope policy and cannot be used to omit or downgrade a touched governed
thread.

## V. Mechanism

Canonical templates:

- `docs/operations/templates/master-index-thread-cpr-template.md`
- `docs/operations/templates/master-index-thread-working-companion-template.md`
- `docs/operations/templates/master-index-thread-oew-template.md`

Deterministic opening helper:

- `tools/open_master_index_thread.py`

Validator:

- `tools/validate_master_index_thread_records.py`

Read-only daily release inventory preflight:

- `tools/validate_daily_release_inventory.js`

The helper must:

- accept a Master Index identifier;
- accept an optional thread title;
- derive canonical filenames and paths;
- verify repository baseline;
- search for existing CPR, companion, and OEW;
- create only missing artifacts;
- preserve existing substantive content;
- never silently overwrite;
- be idempotent;
- support dry-run mode;
- report all actions;
- distinguish created, already present, stale, malformed, missing
  required opening fields, and lifecycle overstatement through helper
  output and validator output;
- never claim repository settlement merely because files were created;
- never claim final deposition or closure.

The validator must detect at minimum:

- missing CPR;
- missing companion;
- missing OEW when strict trinity validation is requested;
- mismatched Master Index identifier;
- mismatched filename;
- mismatched title;
- missing repository baseline;
- missing opening timestamp;
- missing thread state;
- missing lifecycle state;
- invalid OEW status;
- duplicate OEW entry identifier;
- missing required OEW provenance or scope field;
- unsupported OEW closure, disposition, or carry-forward without
  repository evidence;
- missing dependency statement;
- unsupported settlement claim;
- unsupported closure claim;
- stale or materially incomplete active-thread record.

The daily release inventory preflight must be read-only and fail closed.
It may report `RELEASED` only when the steward-named daily thread set,
the valid terminally released source set, and the closure-admitted set
are exactly equal. It must report `NOT_RELEASED` for absent release
declaration, missing terminal source, source validation failure,
intermediate/nonterminal share URL, extra released source, extra closure
admission, duplicate or ambiguous thread identity, or unresolved project
identity where identity is required.

## VI. Operator Instruction

Immediately after David opens and names a new Master Index thread, use:

```powershell
py tools/open_master_index_thread.py "6.3.8(c)" --title "THREAD TITLE"
```

Replace `6.3.8(c)` and `THREAD TITLE` with the newly declared Master
Index identifier and title. Substantive work begins only after Codex
reports the CPR, companion, and OEW paths and lifecycle state.

## VII. Checkpoint Behavior

For long-running or materially divergent threads, checkpoint the CPR,
companion, and OEW with ordinary git commits. Each checkpoint must
preserve:

- thread remains OPEN;
- CPR remains DRAFT AND IN-PROGRESS;
- companion remains DRAFT AND IN-PROGRESS;
- OEW remains DRAFT AND IN-PROGRESS;
- final deposition not performed;
- later revision expected.

Checkpoint settlement must not be represented as thread closure.

Every sufficiently substantive Codex operation must include the
lightweight closing inquiry: "Did this work create, resolve, materially
alter, or supply new evidence relevant to any Open-Ended Whatnot?" If
yes, perform authorized OEW maintenance or surface the matter for
adjudicative review where authority is required. If no, do not
manufacture an entry; record the negative result only where an
applicable procedural record or operation report calls for it.

## VIII. Current-Thread Provenance

Master Index 6.3.8(b) is the motivating observed case.

Direct repository inspection found that:

- its CPR and companion were absent at thread opening;
- substantial work occurred before instantiation;
- the omission was later corrected by placing draft, in-progress
  active-thread records into `docs/archaeology/`;
- the Multiplicity result was preserved separately as non-authoritative
  source custody.

This mechanism exists to prevent recurrence. It does not rewrite
history to imply that the mechanism governed Master Index 6.3.8(b) from
its opening.

## IX. Settlement And Non-Effects

Repository settlement of this clarification, templates, helper, and
validator makes the thread-opening mechanism independently retrievable
and usable. It does not close any active Master Index thread.

Historical Master Index corridors opened before OEW establishment are
not retroactively required to gain OEW companions merely because this
clarification changed. The validator preserves compatibility with those
records unless strict OEW validation is requested or an OEW file exists.

Non-effects:

- no final deposition;
- no thread closure;
- no governance amendment;
- no corpus mutation;
- no database mutation;
- no publication;
- no deployment;
- no unrelated active-corridor modification.

DOCUMENT END