SIGNIT Runbook

Quick-start

The first five minutes

Read state before acting. Start with the system’s current operating posture, confirm the loop-board, check repository integrity, review reachability, then read the latest audit. Never act on a stale surface without re-running the relevant checker.

§ 01

What SIGNIT is

SIGNIT is the assurance-and-control layer around an autonomous research-and-publishing system. It governs whether the system’s outputs are trustworthy, reachable, evidence-bounded, and safe to move through brief-production gates. SIGNIT does not make a claim true by fiat; it proves whether the pipeline has earned the right to use a claim, surface a brief, draft prose, prepare a layout, or pursue publication.

The operating discipline is restraint. Most SIGNIT routines are report-only. Mutating actions — calling external providers, writing the knowledge stores, updating routing state, promoting canonical claims, preparing a handoff, or publishing — are fenced behind explicit gates and, for consequential actions, explicit operator approval.

§ 02

System topology

Two planes matter. A private control plane holds the authoritative source, run outputs, and assurance artifacts — the local control surface from which decisions are made. A redacted state mirror carries a safe subset of operator surfaces for external review. Mirror durability means the safe-state surface exists in the mirror; it does not mean website publication or message delivery.

§ 03

The six operating loops

SIGNIT is organized as six governed control loops. Each carries two separate signals: implementation status (is the machinery built?) and current condition (is its latest proof present?). A loop can be fully implemented and still amber, because the latest proof artifact has not yet arrived.

§ 04

Reading green, amber, and red

Green means the applicable proof is present and clean. Amber usually means the machinery is operational but awaiting a natural run, sidecar, or expected runtime output. Red means a blocked gate, unsafe source drift, test failure, active runtime, or missing required proof that must be resolved before proceeding.

§ 05

What to read first

When something looks off, read the authoritative surfaces in priority order rather than reacting to a single signal.

• Current system state — the system’s operating posture right now.
• Loop board — the condition of each of the six loops.
• Operational reachability — owners, surfaces, and mirror durability.
• Repository integrity — expected runtime output vs. source drift.
• Nightly audit — whether the latest run and audit completed cleanly.
• Brief portfolio — where each brief sits in the lifecycle.
• Graph & routing state — advisory route context and its freshness.
• Operations queue — the current prioritized work.

§ 06

Scheduled work

SIGNIT runs a production pass and a separate assurance pass, plus a set of specialized monitors. The production pass writes state and may call providers; everything else is biased toward report-only and inert modes. Each class of work has an explicit boundary.

§ 07

Graph and routing assurance

Graph and routing data are advisory, not evidentiary. A single authorized post-run path is the only writer for routing apply and graph-assurance reconciliation. Raw graph context must never enter claim evidence; its value belongs only in mediated route-state caveats or constrained allocation layers.

When the graph loop is amber awaiting exact-run sidecars, the watchdog can still report mediated route value while the exact reconciliation inputs have not arrived. The correct recovery is the natural post-run proof — never a manual graph write.

§ 08

Selector allocation and deep-fetch fairness

Selector allocation governs scarce verification capacity. The capped selector prioritizes eligible candidates by priority bucket, evidence strength, source diversity, and deterministic tiebreakers. Deep-fetch budget fairness protects promoted-memory claims from being starved by earlier queues. The budget ledger proves allocation fairness — it is not a provider call, and not a substitute for an actual deep fetch.

§ 09

Brief lifecycle gates

Brief movement is staged, and clearing one gate never clears the next. A controlled draft is not publication. A handoff preview is not delivery. A formatted preview is not layout authorization or website publication. The distinction between assurance (a verdict) and proof (the artifact behind it) holds at every gate.

§ 10

Mirror durability

Mirror durability proves that a redacted operator surface is mapped, present, redaction-safe, and hash-consistent in the mirror. It does not publish a brief. Only safe operator surfaces are mirrored, and only through the generator mechanism; raw databases, secrets, provider payloads, and raw logs are never mirrored. Mirror durability and public release are different states — one is internal readability, the other is an authorized publication action.

§ 11

No-touch principles

The following actions are never taken casually. Each requires the authorized path or explicit operator approval.

• Run providers or models outside the authorized production or review gate.
• Write production stores, promote canonical claims, or mutate finality without explicit approval.
• Write graph state or apply routing updates outside the single authorized path.
• Generate brief draft text from the assurance or audit path.
• Record a final delivery decision without explicit delivery authorization.
• Send messages, deploy website content, or publish without explicit authorization.
• Change schedulers, scheduler contracts, environment configuration, or secrets without explicit operator approval.
• Use broad version-control staging, force-push, or manually copy mirror surfaces outside the generator mechanism.
• Delete, stash, reset, or clean expected runtime dirt merely to make status look clean.

§ 12

Recovery playbook

Most red and amber states have a known, restrained recovery. The recurring principle: distinguish expected runtime dirt from source drift, and let natural runs emit proof rather than forcing writes.

§ 13

Proof artifacts by loop

A loop closes to green only when its proof is present and clean. Each loop has a characteristic set of closing artifacts.

§ 14

Reading debt and watch items

Watch items are not failures. They are states that need interpretation before action. The categories below recur; before treating any of them as a defect, read the current authoritative surface, because later work may have already closed it.

§ 15

Glossary

§ 16

Safe-action principles

Before any consequential action, the operating model favors a small set of habits over improvisation:

• Read before you write. Confirm current state from the authoritative surface; never act on a stale snapshot.
• Prefer read-only and dry-run modes when inspecting, and scope every check as narrowly as the question allows.
• Treat open questions as prompts, not defects — verify them against the current state before concluding anything is broken.
• Let natural runs emit proof. When a loop is amber for want of a sidecar, wait for the run rather than forcing a write.
• Keep mutation on the authorized path — providers, stores, routing, promotion, delivery, and publication each have one, and only one, sanctioned route.