The Great Library of SISO · Canonical operating constitution · 2026-08-02

God Questions infrastructure

A dependency-gated program for making SISO's highest-value questions visible, evidence-connected, assumption-aware, agent-addressable, action-linked, and capable of receiving verified learning—without turning the Great Library into a corpus warehouse, evidence court, execution runtime, or autonomous allocator.

Purpose and outcome contract

God Questions, publicly presented as Frontier Questions, exist to turn consequential uncertainty into better decisions and reusable learning. The infrastructure succeeds when a cold human or agent can reconstruct what is being asked, which decision may change, what assumptions carry the answer, what evidence supports or challenges them, what approved action was attempted, and what verified observation came back.

The system adopts the Frontier Question identity model, question-driven research loop, dossier and CRM example, Ecosystem Intelligence contract, and build-first operating plan. This document reconciles them into one implementation constitution; it does not create a competing registry or portfolio.

Constitutional rules

1. One identity spine. A question is a Work. An accepted answer is an immutable Release. A Snapshot selects the current public view. An Event records operational motion. No dossier database receives parallel identity authority.
2. Owner-held payloads. The Library may preserve public-safe references, hashes, states, summaries, and lineage. Raw corpora, private locators, client material, operational databases, model traces, and rights-bearing payloads remain with their owners.
3. Observation is not truth. An agent response, experiment result, or Observation Receipt is evidence input. Evidence Engines adjudicate claims; the question steward decides answer disposition after the required review.
4. Proposal is not authority. An Epistemic Demand Package or Action Candidate cannot authorize execution. Only a named human or domain owner may approve an immutable, expiring Execution Mandate.
5. Learning proposes change. A Learning Return may challenge assumptions, propose a successor Answer Release, record no change, or reopen a question. It never silently rewrites a Work, Release, routing rule, capability, or public registry record.
6. Assumptions remain attackable. Every load-bearing assumption has an address, falsifier, status, dependency edge, evidence links, and review point. Confidence without a reversal condition is decoration.
7. Automation earns promotion. Repeated manual fields and checks may become validators, tripwires, compilers, or capabilities only after fixtures show decision value, bounded false-positive cost, ownership, rollback, and replay evidence.
8. Old truth stays citable. Corrections use successor records. Accepted Releases, Snapshots, Events, Decisions, and mandates are not rewritten to make a failed path look successful.

Constitutional ownership

One canonical object graph

Mission
  → Frontier Question Work + research contract
    → public-safe program projection
      → Assumption references
      → Evidence connections owned by Foundry / Knowledge / Evidence Engines
      → Typed action-and-learning lineage references
    → Answer Releases (accepted answers only)
    → Whole-Library Snapshot selection

Epistemic Demand Package
  → mutable Action Candidate
  → human/domain approval or rejection
  → immutable expiring Execution Mandate
  → independently owned runtime
  → Observation Receipt
  → Evidence Engine claim candidates and adjudication
  → Learning Return
  → Answer Release | explicit no-change | reopen proposal
  → optional capability-promotion proposal

The public Work projection references this graph; it does not materialize the private payloads or own the execution nodes. Each reference must identify its owner and authority state so an agent cannot confuse discoverability with permission.

Object and interface contracts

The smallest stable first tranche

The first implementation tranche extends the existing research_contract with one optional, separately validated program projection. The shape is now consumed by registry validation, generated Observatory/detail pages, an agent-readable /research.json projection, and contract fixtures. It does not add an API, database, daemon, background agent, dependency, or new record family.

GQ-001, GQ-002, and GQ-009 are the heterogeneous registry fixtures. GQ-009 also records the actual scoped human authorization, mixed independent implementation observation, privacy failure, and no-change Learning Return that drove hardening while keeping the question researching. The composable-CRM dossier remains a synthetic documentation fixture: it tests the full shape without becoming an accepted Work, real mandate, or observed CRM outcome. Any field that does not improve one of these readers or validations is deferred.

Question and answer lifecycle

1. A steward frames or revises the Work's current research contract. captured, scoped, researching, partial, and answered describe question-program state; they do not prove a public Answer Release exists.
2. Evidence owners expose publication-safe references. The program records support and challenge edges; unresolved contradictions remain visible.
3. If reality evidence has material expected information value, the steward emits an Epistemic Demand Package. An Action Candidate may be prepared, rejected, or revised.
4. A named decision owner may issue an expiring mandate. Independent systems execute and a verifier records an Observation Receipt. Expiry, stop, deviation, or rollback is evidence, not embarrassment.
5. Evidence Engines produce claim candidates and an adjudicated evidence package. A Learning Return proposes assumption impact and answer disposition.
6. The steward accepts an Answer Release, records explicit no-change, or reopens the question. The next Snapshot may select the new Release without rewriting prior answers.

Assumption graph and circuit breakers

Assumptions use four levels: GA global, DA domain, QA question, and AA action/ADR. The first tranche validates only the local question projection. Cross-question impact scanning remains a proposed read operation until repeated fixtures establish safe global identity and ownership.

Circuit-breaker rule: a refuted or materially challenged assumption creates an impact proposal over dependent questions, ADRs, experiments, selected answers, and mandate references. It does not automatically mark every dependent conclusion false, cancel execution, or rewrite state. Only the named decision owner may supersede or expire a mandate. Promotion to an automated tripwire requires replay fixtures, bounded false-positive cost, proposal-only behavior, privacy review, and a disable path.

Source alignment and contradiction radar

Existing SISO research is the first candidate source set: GQ-001, GQ-002, GQ-009, the composable-CRM dossier, Foundry inventories, Knowledge material, books, repository research, ADRs, experiments, and operating receipts. These remain owner-held and enter the public projection only through validated, rights-aware, public-safe references. Infrastructure work begins by aligning admitted sources to questions and assumptions, not by commissioning arbitrary broad probes.

Agent addressability and routing

An agent entering through the Observatory must be able to resolve a question by Work ID or GQ label and receive the public-safe frame, state, decision target, assumptions, evidence connections, gaps, watch triggers, selected Release metadata, and action/learning boundary. The first tranche generates this read model from accepted records; it does not launch workers.

The later research-swarm compiler may turn an Epistemic Demand Package into candidate source, refuter, synthesis, experiment, and verification work packages. It remains gated until manual packages reveal stable shared fields, output can be deterministic, least-authority routing is proven, and replay against prior approved mandates shows that compilation never becomes approval.

The later evidence-aware context compiler may assemble only the relevant public or authorized evidence for a task. It remains gated until paired task fixtures show improved correctness, earlier error detection, or lower reconstruction cost after including context-authoring and repair overhead.

Proof-carrying execution and causal lineage

Proof-carrying execution means an approved action remains bound to the question frame, mandate, exact revisions and routes, evaluation plan, observations, verification scope, and returned learning. It does not mean the Library executes work or that a green test proves value.

Causal agent lineage begins as exact, privacy-safe references in Observation Receipts: models, agents, tools, source revisions, interventions, repair, and verified outcome. A causal claim requires a baseline, counterfactual, or other declared method. Mere chronological participation is not causation.

First heterogeneous fixtures and acceptance questions

Dependency waves

Capability genome and promotion

A repeated mechanism may become an independently owned capability only when it has a coherent boundary, steward, provenance, compatible environments, failure modes, evals, rollback, at least one demonstrated reuse case, and a reason for an independent release cadence. Foundry may discover it; a Learning Return may propose it; neither action promotes it.

The mature capability genome may preserve inheritance and competition among verified mechanisms. It must reuse the existing capability-promotion lifecycle and owning Works. It is not a self-modifying production-agent system and not a second marketplace registry.

Observability and authoring economics

Each tranche records machine-verifiable counts and honest qualitative outcomes: fixtures covered, assumptions connected, unresolved references, action/learning chains completed, contradictions visible, generated reader assertions, authoring fields and bytes added, validation time, failures caught, and whether a real decision or answer disposition changed.

Authoring overhead is measured against avoided repeated research, earlier-visible false assumptions, reconstruction time, and decision value. A field with no current consumer, fixture, validator, or generated projection is deleted or deferred. Three-question evidence is a stabilization gate, not proof of universality.

Technical acceptance gates for the first tranche

1. Identity: no new question registry or record family; every program projection belongs to an existing research-question Work.
2. Validation: schemas and cross-reference checks reject duplicate IDs or edges, broken dependency or supersession graphs, unresolved evidence/link references, malformed freshness dates, unsafe locators, skipped action stages, invalid authority transitions, and unowned evidence.
3. Projection: the Research Observatory links this constitution and exposes program coverage; question detail pages render assumptions, evidence connections, action/learning lineage, and selected release maturity.
4. Answer honesty: GQ-009 remains researching; metadata seeds remain distinct from accepted Answer Releases; generated negative assertions prevent inflation.
5. Privacy and rights: records carry only public-safe references, hashes, rights states, and summaries; publication scanning rejects machine-local paths, credentials, private topology, and raw private locators.
6. Cold-reader path: from /research/, a reader can see stewardship, lifecycle, freshness, next useful work, and answer state, then reach the constitution and a question's decision, assumptions, evidence gaps, current release lineage, and action/learning boundary without this conversation.
7. Dogfood: GQ-001 and GQ-002 exercise heterogeneous public/owner-held research; CRM replays the full shape synthetically; GQ-009 records an actual approved scope, mixed PASS/FAIL observation, challenged assumptions, and a no_change Learning Return without an Answer Release.
8. Economics: authoring overhead and generated output are measured; unused flexibility is removed.

Maintainer publication closeout is a subsequent authorized step: after technical acceptance, the owning maintainer runs the full gate, pushes exact commits, adds immutable Release/Snapshot/Event successors, integrates current main under repository controls, deploys, and observes live and GitHub refs. The architecture and its technical fixtures do not grant that authority; the active initiative and repository controls do.

Program falsifiers and kill rules

• The design needs a second question registry, giant schema suite, central Information Organ database, or universal runtime to stay coherent.
• The visible dossier accumulates fields but cannot improve a research, routing, architecture, or investment decision.
• Evidence cannot be connected without exposing private corpora, client data, credentials, machine paths, or operational topology.
• Proposal, approval, observation, adjudication, and accepted answer cannot be mechanically distinguished.
• Authoring and maintenance cost exceeds avoided re-research, reconstruction, or decision error across the fixture cohort.
• Cross-source contradiction or assumption automation creates unbounded false positives or silently broadens authority.
• A compiler, capability, portfolio model, or market is promoted before manual outcomes establish calibration and ownership.

Failure modes and required response

Privacy, rights, and publication boundary

The public surface may carry stable IDs, GQ labels, Work IDs, public URLs, safe owner roles, hashes, dates, rights states, aggregate metrics, explicitly asserted public-safe summaries, and public evidence references. Program free text is scanned for known credential, machine-path, traversal, local-host, and mapped-host forms in addition to repository-wide publication scanning. It must not carry private corpus contents, raw extracts, client facts, identities not cleared for publication, personal notes, credentials, private topology, machine-specific paths, raw logs, model session payloads, or navigable private evidence locators.

A hash proves identity only when the verifier can lawfully access the underlying artifact; it does not make a private artifact public or independently verified. owner_held and rights_review are honest states, not defects to conceal.

GitHub, release, and deployment discipline

1. One active maintainer owns the reserved Library surfaces. Bounded reviewers are read-only unless a non-overlapping reservation explicitly grants edits.
2. Each meaningful tranche is verified, committed, and pushed to the named public branch before the next tranche begins.
3. Generated pages are rebuilt from authored docs and accepted registry records; generated Work pages are never hand-edited.
4. Closeout adds a new Great Library self-Release, a successor Whole Library Snapshot preserving unaffected selections, and a completion Event with exact evidence. Accepted immutable records are never rewritten.
5. Before main integration, fetch current origin, rebase if main moved, inspect reservations, rerun the complete gate, and never force-push.
6. Deployment runs only after canonical main contains the immutable closeout lineage. Final receipts name exact branch/main commits, Release, Snapshot, Event, verification verdict, deployment URL, live observation, remaining hypotheses, and the next gated tranche.

Existing, first tranche, later, and rejected

Next dependency gate

Implement and dogfood W1 only. If its fixtures and generated readers prove that the three-field program projection improves reconstructability without unacceptable overhead or boundary leakage, stabilize it through an immutable Library closeout. If not, simplify or delete it and preserve the failed learning. W2 does not open merely because W1 compiles.