The Great Library of SISO · Luna drafting pass · 2026-08-01

100 Million Token Operating Plan

A build-first execution layer for the already-published fifteen-part program. It turns the portfolio into bounded waves, named responsibilities, evidence gates, and reversible work packages while consuming the canonical Frontier Questions architecture rather than recreating it.

Purpose and non-duplication rule

The source thesis in The 100 Million Token Program remains the portfolio definition. This page adds the minimum execution structure needed to approve a first slice: dependency waves, scoped-truth prerequisites, owner/organ, resource class, deliverable, evidence gate, parallelization class, and stop condition for every program.

Operating rule: the plan is a projection over existing contracts. It must not create a second registry, a new Frontier Question schema, a central Information Organ database, a replacement evidence warehouse, or a private-source intake path. If an implementation needs a new durable identity or release boundary, it must first be proposed through the owning contract and accepted outside this page.

Build-first orientation

The portfolio is not a study of whether the Great Library is useful. Its purpose is to make SISO's public agent ecosystem materially larger, easier to adopt, easier to extend, and easier for agents to navigate without re-deriving where source belongs. Evaluation remains a correctness, safety, portability, and promotion gate; it is not a prerequisite to begin obvious public-safe improvements.

System boundary

Canonical contracts this plan adopts

These five authored documents are normative inputs to the operating plan. The plan adds no competing definitions:

The operating loop

The loop below is the required relationship between mission, God Questions, evidence systems, decisions, and portfolio investment. It is intentionally a flow of contracts and receipts, not a new data model.

Mission value
  → Frontier Question Work + canonical dossier
  → Foundry source universe and watchlist
  → SISO Knowledge provenance/retrieval + Evidence Engines claims/counter-evidence
  → assumption dependency graph + ADRs + reversible experiments
  → graded Answer Release + watch trigger
  → approved program investment and measured operating outcome
  → outcome receipt challenges assumptions and informs the next question/release

The Great Library records safe identity, lineage, decision, Release, Snapshot, Event, and receipt projections at the public boundary. It does not ingest the underlying corpus or operational database merely because the loop references them.

Minimal scoped-truth prerequisites

Complete ecosystem truth is continuous scoped evidence, not a blocking total census. A wave may open when the following minimum slice is clear for its own work package:

1. Named scope: one public Work family, source cohort, question, interface, or task bank slice; no claim of exhaustive coverage.
2. Identity baseline: the current Whole Library Snapshot and relevant Work, Release, Assembly, Event, or Decision references are resolved.
3. Ownership: one accountable organ and one reviewer are named; external ownership is preserved.
4. Boundary classification: material is classified as public/permitted, external upstream, private/internal, legacy, or unknown. Unknown or private material stops the lane.
5. Evidence contract: the package states what observation would count as success, failure, or a reason to reopen the question.
6. Recovery: the work has a reversible change path, an evidence location in the owning system, and a rollback/retirement rule.

Dependency graph and parallel waves

The portfolio is parallel by design. The edges below describe minimum evidence dependencies, not a serial queue and not a claim that any package is approved.

W0 approval + safety baseline
  ├─ P1 bounded ecosystem truth slice ─┐
  ├─ P6 evaluation seed bank ──────────┼─→ W1 evidence/control lanes
  ├─ P12 privacy, security, recovery ──┘
  └─ P14 adversarial review (baseline)

W1 evidence/control lanes
  ├─ P2 Library read front door ───────────┐
  ├─ P3 cross-repository intelligence ─────┤
  ├─ P5 Foundry discovery pilot ───────────┼─→ W2 operational pilots
  ├─ P8 interoperable Information Organ ───┤
  └─ P14 continuous refutation ────────────┘

W2 operational pilots
  ├─ P4 one-clone Agent Stack ──────┐
  ├─ P7 executable lessons ─────────┤
  ├─ P9 living Frontier Questions ──┼─→ P10/P11 improvement loops
  ├─ P10 duplication/drift ─────────┤
  └─ P11 maintenance proposals ─────┘

W3 bounded externalization
  ├─ P13 outside-user distribution (after P4 evidence)
  └─ P15 strange bets (after P6/P12/P14 gates)

Continuous horizontals: P1 (truth coverage), P6 (evaluation), P12 (safety/recovery), and P14 (adversarial review) never become permanently “done.” They publish scoped receipts and refresh triggers instead.

Fifteen-program execution matrix

Every row is a PROPOSED · UNAPPROVED work package. “Owner/organ” names the accountable responsibility, not a new organizational boundary. “Gate” means evidence required before the package may claim its deliverable. “Resource” uses the classes defined below; “Class” is the parallelization class: F foundation, P parallel, S successor-dependent, or X bounded exploration.

Resource classes and scheduling rules

The classes below are planning abstractions, not grants of access or a claim that capacity is available. An operator must set the actual budget, duration, and approved targets in each initiative Event.

• One accountable owner and one independent reviewer per package; one active writer for a shared public contract at a time.
• Every parallel lane declares a machine-neutral scope and reservation in its Event thread; no two lanes produce the same named artifact.
• Indicative portfolio budgeting may reserve the largest shares for truth/control, evidence/evaluation/safety, and operationalization, with a small capped exploration slice. Percentages are not approval until an operator sets them.
• Token count, agent count, and document volume are inputs. Success is measured by value, correctness, risk removed, reusable capability, and decision quality.

Four states that must not be conflated

Evidence and exit gates

1. G0 · proposal gate: the package states mission fit, decision owner, minimal scoped truth, intended value, resource class, evidence gate, and stop condition. It remains proposed until approved.
2. G1 · boundary gate: sources and outputs are classified; private, credential-bearing, client-identifying, machine-specific, rights-unclear, or unknown material is excluded or held outside the public surface.
3. G2 · execution gate: the operator approves the scope; the lane publishes an immutable initiative_started Event with branch/reservation information suitable for public records and no local topology.
4. G3 · evidence gate: the result is replayable or inspectable, names its cutoff and limitations, distinguishes support from contradiction, and survives the required independent review.
5. G4 · outcome gate: the work changes a measured task outcome, assumption, ADR, capability boundary, or watch decision enough to justify its cost. “More tokens” is not an outcome.
6. G5 · promotion/publication gate: only the owning repository and Library contract may publish a Release, Snapshot, Assembly, Event, or Decision. An authored plan never promotes itself.
7. G6 · exit gate: close with exact evidence and next action, or record blocked, killed, corrected, or retired status. Preserve immutable history; do not rewrite a failed attempt into success.

Immediate build sequence

The user has approved the build-first direction. Each concrete lane still opens through the owning repository's coordination contract, uses public-safe bounded scope, and closes with exact evidence. The sequence below favors shipped capability and source coverage over measuring whether the overall idea is worthwhile.

Authority boundary: public read-only discovery and reversible improvements to SISO-owned public repositories may begin through normal repository controls. New accounts, private-source access, rights-unclear copying, destructive migration, paid resource commitments, silent automation, and production policy changes require separate authority.

Failure, kill, and rollback rules

• Rights/privacy kill: stop immediately on credentials, personal or client-identifying data, private topology, unclassified legacy material, or unclear redistribution rights. Preserve only a non-sensitive blocker receipt.
• Scope kill: pause when a package needs a second named artifact, an unreserved path, an unapproved source universe, or a new registry/warehouse/schema. Return to G0.
• Evidence kill: do not promote a claim when its source receipt, witness independence, cutoff, or replay path is missing; record uncertainty instead.
• Outcome kill: retire a package when the pre-set decision threshold is missed, the next evidence has lower value than acting, or two bounded passes do not change a decision, assumption, or measurable outcome.
• Safety kill: pause dependent lanes after a material scan, threat, restore, or adversarial failure. Resume only after a reviewed correction and fresh evidence.
• Automation kill: autonomous maintenance and adapters may propose but never silently mutate production or public truth. Disable them when false positives, unbounded cost, or rollback failure exceeds the approved threshold.
• Portfolio kill: remove an unapproved package from the next wave without rewriting the source thesis. A killed proposal is a valid portfolio decision, not a failed Library Release.

Later Sol-review checklist

Acceptance is deferred. A later review should use this checklist and require evidence, not agreement with the prose:

Next build queue

1. Close this operating-plan lane, publish the accepted build-first direction, and open non-overlapping implementation Events.
2. Improve the public Agent Stack Distribution's outsider-facing release and community surface without changing component ownership.
3. Run the first checkpointed Foundry public-repository campaign and publish only reviewed, rights-aware candidate metadata through the Library contract.
4. Connect the Stack, its components, external upstreams, source inventories, and promotion queue through the existing generated human and machine surfaces.
5. Promote the first small capability cohort into owning repositories, then repeat discovery, review, release, and Stack-pinning as a continuous loop.

The operating direction does not grant access to private sources or authorize storage migration. Concrete changes still require the owning repository's accepted branch, verification, release, and publication contracts.