The Great Library of SISO · Research model
Questions are durable.
Answers keep moving.
Frontier Questions is the public name for the standing research portfolio historically called God Questions: high-leverage questions that deserve the widest relevant evidence, explicit reasoning, adversarial testing, and repeated answers as the world changes.
Core decision
A Frontier Question is a Work, not a document folder or a row in a second catalog. Each accepted answer is an immutable Release. A Snapshot selects the current answer while old answers and their evidence remain citable.
A Frontier Question is a Work, not a document folder or a row in a second catalog. Each accepted answer is an immutable Release. A Snapshot selects the current answer while old answers and their evidence remain citable.
Questions serve the SISO mission. The question-driven research architecture defines how sources, claims, assumptions, ADRs, experiments, and refreshes operate; the reusable dossier turns that method into one consistent module per question.
The four independently owned jobs
One question package
| Layer | Contract |
|---|---|
| Identity | Stable Work ID, GQ label, title, question text, steward, and permanent Library URL. |
| Frame | Evidence mode, source systems, Foundry scopes, expected answer shape, known exclusions, and publication boundary. |
| Evidence map | Source locators and content hashes live with their owning corpus or engine. The Library stores citations and receipts, not raw warehouse payloads. |
| Reasoning | Candidate claims, supporting and refuting evidence, witness independence, unresolved contradictions, and killed hypotheses. |
| Answer | An immutable Release with an explicit grade, date, evidence universe, limitations, and falsifiable refresh trigger. |
| Watch | Foundry or another source owner signals material drift; a successor answer is produced without rewriting the earlier Release. |
The research loop
- Frame before search. Separate overloaded questions and pre-register candidate claims or evaluation dimensions.
- Map the evidence universe. Use Foundry categories, resource buckets, people, momentum, and explicit live anchors to define what can bear on the question.
- Acquire by value. Read the highest-information sources first, widen until marginal evidence stops changing the answer, and preserve rights and provenance.
- Reason in claims. Record support, contradiction, independence, uncertainty, and dead ends. Repository popularity is a retrieval prior, never proof.
- Adversarially synthesize. Try to break load-bearing claims, distinguish universal findings from SISO preferences, and state what the evidence cannot answer.
- Release, then watch. Publish the answer and receipts that are safe to publish; trigger a successor when new evidence or a failed prediction materially changes the conclusion.
What does not enter this public repository
Personal questions, private operational data, conversations, raw databases, credentials, private topology, machine-specific paths, and rights-unclear corpora remain outside the public Great Library. A public question may carry public_metadata_only while its private evidence is reviewed. A private question gets no public record until a safe projection exists.
Why this is not a new registry type
The existing Library primitives already express the lifecycle correctly: Work = durable question, Release = immutable answer, Snapshot = current selection, typed relationships = evidence-system responsibilities. The only schema addition is a research contract on Works whose type is research_question.
The initial module boundary
The method, template, and worked examples remain authored Library documentation while Foundry, SISO Knowledge, Evidence Engines, and operating systems perform their independently owned jobs. Promote the method into a separate Work or service only after it gains independent source code, operators, a release cadence, or a corpus lifecycle. This keeps the first version useful without creating a second registry or speculative platform.