# GN3 — Auditor durable context

Durable audit, language, computation, and certification protocol. Exact audit targets remain live Supabase state.

**Scope.** This is a generated, read-only startup snapshot of slow-changing GN3 context. Supabase GN3 is canonical. Read this page only at the beginning of a session: ChatGPT may cache it for the rest of that session. After startup, obtain all updates directly from Supabase GN3 through the GN3 synchronization interface; do not reread this page for freshness. Live guidance, research-tree state, active research, audit queues, failures, removals, and frontier movement are intentionally excluded.

**Transport.** The exporter reads Supabase through revision-pinned GN3 RPCs with a maximum content page of 20,000 characters and verifies every assembled body.

**Auditor live target.** The exact audit target and dependency closure are not compiled into this durable page because they vary by assignment. Use `gn3_startup('auditor', target_id, ...)` for the exact assigned target context.


# Startup

## GN3 startup

_GN3 document: `start001`_

# GN3 startup

GN3 uses the Supabase-backed document tree as its live authority.

Supabase project:
- name: `GN3_RESEARCH`
- ref: `fewmvjslkhoygixiimgn`

The public GitHub Pages surface is a generated, read-only transport for slow-changing role context; it is never canonical and contains no live research state.

## Connector startup rule

Invoke GN3 only through the known project above.

If the Supabase connector rejects an otherwise valid `gn3_*` SQL call at its safety/access layer **before the database executes it**, treat that as a connector-level transient rejection, not as evidence that the SQL, GN3 function, or project is wrong.

Retry the same high-level GN3 call once. If useful, an equivalent PostgreSQL quoting form such as dollar-quoting string arguments is acceptable. Do **not** respond by listing Supabase projects, searching for another project, inspecting backing tables, reconstructing state elsewhere, or changing to a different research source.

If repeated retries fail, report the connector failure explicitly.

## Researcher / Vice Director — preferred fresh startup

Read the appropriate durable role page **in full**:

- Researcher: `https://sircaptaincaleb.github.io/GN3_RESEARCH/researcher.html`
- Vice Director: `https://sircaptaincaleb.github.io/GN3_RESEARCH/vice_director.html`

The page contains the slow-changing startup material: architecture/policies, proof spine, certified CORE/UTILITY shelf material, and toolkit mathematics. Live guidance, the research tree, active research, audit state, failures, removals, and frontier movement are deliberately excluded.

After reading the page, call:

`gn3_sync(role, since_revision := null, cursor := 0, page_chars := 12000, expected_revision := null)`

A null `since_revision` means **fresh live snapshot**. Consume every returned page at the pinned `repository_revision` until `complete=true`. Thereafter continue with:

`gn3_sync(role, last_seen_revision)`

using the last fully consumed repository revision.

If the Pages surface is unavailable, incomplete, or visibly truncated, fall back to the full canonical startup:

`gn3_startup(role, target_id := null, cursor := 0, page_chars := 12000, expected_revision := null)`

and consume every returned page.

## Astra

The durable Astra page is available at:

`https://sircaptaincaleb.github.io/GN3_RESEARCH/astra.html`

It is useful as the slow-changing mathematical/policy context, but Astra still uses the role-aware Supabase startup/live mechanism for its current strategic layer. Until an Astra-specific live-sync interface replaces that step, `gn3_startup('astra', ...)` remains the complete canonical Astra initialization.

## Auditor

The durable Auditor page is available at:

`https://sircaptaincaleb.github.io/GN3_RESEARCH/auditor.html`

The exact audit target and dependency closure are assignment-specific and remain in Supabase. Use `gn3_startup('auditor', target_id, ...)` to obtain that exact live target context.

## Retrieval discipline

The 12,000-character GN3 default is chosen to keep complete JSON responses transport-safe after metadata overhead. The GitHub Pages assembler itself uses revision-pinned `gn3_get_documents` reads capped at 20,000 content characters and verifies every assembled body.

If a high-level response is visibly truncated, retry the same GN3 function with a smaller character budget. Do not reconstruct missing state with raw SQL.

For mathematical documents, synchronization normally delivers the fresh `statement` interface rather than the proof body. Fetch proof bodies only when needed with `gn3_get_document` or `gn3_get_documents`.

Ordinary research uses the generated durable page plus GN3 RPCs, not direct reads of `gn3_documents`, `gn3_dependencies`, `pg_proc`, or other backing tables/catalogs. Raw SQL is for GN3 infrastructure engineering, diagnosis, migration, or administration.


## Fast concurrency path

During an active wave, use gn3_head() for the cheapest "did the world move?" check. Use gn3_direction_delta(last_seen_revision) or gn3_frontier_digest(role) when a full sync would be unnecessary.

For multi-object research publication, prefer gn3_stage_research_bundle(...), optionally mutate the stage with gn3_append_staged_batch(...) or gn3_replace_staged_batch(...), inspect it with gn3_get_staged_batch(...), then commit with gn3_commit_staged_batch(...). Staging does not advance repository revision; commits use object-local conflict checks. gn3_post_research(...) also tolerates unrelated sibling publications while still rejecting semantic conflicts.

Use gn3_help('staging'), gn3_help('search'), or another targeted help topic instead of ingesting full help when only one interface is needed.


# Policies and role protocol

## Connector and retrieval guidance

_GN3 document: `i0000001`_

# Connector and retrieval guidance

**Status: STARTUP MECHANICS.**

This file owns GN3 retrieval and concurrency mechanics. Project topology is in `01_ARCHITECTURE.md`; research behavior in `03_RESEARCH_PROTOCOL.md`; audit/lifecycle semantics in their dedicated policies. `gn3_help()` is the authoritative function/workflow reference.

## Supabase project identity

GN3 uses exactly this Supabase project for live research state:

- name: `GN3_RESEARCH`
- ref: `fewmvjslkhoygixiimgn`

Workers should target this project directly. They should not enumerate Supabase projects merely to rediscover it during ordinary startup.

## Durable role pages

GN3 publishes generated, read-only GitHub Pages containing slow-changing role context:

- Researcher: `https://sircaptaincaleb.github.io/GN3_RESEARCH/researcher.html`
- Vice Director: `https://sircaptaincaleb.github.io/GN3_RESEARCH/vice_director.html`
- Astra: `https://sircaptaincaleb.github.io/GN3_RESEARCH/astra.html`
- Auditor: `https://sircaptaincaleb.github.io/GN3_RESEARCH/auditor.html`

Supabase remains the sole live authority. These pages are compiled transport artifacts, not writable or canonical state. They deliberately exclude current guidance, research-tree state, active research, audit queues, failures, removals, and frontier movement.

For Researcher and Vice Director fresh startup, read the appropriate durable page **in full**, then obtain the complete live layer with:

`gn3_sync(role, since_revision := null, cursor := 0, page_chars := 12000, expected_revision := null)`

Null `since_revision` means a fresh live snapshot. Consume every page before work begins, carrying the returned `repository_revision` as `expected_revision` until `complete=true`.

Thereafter continue with:

`gn3_sync(role, last_seen_revision)`

which returns the revision-pinned live delta plus current guidance/research-tree state and bounded correctness alerts.

If GitHub Pages is unavailable, incomplete, or visibly truncated, use the full canonical fallback:

`gn3_startup(role, target_id := null, cursor := 0, page_chars := 12000, expected_revision := null)`

and consume every returned page.

Astra still uses its role-specific Supabase initialization in addition to any durable page reading. Auditor startup may be called without a target to receive the audit queue; a `target_id` remains available when a narrow dependency-closure startup is useful.

## Connector-level safety rejection

The Supabase connector may occasionally reject an otherwise valid SQL invocation at its own safety/access layer before PostgreSQL executes the query.

For an ordinary high-level GN3 call such as `SELECT * FROM public.gn3_startup(...)` or another `gn3_*` RPC, such a rejection is **not evidence that the GN3 function, SQL, or project identity is wrong**.

Recovery rule:

1. retry the same high-level call once against project ref `fewmvjslkhoygixiimgn`;
2. if useful, retry with an equivalent PostgreSQL quoting form, such as dollar-quoted string arguments;
3. do not enumerate projects, search for another project, inspect backing tables, substitute Slack/GitHub state, or redesign the access path;
4. if the retry still fails, report the connector-layer failure explicitly.

Do not turn a transient connector rejection into research-state reconstruction.

## Transport safety

GN3's 12,000-character default is chosen so the complete JSON response remains transport-safe after metadata overhead. The external Pages assembler uses revision-pinned `gn3_get_documents` reads capped at 20,000 content characters and verifies each reconstructed body before publishing.

If a GN3 response is visibly truncated, retry the **same high-level function** with a smaller `page_chars` or `part_chars`. Do not recover by querying backing tables.

When using the Supabase connector, send **one SQL query per connector request**. Do not concatenate multiple SQL statements with semicolons and expect them to execute as an ordered multi-query transaction or return independent usable results; connector behavior does not support that workflow reliably. If several GN3 operations are logically one transition, use the appropriate GN3 batch function. Otherwise issue separate connector requests, carrying the returned repository revision forward.

Likewise, do not batch several large paginated GN3 reads into one connector request merely to save calls. A single GN3 page can be transport-safe while the combined outer connector response becomes truncated. Consume large pages one request at a time.

## Normal reads

Use the narrowest read after synchronization:

- `gn3_get_document()` — one exact known document, including paginated body;
- `gn3_get_documents()` — several exact documents in one revision-pinned, character-paginated read; request `statement` or `body`;
- `gn3_search()` — genuine discovery;
- `gn3_get_subtree()` — a known tree location;
- `gn3_current_strategy()`, `gn3_current_guidance()`, `gn3_frontier()`, `gn3_active_research()`, `gn3_live_research_since()` — specialized state views;
- `gn3_needs_audit()`, `gn3_uncertified()` — certification work;
- `gn3_notices(role, ...)` — active/resolved worker-facing notices when a dedicated notice read is useful; normal startup/sync already delivers relevant notices;
- `gn3_changes_since()` — rawer revision-journal synchronization.

Follow returned cursors until `complete=true` whenever completeness matters.

**Ordinary workers must not query `gn3_documents`, `gn3_dependencies`, `pg_proc`, or other GN3 backing tables/catalogs directly for research state.** Do not enumerate documents manually, reproduce search with `LIKE`, inspect function definitions to rediscover signatures, or read statements/bodies/audit state by table query. Use `gn3_help()` and the GN3 RPCs.

Direct table/catalog SQL is reserved for GN3 infrastructure development, diagnosis, migration, or backend administration.

## Revision coherence and writes

Revision pinning remains the default for coherent paged reads and ordinary small writes. If a revision-pinned write races unrelated repository activity, synchronize before retrying.

For large or multi-object writes, prefer transient staging rather than resending the payload.

### General staged batches

`gn3_stage_batch(operations_json, ttl_minutes)` uploads an entire ordinary GN3 operation batch once. Staging does **not** advance the repository revision. It records object-local concurrency tokens for every existing document the transaction touches, including that document's outgoing dependency set.

Inspect with `gn3_get_staged_batch(stage_id)`; discard with `gn3_discard_staged_batch(stage_id)`.

Commit with the small call `gn3_commit_staged_batch(stage_id)`.

- The commit does not require an expected global repository revision.
- Unrelated research/audit writes do not invalidate the stage.
- The complete staged batch commits atomically with one GN3 revision.
- If a touched document changed after staging, the commit fails safely and the staged payload remains available; inspect the conflict and reconcile without resending the large batch.

Stages expire automatically; the default TTL is six hours and callers may request 5–1440 minutes.

Use ordinary `gn3_apply_batch(expected_revision, operations_json)` when the payload is small and immediate. Use staged batches when the transaction is large, expensive to reconstruct, or likely to race concurrent work.

### Audit-specific staged batches

Audit uses a stricter snapshot-first variant because certification may depend on documents that are not themselves being edited.

1. `gn3_audit_snapshot(target_ids, extra_watch_ids, expected_revision)` captures object-local tokens for each target, every current direct dependency, and any explicitly watched additional premise at the pinned read revision.
2. The Auditor performs proof review without changing GN3 state and accumulates intended repair/certification operations.
3. `gn3_stage_audit_batch(operations, snapshot)` accepts those operations only if every watched object still matches the pre-audit snapshot. Staging itself does not advance the repository revision.
4. `gn3_verify_audit_batch(stage_id)` reports any object-local conflicts.
5. `gn3_commit_audit_batch(stage_id)` atomically rechecks the same baselines under the revision lock and applies the full batch in one GN3 revision.

Therefore unrelated concurrent work may freely advance the global repository revision while an audit is underway. Only a change to the audited target or a watched premise invalidates that audit. A staged audit that conflicts remains available for inspection/reconciliation.

Audit staging also packages worker-facing consequences automatically. FAIL operations, localized repairs followed by certification, and Auditor-authored mathematical revisions left uncertified generate first-class `notice` objects in the same atomic commit. An Auditor may put a concise human explanation in a target operation's optional `notice` field; otherwise GN3 emits a mechanical summary of the changed surfaces/disposition.

### Staged single-body convenience

`gn3_stage_body`, `gn3_get_staged_body`, `gn3_commit_staged_body`, and `gn3_discard_staged_body` remain as a lightweight convenience for one large body replacement. General staged batches subsume this case when several related changes belong together.

Do not perform SQL-side read-modify-write editing against backing tables. Retrieve through GN3, construct the intended content explicitly, then use ordinary or staged GN3 write APIs.

## Live team research

Publish active mathematical work with `gn3_post_research(..., statement)`. The optional statement is the compact claim teammates receive by default; the body contains proof/supporting detail.

For Researcher/Vice Director, fresh `gn3_sync(role, null)` supplies all current active research statements together with current strategy, current guidance, the research tree, audit state, frontier state, and active worker notices. Numeric `since_revision` supplies ongoing changes. Astra may use `gn3_sync('astra', snapshot_revision)` for a delta after the Astra hot-shelf snapshot. `gn3_live_research_since()` remains available as the narrower research-only feed.

## Legacy and retrieval failure

Supabase GN3 is the live authority. GitHub repository content and Slack are provenance/archaeology only; the generated GitHub Pages role views are the sole exception and are read-only compiled projections of Supabase.

If required current material cannot be retrieved completely and coherently through the durable page plus GN3 live interfaces, treat that as a retrieval/interface problem to diagnose. Do not silently substitute fragments, legacy state, or ad hoc SQL reconstruction.


## Concurrency fast path

The preferred high-concurrency interfaces are intentionally narrow:

- gn3_head() returns repository revision, current strategy/guidance, operational wave status, and small queue counts.
- gn3_direction_delta(since_revision, role) reports whether strategy, guidance, or operational status changed and returns compact changed-research/notices.
- gn3_frontier_digest(role) returns a compact current frontier: newest certified, pending/contingent, recent failed results with failure fingerprints, active moonshots, and notices.
- gn3_search_math(...) is statement/title-weighted mathematical search with certified-only, current-guidance, and subtree filters.
- gn3_help(topic) provides targeted help such as staging, search, writes, or a documented gn3_* function name.

gn3_sync and gn3_startup now avoid repeating the large state envelope on continuation pages. If a complete stream is modest (at most 28,000 content characters), the first request may automatically expand to one transport-safe page. The response includes transport.recommended_page_chars. Larger reads remain revision-pinned: carry the returned repository_revision as expected_revision.

General staged batches are **mutable before commit**. Use gn3_append_staged_batch to add operations or gn3_replace_staged_batch to replace the staged source transaction. gn3_get_staged_batch exposes the actual staged source operations, watches, conflicts, timestamps, and readiness. Existing watched objects retain their original concurrency baselines; newly introduced objects acquire baselines when added. Dependency targets are watched as semantic premises. Audit stages may also be mutated, but only within the original audit snapshot watch-set.

For ordinary research, use gn3_stage_research_bundle to stage theorem/proof body, statement, dependencies, and metadata together. gn3_post_research_bundle is the immediate convenience form. Ordinary gn3_post_research and bundle publication distinguish semantic conflicts from unrelated repository churn: stale revisions caused only by unrelated sibling activity may publish optimistically, while changes to strategy/guidance, the research tree, or explicit premises still force synchronization.

For a failed result, gn3_stage_research_repair stages body + statement + dependencies + metadata patch + reopening to pending as one object-local transaction. The immediate gn3_repair_research form performs the same logical repair in one revision.

GN3 does not currently keep long-lived server-side read sessions. Large paged reads therefore remain explicitly revision-pinned rather than silently mixing worlds. Prefer the compact head/delta/digest interfaces when exact reconstruction of a large live stream is unnecessary.

## 01 — GN3 architecture

_GN3 document: `i0000002`_

# 01 — GN3 architecture

**Status: CANONICAL.**

This file owns GN3 topology, authority, mathematical surfaces, and lifecycle. Other numbered policies own language, research method, audit, computation, terminology, and document form.

## Roles

GN3 separates four functions:

- **Astra** — scarce strategic Director: theorem-level abstraction, route selection, high-level probes, moonshots, and an explicit strategy assignment on every activation—either affirming the current strategy epoch or issuing a new one when the conceptual map changes.
- **Vice Director** — global coherence of the live project: reconcile parallel research, compare competing syntheses and abstractions, compress the strongest justified mathematical picture, maintain the current strategy epoch, current guidance wave, Astra hot shelf, and research tree, select audits, compose durable mathematics, and keep live state coherent.
- **Researchers** — full mathematical research cycles under current strategy and guidance: assess the live position, make an opening moonshot before local proof search, attack mathematics, publish useful intermediate results continuously, synthesize, pursue conceptual ascent, re-synthesize/compress, perform minor self-maintenance, then revisit and revise or replace the moonshot before selecting the next local attack.
- **Auditors** — independent checking and repair of exact assigned mathematics.

Detailed Astra and Auditor behavior lives in `ASTRA.md` and `AUDITOR.md`. Researcher and Vice Director receive the same mathematical startup context; their difference is responsibility, not hidden mathematics.

Synthesis, conceptual ascent, abstraction proposal, and moonshotting are **team-wide mathematical responsibilities**, not services reserved to the Vice Director or Astra. Researchers should perform them in parallel from their local mathematical vantage and publish nontrivial outputs into live research as they arise. The Vice Director's unique responsibility is to compare those parallel interpretations globally: resolve incompatibilities, identify dominance and genuine parent structure, decide what becomes part of the project's coordinating abstraction model, and keep project surfaces compressed and mutually consistent.

## Authority and namespace

Supabase GN3 is the sole live authority. GitHub and Slack are historical provenance only.

Workers interact with that authority through the GN3 RPC interface supplied by startup/help. Backing Postgres tables are implementation detail, not a normal research API; direct SQL table reads/writes are reserved for infrastructure work, diagnosis, migration, or administration.

The durable namespace is:

- `PROOF_SPINE/` — the sequential canonical proof;
- `SHELVES/CORE/` — certified theorem-quality material plausibly destined for the proof spine;
- `SHELVES/UTILITY/` — certified reusable mathematics plausibly destined for the toolkit;
- `SHELVES/HOT/` — provisional strategic delta for Astra; not certification-bearing. The Astra hot shelf carries a `snapshot_revision` so Astra can delta-sync only newer live changes;
- `TOOLKIT/` — final reusable mathematics; its README is the statement-level startup index;
- `RESEARCH_TREE` — the live mathematical abstraction/coordinating layer, spanning useful levels from the global theorem down to concrete local targets;
- active/retained research documents — working mathematics and explicit strategic/abstraction proposals;
- current strategy — the unique higher-level strategic epoch: conceptual model, global route decomposition, and major strategic pressure points;
- current guidance — the unique tactical team-thrust wave inside the current strategy epoch;
- `NOTICES/` — compact live coordination alerts. Individual notice objects have `doc_type='notice'`; active notices are delivered to their intended worker roles, and resolved notices remain queryable until normal pruning/trash;
- `ARCHAEOLOGY/` — historical recovery and provenance, never current authority.


## Search and retrieval

Use `gn3_search` for genuine discovery. Search separates matching, ordering, and returned projection:

- match modes `strict`, `conjunctive`, and `disjunctive` mean respectively one literal case-sensitive phrase, every whitespace-delimited term, and at least one whitespace-delimited term;
- legacy `substring`, `exact`, `title`, and `fts` modes remain available;
- order `oldest` and `newest` use document `updated_at`; `relevance` orders by `sum_i sqrt(x_i)`, where `x_i` is the literal occurrence count of search term `i` in title plus body;
- projection `statement` returns only document ID and the document's statement column, avoiding body retrieval.

Candidate matching is indexed before relevance scoring. Relevance scoring is bounded by candidate count rather than document-text length; there is no text-length cap. Use `p_under_id` to narrow discovery to a subtree when appropriate. Ordinary exact-document reads still use `gn3_get_document` or `gn3_get_documents`, not search.

All GN3 pagination is stateless. The server must not persist cursor objects, cached result sets, pagination sessions, or continuation snapshots. A cursor is only a scalar continuation token supplied again by the caller, and each page is recomputed from canonical state. For multi-page reads, carry the returned `repository_revision` forward as `p_expected_revision`; if the repository changes, the next page must fail rather than continue against a different state.

## Mathematical status

Mathematical meaning is classified independently of document lifecycle and audit state through `mathematical_status`:

- `proved` — an asserted mathematical result;
- `conjecture` — a precise open mathematical claim;
- `proposal` — a research route, abstraction, mechanism, moonshot, or other idea not asserted as proved;
- `evidence` — a counterexample, construction, computation, obstruction, or other evidentiary mathematical object.

Nonmathematical documents use no mathematical status. This field is orthogonal to `status` and `audit_status`. Changing it changes the audit fingerprint. Titles and prose labels must not substitute for this field when distinguishing proved mathematics from conjectural or proposed mathematics.

## Mathematical documents: statement and body

A mathematical document may carry a nullable `statement` separate from its full `body`.

The statement is the compact mathematical interface: definitions/hypotheses/conclusions needed to know what was proved. The body contains proof, derivation, computation, examples, or supporting detail. Startup, dependency context, and peer-research feeds prefer a fresh statement; exact body retrieval is on demand.

A statement is trusted as fresh only when its recorded source-body hash matches the current body hash. Mathematical interface changes participate in audit invalidation. Do not treat the statement as an informal summary: it must state the actual mathematics.

## Durable mathematical surfaces

The proof spine and toolkit are final canonical destinations. CORE and UTILITY are certified staging surfaces.

A shelf candidate must itself be independently audited; certified ingredients do not automatically certify a rewritten composition. Shelf documents are organized by mathematical topic/proof coordinate, not worker, guidance wave, discovery order, or result number.

CORE should contain coherent proto-proof sections. UTILITY should contain independently reusable mathematical units. Both are mathematics only: no workflow commentary, provenance narrative, or audit ledger. HOT is the intentional exception because it is a temporary strategic handoff surface.

Structural synthesis, conceptual ascent, audit, shelf admission, and final placement are distinct operations: synthesis determines how results fit; ascent seeks stronger explanations or better abstractions; audit verifies exact mathematics; shelves preserve stable audited material; final promotion waits for the mathematical role to settle.

## Research tree

The research tree is the project's **big-picture mathematical coordination layer**. It is not merely a task list or progress outline.

It should represent the live understanding of the problem at multiple useful abstraction granularities. It may contain the global theorem, major reductions, intermediate abstraction statements, candidate parent lemmas, conjectural mechanisms, obstruction formulations, competing conceptual decompositions, and concrete local targets.

Research-tree nodes are not automatically certified mathematics. The tree must distinguish established facts from proposals, conjectural abstractions, and open targets.

Researchers propose useful abstraction statements through live research. The Vice Director integrates the proposals that genuinely clarify or coordinate the search, decides their placement and relationships, removes dominated or obsolete abstractions, and maintains the tree as a coherent explanation of the big picture.

The tree should answer both:

- what concrete problems are currently being attacked; and
- what the team currently thinks those problems **mean**, at each useful level of abstraction.

It is deliberately lossy and may be rewritten aggressively as understanding changes. Durable mathematics should live in canonical/toolkit/shelf/research documents, not be preserved merely because an old abstraction once appeared in the tree.

## Generated durable context

GitHub Pages is a generated, read-only delivery surface for slow-changing role context assembled from Supabase GN3. It is not canonical state and is never edited as an independent source of truth.

Role pages may contain durable startup policy, proof-spine material, toolkit mathematics, and certified CORE/UTILITY material. They deliberately exclude live guidance, research-tree state, active research, audit queues, failures, removals, and frontier movement; those remain live Supabase state and are synchronized through GN3 RPCs.

The **Vice Director owns publication of these generated durable-context views**. After completing a meaningful durable update affecting startup context, architecture/protocol, proof spine, toolkit, CORE, or UTILITY, the Vice Director should trigger the `Publish GN3 role context` GitHub Actions workflow. Several related durable edits should normally be integrated and published with one rebuild rather than triggering a rebuild after every small edit.

Publishing does not change authority: the workflow reads current revision-pinned GN3 content, assembles the role pages, and overwrites the current Pages deployment. No historical page snapshots are required. Live research changes alone do not require a Pages rebuild.

## Live state and lifecycle

Current operational state is represented directly in Supabase:

- exactly one live strategy document should have status `current`;
- exactly one live guidance document should have status `current`; guidance waves may change several times within one strategy epoch;
- research status `active` means current search;
- `retained` means deliberately preserved but non-active;
- trash is reversible curation;
- audit status `failed` means known invalid as stated. Failed research automatically leaves the active surface and becomes `retained`; reopening a repaired failed research document with `gn3_mark_pending()` reactivates it;
- notice status `active` means the alert still deserves worker attention; `resolved` means its consequence has been absorbed. Notices are nonmathematical and use `audit_status='not_required'`.

Keep `retained` small. Do not create shadow archival statuses such as old/superseded/retracted. Superseded working research must not remain `active`: retain it only when it still has deliberate reference value, otherwise redirect any needed dependents and trash it. Historically valuable material belongs in archaeology; obsolete working noise belongs in trash.

## Dependencies, trust, and deletion

Live dependencies point only to live documents. Proof-support dependencies among mathematics/research/proof documents are acyclic.

Certification is local to the checked mathematical interface. A changed direct premise invalidates the direct certified dependent; GN3 does not recursively hash the entire theorem DAG. Thus a downstream theorem can remain locally certified while the full chain through an upstream pending node is not certified.

Trash is blocked when an outside live document still depends on the selected subtree. Redirect, absorb, or retain the dependency first. Hard purge is irreversible inside Supabase because the change journal stores no historical bodies; normal curation is therefore trash first and purge only in a later deliberate pass. Same-pass purge is for disposable tests, failed imports, or confirmed exact duplicates.

## Governing shape

Discovery may be expansive; durable GN3 state must be compressive.

Do not duplicate state into parallel status files, audit ledgers, changelogs, or provenance layers. Notices are the narrow exception for ephemeral coordination: they point workers at a consequential change but never replace the target document's audit state, exact mathematics, guidance, research tree, or revision journal. The proof spine records the proved/open sequential argument; the research tree records the live abstraction hierarchy and coordinating big picture; guidance records the current directive; active research carries concurrent mathematical findings and strategic proposals; document audit fields record certification; the revision journal records continuity.

Researchers publish useful mathematics and proposals continuously. The Vice Director continuously reconciles them, removes obsolete machinery, composes surviving mathematics, and keeps these surfaces mutually consistent.

## 02 — Mathematical language and proof coding

_GN3 document: `i0000003`_

# 02 — Mathematical language and proof coding

**Status: CANONICAL.**

This file owns the language standard for current GN3 mathematics.

## Intrinsic mathematical language

State mathematics in terms of the objects and relations themselves, not discovery history or proof-management vocabulary. A reader should not need Slack, Git history, result numbers, prior guidance, or neighboring prose to know what a theorem means.

Prefer standard graph/hypergraph language and explicit descriptions. Project-coined vocabulary is allowed only when registered in `06_TERMINOLOGY.md`.

## Mathematical compilability

Every load-bearing statement must:

- bind the ambient object and every symbol;
- state all mathematical hypotheses actually used;
- type induced subtournaments, paths, covers, deletions, sets, and maps correctly;
- give the exact conclusion proved;
- distinguish existence from construction and retained properties from properties of a newly produced object;
- preserve any downstream-relevant orientation, endpoint, witness, disjointness, order, maximality, or recurrence condition.

Dependencies explain why a fact is available; they do not replace the hypotheses or definitions needed to parse the statement.

## No hidden provenance or reachability

Do not encode mathematical content by phrases such as accepted case, current branch, inherited configuration, earlier engine, surviving route, or reachable state unless those words have an intrinsic mathematical definition in the statement.

A sequence of proof transformations is not automatically a mathematical object. If reachability, descent, or recurrence is load-bearing, define the state space and relation explicitly.

## Strengthening and factorization

Test natural strengthenings and simpler parent lemmas. Prefer a genuinely stronger useful theorem when it follows cleanly, but do not hide unresolved work inside an ambitious abstraction.

Factor repeated arguments through natural reusable lemmas when that improves proof topology. Inline one-use machinery. Simplification must remove complexity, not merely rename or relocate it.

New strengthenings or materially new proofs are new mathematics and require audit before certification.

## Finite checks

A load-bearing finite case analysis must be checkable from the text through a conceptual argument, an explicit bounded table, a compact certificate, or a precisely cited earlier result. Avoid unexplained phrases such as one checks.

Computation follows `05_COMPUTATION_DISCIPLINE.md`.

## Canonical proof form

Canonical exposition is sequential, mathematical, and self-contained up to explicit canonical inputs. Provenance, migration history, obsolete GN3/A7C3 identifiers, audit history, and discovery transcript stay outside the proof.

Open implications are stated as gaps or research targets. They must never be disguised as theorem output, bookkeeping state, or inherited status.

## 04 — GN3 shared certification interface

_GN3 document: `i0000005`_

# 04 — GN3 shared certification interface

This file contains the certification rules every role must understand. Detailed Auditor procedure is in `AUDITOR.md`.

## Mathematical status versus certification

`mathematical_status` and `audit_status` answer different questions. The former says what kind of mathematical object the document is; the latter records verification state of its exact interface.

- `proved` — asserted result and ordinarily audit-bearing;
- `evidence` — exact mathematical evidence and ordinarily audit-bearing when load-bearing;
- `conjecture` — open claim, not a proved result;
- `proposal` — unproved research mechanism or route.

The ordinary `gn3_needs_audit()` queue contains only `proved` and `evidence` documents. Conjectures and proposals may still be inspected explicitly, but certification of their wording or supporting premises must never be represented as proof of the conjectural or proposed conclusion. Changing `mathematical_status` changes the audit fingerprint.

## Scope and independence

Research may use provisional mathematics optimistically. Certification attaches only to the exact mathematical interface independently checked, identified by document ID and audit fingerprint at a repository revision.

The original author may explain or revise a result but may not self-certify it. The Vice Director selects what is load-bearing enough to audit; there is no requirement to audit every research result or clear a chronological backlog. Auditors may nevertheless take one target, several targets, or the entire current audit queue in one working pass.

## Dispositions

Use these dispositions:

- **PASS** — exact target certified.
- **PASS_ADJUSTED** — localized repair/qualification was required and the Auditor checked the repaired exact text without introducing substantive new mathematics.
- **REVISION REQUIRED** — not certified as written, including substantial Auditor-authored repair awaiting independent verification.
- **FAIL** — known false/invalid as stated; persist with `gn3_fail(..., reason)`, not merely `pending`.

Use certified mathematics only at the exact audited strength.

## Repair and second audit

Repair is part of audit. An Auditor may certify a localized repair that does not introduce a new proof idea or materially change the theorem.

A substantial Auditor-authored mathematical repair requires a second independent Auditor. Until that passes, the target remains uncertified.

A failed target may be edited while failed. Failed research is automatically `retained`, so it no longer appears as active work. Once a repaired candidate is complete enough to audit, reopen it with `gn3_mark_pending()`; this reactivates failed research and a failed document cannot be certified directly.

The localized/substantial distinction is mathematical, not a line-count rule.

## Supabase audit state

Authoritative certification lives on the target document: audit status, audit fingerprint, audited fingerprint, and dependencies. Optional audit records preserve useful reasoning but are not a second ledger.

The audit fingerprint tracks the mathematical body, any fresh statement interface, audit-relevant metadata, and direct dependency signature. Mathematical interface changes invalidate stale direct certification automatically. Ordinary provenance/lifecycle metadata does not by itself create new mathematics.

Certification is local rather than a recursive whole-DAG hash. A theorem can remain locally certified while an upstream dependency chain contains a pending node; the full chain is then not certified through that node.

## Shelf and canonical admission

A rewritten or merged mathematical exposition requires audit of that exact composition even when all ingredients were previously certified. Nothing mathematical enters CORE or UTILITY until the exact candidate has PASS or PASS_ADJUSTED.

A byte-for-byte move creates no new mathematical obligation. A mathematical edit to shelf or canonical text does.

## Role responsibilities

The Vice Director selects audit targets, supplies enough context, tracks load-bearing certification, and propagates failures/material weakenings into live strategy.

Researchers may continue while audits run and may use provisional mathematics, clearly marked as such.

Auditors independently check exact mathematics and repair when possible. Substantive repairs require a second Auditor as above.

Retention, trash, restore, and purge follow the lifecycle rules in `01_ARCHITECTURE.md`.


## Worker-facing audit notices

Audit consequences that materially change what teammates should trust are packaged as first-class `notice` objects rather than buried in an audit transcript.

`gn3_stage_audit_batch` automatically appends a notice, in the **same atomic audit commit**, when a target is failed, when a localized repair is certified as PASS_ADJUSTED, or when an Auditor changes mathematical content but leaves the new fingerprint uncertified/REVISION REQUIRED. Pure PASS creates no notice.

For a useful human explanation, add an optional `notice` field to any staged operation for that target. GN3 otherwise supplies a concise mechanical summary of the disposition and changed surfaces. The target document remains the authority for certification; the notice is only a worker-facing alert.

Researchers, Vice Director, and Astra receive relevant active notices through normal startup/sync. The Vice Director should resolve a notice once its consequence has been absorbed into guidance, dependencies, research-tree/shelf state, or otherwise no longer needs active attention. Resolved notices may later be pruned/trash-curated normally.

## Multi-target and batch auditing

Auditor startup without a `target_id` returns the current audit queue. An Auditor may choose one, several, or all queued targets. Targeted startup remains optional when a particular target's dependency closure is useful.

Use `gn3_get_documents(ids, 'body', ...)` to retrieve several exact proof bodies together when that is the efficient unit of work.

Auditors do **not** use ordinary direct write batching as the normal certification path. Before checking a coherent batch, capture `gn3_audit_snapshot(target_ids, extra_watch_ids, expected_revision)`. Audit against that exact target/premise snapshot, accumulate all outcomes, then stage them with `gn3_stage_audit_batch(operations, snapshot)`.

After staging, call `gn3_verify_audit_batch(stage_id)`; if it reports `ready_to_commit=true`, finish with `gn3_commit_audit_batch(stage_id)`. The commit is atomic and rechecks every watched object under the canonical revision lock.

This deliberately separates **audit work** from **repository commit**:

- unrelated repository revisions do not invalidate a staged audit;
- target or watched-dependency changes do invalidate it;
- the read-to-stage race is closed because staging must match the earlier audit snapshot;
- the verify-to-commit race is closed because commit rechecks the same baselines;
- localized repairs and certifications that belong together may commit in one repository revision;
- each certification/failure remains an independent mathematical judgment even when several are committed together.

If a staged operation introduces a dependency not present in the snapshot, take a new snapshot including that dependency before staging. An Auditor is not required to process the queue chronologically or one document per session.

## 05 — GN3 computation discipline

_GN3 document: `i0000006`_

# 05 — GN3 computation discipline

**Status: CANONICAL.**

GN3 is proof-first. MILP, SAT, SMT, CP-SAT, exhaustive enumeration, and similar tools are auxiliary methods for sharply bounded finite questions, not default research modes.

## Admission gate

Before a substantial computation, require all four:

1. **Exact question.** The finite feasibility/optimization/classification question and the mathematical inference from each possible outcome are already clear.
2. **Deliberately small instance.** There is strong reason to expect one bounded run to resolve cleanly; rough variable/constraint/search scale is understood.
3. **Compact output.** The needed result is a status, small witness/counterexample, optimum/count, or compact certificate—not a large transcript.
4. **Cheap failure.** If the run stalls, the worker can immediately return to mathematical search.

If any condition is doubtful, reduce the problem or reason mathematically first.

## Solver use

Use MILP for transparent small feasibility/extremal encodings; prefer feasibility, preprocessing, fixed parameters, and symmetry reduction over large raw formulations.

Use SAT/SMT/CP-SAT for small exact consistency questions with immediately interpretable variables. Avoid broad solution enumeration, repeated blocking loops, giant symmetry-unreduced searches, or opaque models.

A stalled first sensible formulation is evidence to shrink the mathematical question, not an invitation to spend the research cycle tuning the solver.

## Output and stop rules

Choose an output budget before execution. Suppress progress logs, traces, full assignments, generated matrices, exhaustive solution lists, and diagnostics unless a tiny excerpt is specifically needed.

Aggregate internally; output only the mathematical payload.

Stop when resource/search growth becomes surprising, interpretation needs a large dump, repeated reformulation becomes solver engineering rather than mathematics, or the computation no longer has a clear path to the live theorem/obstruction/counterexample.

Do not let sunk effort monopolize the task.

## Team concurrency

Normally at most one worker should pursue a solver-heavy version of the same subproblem unless guidance explicitly makes the finite computation a shared primary target. Other workers should continue independent proof-first routes.

Publish useful compact conclusions quickly. If the computational route stalls, report only the concise null information that matters and relinquish it.

## Durable computational evidence

Retain only what makes the inference intelligible and reproducible when needed:

- the exact finite question;
- mathematical meaning of variables/constraints when relevant;
- enough scale to show the check was bounded;
- compact output/witness/certificate;
- the mathematical conclusion;
- code only when future verification or reuse is genuinely valuable.

Raw logs, giant models, search traces, and large generated tables are not durable mathematics. A computational result that cannot be reduced to a small checkable payload may guide exploration but should not become a hidden load-bearing proof dependency.

Use computation to collapse uncertainty, not create more state for the team to inspect.

## 06 — GN3 terminology registry

_GN3 document: `i0000007`_

# 06 — GN3 terminology registry

This is the authority for project-coined mathematical terminology. Standard mathematical language and locally defined symbols need no registration.

## Rule

A project-coined term is reusable English shorthand whose GN3 meaning is not its ordinary established mathematical meaning.

**If such a term is not approved here, do not use it as established vocabulary; spell out the mathematics instead.**

A proposed term should name a recurring intrinsic object/relation for which standard terminology or a short descriptive phrase is materially worse. Approval requires an explicit definition and revision of this registry.

## Approved GN3 vocabulary

- **boundary tournament**, **tight triple/path/cycle**, **path cover**, **exact q-path cover** — canonical proof-spine definitions;
- **endpoint transfer** — canonical longest-path definition;
- **source path**, **left-extended path**, **right-extended path**, **oppositely extended pair** — canonical fixed-pair definitions;
- **continuation sequence**, **continuation reduction** — only their exact proof-spine definitions;
- **matching blocks**, `M_low`, `M_mid`, `M_high` — the ordered opposite-edge matchings in the non-Hamiltonian edge-ordered four-vertex classification;
- **comparison digraph** — only for an explicitly defined comparison graph as in the small-order machinery.

The list is intentionally short. A useful theorem does not need a nickname.

## Forbidden project shorthand

Do not repurpose the following as GN3-specific mathematical labels:

`core`, `four-core`, `endpoint core`, `fan`, `fiber`, `splice/splicing`, `turn`, `signature`, `profile`, `seam`, `rail`, `gate`, `packet`, `carrier`, `cell`, `bridge`, `face`, `quiet gap`, or `surgery`.

Their established mathematical meanings remain allowed. Otherwise state the object or operation explicitly: name the vertex set, ordered triple, path, partition, family, cut, concatenation, replacement, or deletion actually meant.

Legacy filenames may retain old words; that does not authorize them in current statements/proofs.

## Enforcement

Legacy Slack/GitHub/archaeology vocabulary does not override this registry.

When unapproved shorthand appears in current mathematics, rewrite it into explicit standard language without changing the content and without inventing a replacement nickname.

Auditors check terminology compliance. Directors and the Vice Director should remove discovery-time shorthand during synthesis. When unsure whether a phrase is standard or project-coined, prefer the explicit mathematical description.

## 07 — GN3 communication and document standard

_GN3 document: `i0000008`_

# 07 — GN3 communication and document standard

**Status: CANONICAL.**

This file owns the shape of live GN3 documents. Language rules are in `02_MATHEMATICAL_LANGUAGE.md`; lifecycle in `01_ARCHITECTURE.md`; certification in `04_AUDIT_PROTOCOL.md`.

## Research documents

A mathematical research document should use its nullable `statement` field for the exact standalone claim and its body for proof, derivation, bounded computation, examples, or supporting detail.

The statement must bind its ambient object, local objects, hypotheses, and conclusion. It is not an informal summary. Strategic interpretation and provenance belong in the body after the mathematics or in metadata.

Publish precise intermediate results early enough to unblock teammates. Live sharing does not confer certification.

## Mathematical formatting

Use Markdown backticks for inline mathematical expressions and symbols whenever practical, for example `pc(K)<=2`, `V(H)-S`, or `(a,s,c)`. This is the preferred GN3 transport-safe notation.

Avoid relying on LaTeX backslash commands in text sent through connector/SQL/tool layers. Backslashes may be interpreted or stripped before the document reaches GN3, producing malformed mathematics even when the intended LaTeX was correct. Use plain intrinsic notation inside backticks unless a richer mathematical display is genuinely needed and the transport path is known to preserve it exactly.

Every explicit proof block headed `## Proof` must end with the proof-ending square `∎`. This is part of the GN3 document form, not optional typography. It also lets statement/body projection and validation recognize where the proof block ends.

## Guidance documents

Current guidance should state, compactly:

- the common mathematical target;
- strongest relevant certified/provisional base;
- exact current obstruction;
- useful negative evidence/fences;
- highest-value attacks and moonshots;
- routes to defer.

Exactly one guidance document is current. Replace guidance atomically rather than maintaining a parallel hand-written history.

## Notice documents

A `notice` is a compact live coordination object under `NOTICES/`. Use it when workers need to see a consequential operational or mathematical-state change without duplicating the underlying authoritative state.

A notice body should say what changed, which target(s) it concerns, and what workers should do differently. Metadata carries at least `kind`, `severity`, `target_ids`, and `audience`. Active notices are delivered through startup/sync; resolve them after the consequence has been absorbed. Do not use notices as a second audit ledger, changelog, proof store, or guidance system.

Audit FAIL, PASS_ADJUSTED, and REVISION REQUIRED outcomes are generated automatically by staged audit commits. Auditors should add a concise optional `notice` field to the relevant staged target operation when the mechanical summary would not adequately explain the mathematical consequence.

## Audit and continuity

Certification belongs to the target document's audit fields/fingerprint, not prose wrappers or a second audit ledger. Detailed audit records are optional supporting material.

The GN3 revision journal is the continuity stream. It records operations and changed IDs, not historical body snapshots. Do not maintain a duplicate changelog.

## Corrections

When the same mathematical object is repaired, edit the existing live document rather than creating a competing canonical copy.

- editorial/localized repairs follow the audit rules;
- substantive mathematical change requires fresh certification;
- known false mathematics is first marked with `gn3_fail()`;
- a repaired failed candidate is reopened with `gn3_mark_pending()` only when ready for audit;
- if the surviving theorem is materially different, create a new document;
- obsolete material is redirected/absorbed and then trashed under the architecture lifecycle rules.

Substantial Auditor-authored mathematical repairs require a second independent Auditor.

## Concurrency

Work from a known repository revision for coherent reads. Ordinary non-audit writes may use revision-pinned GN3 operations, `gn3_apply_batch()`, or the general staged-batch API when several changes must form one coherent transition.

Audit is different: proof review must use `gn3_audit_snapshot(...)` followed by `gn3_stage_audit_batch(...)`, `gn3_verify_audit_batch(...)`, and `gn3_commit_audit_batch(...)`. This makes certification conflict on the audited objects and premises actually relied on rather than on unrelated global repository activity.

Teammates normally consume research statements through the live feed and fetch full proof bodies only when needed.

## Pre-write check

Before making mathematics load-bearing, verify:

1. the statement is standalone and all symbols/hypotheses are bound;
2. the conclusion has exactly the proved strength;
3. language and typing satisfy `02_MATHEMATICAL_LANGUAGE.md`;
4. actual nonlocal premises are represented by dependency edges;
5. provisional and certified inputs are not conflated;
6. the change updates the natural existing document rather than creating duplicate canon;
7. every `## Proof` block ends with `∎`;
8. mathematical notation is transport-safe, preferring backticks/plain intrinsic notation over fragile LaTeX backslash commands.

## Durable promotion and dependencies

Discovery may be broad; durable mathematics should be compressed.

Certified proof-route mathematics is composed into coherent CORE candidates; reusable mathematics into UTILITY candidates. The exact composition must itself pass audit before shelf admission. Final proof-spine/toolkit promotion waits for stable mathematical placement.

Live mathematical dependencies must point to live documents and proof-support dependency cycles are forbidden. Deletion, retention, trash, and purge semantics are owned by `01_ARCHITECTURE.md`.

Supabase GN3 is the only live surface; Slack and GitHub may remain provenance but are not needed to understand current mathematics or state.

## Auditor — independent certification protocol

_GN3 document: `i0000010`_

# Auditor — independent certification protocol

**Status: ROLE-SPECIFIC.**

This file is read by Auditors. Researchers do not need it. The shared certification interface is summarized in `04_AUDIT_PROTOCOL.md`; this file contains the detailed operating rules for independent audit and repair.

## Mission

Audit the exact mathematics assigned, aggressively and independently. Check correctness, hidden assumptions, typing, completeness, dependency validity, index ranges, path orientations, support partitions, and compliance with `02_MATHEMATICAL_LANGUAGE.md`, `06_TERMINOLOGY.md`, and `07_COMMUNICATION_STANDARD.md`.

Certify only the exact current text that actually passes. Audit is not passive fault-finding: repair is part of the job when the intended mathematics is clear.

## Assignment and scope

The Vice Director selects load-bearing targets. There is no chronological audit backlog and no obligation to inspect unrelated research.

An audit batch may contain several related document IDs so definitions and dependencies can be reused efficiently. One independent Auditor normally owns one coherent batch; certification remains itemwise.

The Auditor must be independent of the incoming mathematics. Read the exact target document at one repository revision, its explicit dependency edges and exact prerequisite mathematics, and only enough surrounding context to type the statement correctly.

## Exact certification identity

For a live GN3 target, certification identity is:
- document ID;
- current body/metadata/dependency-derived audit fingerprint;
- repository revision at which that fingerprint was checked.

Agreement, recency, repeated use, or historical Git/Slack placement does not certify mathematics.

Use these dispositions:
- **PASS**
- **PASS_ADJUSTED**
- **REVISION REQUIRED**
- **FAIL** — false or invalid as stated; record the exact target with `gn3_fail(..., reason)`.

If only a cleanly separable substatement survives, certify that substatement explicitly rather than implying partial certification of a larger target.

## Repair

A **localized repair** may fix presentation, typing, local scope, explicit dependencies, a locally omitted case, or another defect that introduces no new proof idea and does not materially change the theorem. The same Auditor may make and verify it and return PASS_ADJUSTED.

A repair is **substantial** when it changes mathematical scope/content, introduces a new proof idea, fills a genuinely nonlocal gap, or replaces the argument by materially different mathematics. The first Auditor should still attempt a useful repair, but must leave the changed target uncertified/REVISION REQUIRED. A second independent Auditor then checks the new fingerprint.

When a previously trusted target is actually false, record FAIL **before** overwriting its body. A repair of the same theorem may then be drafted while the document remains failed. Once the repaired candidate is complete, reopen it with `gn3_mark_pending()`; if the Auditor authored a substantial repair, a second independent Auditor is still required. If only a materially different/weaker theorem survives, create a separate target rather than silently rewriting the failed theorem into a new claim.

The size of the textual edit is irrelevant.

## Dependencies

Check each target together with its explicit GN3 dependency edges and the exact hypotheses actually consumed.

If batch item B depends on batch item A, audit them in a mathematically sensible order. If a target depends on an uncertified document outside the batch, the local implication may be checked conditionally, but that does not certify the upstream document or full chain. This local/interface convention is deliberate: a direct premise statement or failure-marker change invalidates the direct certified dependent, but certification is not recursively revoked through unchanged intermediate theorem statements.

Do not silently promote provisional dependencies to certified facts.

## Shelf and canonical candidates

A mathematical document may enter `SHELVES/CORE/` or `SHELVES/UTILITY/` only after an independent Auditor certifies the **exact composed candidate**. Certified ingredients do not automatically certify a rewritten composition, changed dependency order, connective argument, or merged exposition.

A mathematical change to an admitted shelf or canonical proof text requires audit of the changed fingerprint as required by the destination. Pure relocation without changing body, metadata affecting mathematics, or dependencies does not create new mathematical content.

## Computation during audit

Audit the mathematical claim, not a wall of machine output. Isolate the exact finite question and verify it with the smallest independently checkable calculation or certificate available. Prefer direct evaluation, a bounded table, or a concise reproducible script. If verification begins producing large low-information output, reduce the check rather than widening it.

Raw output volume is not evidence.

## Worker-facing notices

Do not separately create ad hoc audit posts for failures or repairs. The staged audit API automatically creates first-class `notice` objects for FAIL, PASS_ADJUSTED, and Auditor-authored revisions that remain uncertified. These notices commit atomically with the audit outcome and are delivered to Researchers, Vice Director, and Astra through normal startup/sync.

When a failure or adjustment has a non-obvious mathematical consequence, include a concise optional `notice` field on any staged operation for that target. State what changed and what downstream workers must no longer assume (or may now rely on). Pure PASS requires no notice. The notice is an alert only; certification authority remains on the exact target document/fingerprint.

## Supabase audit procedure

Auditing uses a two-phase object-local concurrency protocol. **Do not make direct audit writes while proof review is in progress.** Unrelated repository revisions must not invalidate completed audit work, while changes to an audited target or a premise actually relied on must prevent stale certification.

1. Fresh audit initialization may call `gn3_startup('auditor')` to receive the queue, or `gn3_startup('auditor', target_id)` when a target's dependency closure is useful. Consume every required page at one pinned repository revision.
2. Before proof review, call `gn3_audit_snapshot(target_ids, extra_watch_ids, expected_revision)`. The snapshot records object-local concurrency tokens for every target, its current direct dependencies, and any additional documents whose exact contents the audit will rely on.
3. Read the exact target bodies/statements and prerequisite mathematics against that pinned revision. The global revision identifies the coherent read snapshot; the object-local snapshot determines whether the eventual audit result is still valid.
4. Check the mathematics independently and accumulate the intended audit operations in memory: localized body/statement repairs, dependency changes, mathematical-status changes, FAIL/PENDING transitions, and certifications. Do not apply them yet. For a failure/adjustment whose consequence is not obvious, attach a concise `notice` field to one of that target's operations.
5. If the target is false or invalid as stated, the staged operation sequence must record FAIL before any repair rewrite. A repaired failed candidate remains failed during drafting and is reopened with `mark_pending` only when ready for audit.
6. A localized repair may be included in the same staged audit batch and followed by certification after the Auditor has checked the exact repaired text. A substantial Auditor-authored repair must remain uncertified and require a second independent Auditor.
7. Stage the complete result with the snapshot-aware `gn3_stage_audit_batch(operations, snapshot)`. Staging does not advance the repository revision. It rejects if any target or watched premise changed between the audit snapshot and staging.
8. Call `gn3_verify_audit_batch(stage_id)`. If `ready_to_commit=true`, commit atomically with `gn3_commit_audit_batch(stage_id)`. The commit rechecks the same object-local baselines while holding the canonical revision lock.
9. Unrelated research, guidance, or other audit commits may advance the global repository revision between snapshot, verification, and commit without invalidating the audit. A change to any watched object causes a conflict instead; the staged batch remains available so only the affected audit context must be reread/reconciled.
10. If an operation introduces a new dependency, that dependency must already be present in the audit snapshot. Take a new snapshot including it rather than silently certifying against an unobserved premise.
11. Record concise detailed audit reasoning in a dedicated audit document or target metadata only when it is useful for future verification; do not build a transcript ledger.

The final audit record identifies each target document, its disposition, and the exact audited fingerprint. The repository revision at initial read remains useful provenance, but certification validity after concurrent unrelated writes is governed by the watched object-local baselines.

## Research during audit

Researchers do not stop while audit runs. They may continue using provisional mathematics optimistically. Audit is not a project-wide synchronization barrier.

If an audit fails, weakens, or materially repairs a load-bearing statement, the Vice Director—not the Auditor—propagates the consequence through current guidance, dependencies, the research tree, shelves, and canonical candidates.

The Auditor's role ends at exact verification, repair, certification state, and a clear record where needed.