TemplatesU7 · Doc readerfrontier-question-template
doc · rendered from docs/frontier-question-template.html · Frontier Questions · Reusable dossier

One question. One living evidence spine.

A reusable Frontier Question dossier template with assumptions, source queues, claims, ADRs, experiments, answer Releases, and a worked CRM architecture example.

00

Abstract

the document's own opening, verbatim

Create one dossier per Frontier Question. The dossier is the operating map; the stable question remains a Library Work, and each accepted answer remains an immutable Release. Large, private, licensed, or operational payloads stay with their owning evidence systems. The registry scaffold below is the public-safe read model, not a second dossier or evidence store.

Template rule: do not fill every field with ceremonial prose. A field exists to change retrieval, reasoning, a decision, or a refresh trigger. Mark unknowns honestly. Link evidence rather than copying entire corpora.
what it is
a template: the fields a Frontier Question dossier carries and a worked composable-CRM example (docs/README.md:19)
sits in
Library docs · mission thread gls:thread:mission-question-architecture (registry event 2026-08-01)
used by
the 17 frontier-question-gq-* Works in registry/works; the last commit dogfooded it on GQ-009
may claim
a structure, not an answer: no Frontier Question is answered by this document
01

Copyable question dossier

FRONTIER QUESTION
ID / public label:
Title:
Exact question:
Why this matters / value path:
Decision owner and steward:
Status: proposed | scoped | active | synthesis | released | watching | challenged
Time horizon:
Public / private boundary:
Expected answer shape:
Refresh triggers:

FRAME
Definitions:
In scope:
Out of scope:
Constraints:
Subquestions:
Success / decision threshold:
Known disagreements:

BASELINE
Current best answer:
Confidence and why:
Candidate answers / hypotheses:
What would reverse the leading view:
Known unknowns:

ASSUMPTION LEDGER
- ID: GA-___ | DA-___ | QA-___ | AA-___
  Statement:
  Scope and status:
  Confidence:
  Evidence for / against:
  Falsifier:
  Depends on / dependents:
  Last reviewed / supersedes:

EVIDENCE UNIVERSE
Foundry scopes and watchlists:
Repositories / code:
People / organizations:
Books:
Papers / official documentation:
Web / community / videos:
Datasets:
SISO systems / experiments / user evidence:
Missing viewpoints and rights constraints:

SOURCE QUEUE
- Source ID / locator / edition or revision:
  Source type and creator:
  Rights / publication boundary:
  Relevance hypothesis:
  Assumption or subquestion targeted:
  Expected information gain:
  Read state and extraction receipt:

CLAIM + CONTRADICTION LEDGER
- Claim ID / atomic statement / type / scope:
  Supporting sources:
  Refuting sources:
  Witness independence:
  Applicability and confidence:
  Unresolved contradiction:

FIRST-PRINCIPLES SYNTHESIS
Irreducible constraints:
Mechanisms and causal model:
Incentives / information flows / feedback loops:
Universal findings vs SISO preferences:
Killed hypotheses and why:
What the evidence cannot establish:

IMPLICATIONS
Assumptions changed:
Capability or stack map changed:
ADRs create / revisit / supersede:
Experiments to run:
No-regret actions:
Actions explicitly not justified:

ANSWER RELEASE
Answer and grade:
Evidence universe and cutoff:
Load-bearing assumptions:
Limitations and contradictions:
Predictions:
Decision / implementation implications:
Successor and superseded answer IDs:
Next watch date / event triggers:
02

Minimal registry scaffold

The authored Work keeps the existing research_contract identity and adds one validated program. Copy only public-safe metadata. Every evidence connection names its owning Work and affirms that its projected summary is safe; every action link declares authority and its immediate predecessor. The generated Research page and /research.json consume this exact state.

"program": {
  "freshness": {
    "assessed_at": "YYYY-MM-DD",
    "review_due_at": "YYYY-MM-DD"
  },
  "next_useful_work": "One ordered, decision-relevant next step.",
  "assumptions": [{
    "id": "QA-QUESTION-ASSUMPTION",
    "level": "QA",
    "scope": "bounded claim scope",
    "statement": "A falsifiable load-bearing belief.",
    "status": "active",
    "confidence": "low",
    "falsifier": "The observation that would overturn it.",
    "depends_on": [],
    "evidence_connection_ids": ["EC-QUESTION-SOURCE"],
    "review_date": "YYYY-MM-DD"
  }],
  "evidence_connections": [{
    "id": "EC-QUESTION-SOURCE",
    "source_type": "documentation",
    "owning_work_id": "gls:work:...",
    "reference": "public-safe locator or opaque receipt",
    "relevance_hypothesis": "Why this source could change the assumption.",
    "rights_state": "public_metadata_only",
    "publication_state": "public_safe_metadata",
    "observed_at": "YYYY-MM-DD",
    "provenance_receipt": "public-safe receipt",
    "revision_or_digest": "stable revision or digest",
    "summary": "Public-safe metadata only; never paste the private payload.",
    "supports_assumption_ids": ["QA-QUESTION-ASSUMPTION"],
    "challenges_assumption_ids": []
  }],
  "action_learning_links": [{
    "id": "AL-QUESTION-DEMAND",
    "object_type": "epistemic_demand",
    "authority_state": "demand_only",
    "owner_role": "question_steward",
    "reference": "public-safe demand receipt",
    "recorded_at": "YYYY-MM-DDThh:mm:ssZ",
    "predecessor_ids": [],
    "related_assumption_ids": ["QA-QUESTION-ASSUMPTION"],
    "status": "proposed",
    "summary": "Requests evidence and grants no approval or execution authority."
  }]
}
Authoring gate: run npm run verify. Validation rejects broken assumption/supersession graphs, unsafe locators, duplicate edges, malformed freshness dates, and action chains that skip demand → candidate → mandate → observation → learning. A research state such as answered still does not create a public Answer Release.
03

Worked example · composable CRM

6 subheadings

This is a framing example, not an accepted Work, product commitment, vendor ranking, or completed answer.

Exact question

What reusable, composable CRM and business-operating-system architecture should SISO adopt so client systems inherit high-value data, grid, document, form, workflow, permissions, integration, reporting, and agent capabilities without rebuilding the same foundations for every engagement?

Why it matters

The decision affects delivery speed, reliability, upgrade cost, client fit, agent usability, licensing risk, and the amount of reusable capability that compounds across projects. The answer is not “find the biggest CRM repository.” It is a reference architecture, capability map, evidence-backed source strategy, and sequence of reversible decisions.

Question-specific assumptions to test

IDCandidate assumptionUseful falsifier
QA-CRM-01A large share of client workflows reuse a stable set of data, relationship, permission, view, form, automation, and audit primitives.Workflow sampling shows the supposedly shared core is small or forces costly exceptions.
QA-CRM-02Adapting modular, appropriately licensed foundations creates more lifetime value than repeatedly generating bespoke foundations.Integration, upgrade, or license cost persistently exceeds verified bespoke delivery and maintenance cost.
QA-CRM-03A flexible data-and-workflow kernel can support vertical capability packs without becoming an unmaintainable universal platform.Two or more representative verticals require incompatible invariants in the proposed kernel.
QA-CRM-04Agents become materially more useful when the system exposes typed actions, permissions, provenance, and reversible audit trails rather than only a user-interface automation layer.Controlled tasks show no meaningful quality, speed, or safety improvement over the simpler interface.
QA-CRM-05Upstream health, interface stability, composability, and rights are stronger selection criteria than feature count or popularity alone.Outcome data demonstrates that simpler popularity/feature signals predict adoption success better.

Evidence map

Executable evidence

Appropriately licensed open-source CRM, database, grid, document, workflow, form, permission, integration, and agent-interface projects; architecture and extension seams; test and upgrade behavior.

Product and market evidence

Publicly observable Notion/Airtable-class workflows, customer jobs, switching costs, ecosystem patterns, and documented interfaces. Product behavior may inform requirements; proprietary source code is not assumed available for reuse.

Book and framework evidence

Question-mapped sources on organizational scaling, modularity, platform economics, operations, and adoption. The user-named Exponential Organizations 2.0 enters as a queued source only after a relevance and rights check.

Reality evidence

Representative client workflow samples, delivery time, change frequency, permission failures, automation reliability, agent task completion, operator feedback, and lifetime maintenance cost.

Subquestions

  • Which capabilities are truly invariant across target engagements, and which belong in vertical packs?
  • What is the smallest stable kernel: data model, relationships, permissions, event log, workflow runtime, views, or something else?
  • Which components must share a transaction/security boundary, and which should remain replaceable services?
  • What extension contracts let agents and humans operate the same system safely?
  • Which source candidates are lawful to reuse, healthy enough to depend on, modular enough to extract, and economical to maintain?
  • When should SISO integrate, extract a capability, contribute upstream, wrap a service, or build an original component?

Expected answer package

  1. A capability graph separating kernel, optional modules, vertical packs, integrations, and agent interfaces.
  2. A source landscape that distinguishes executable code, architectural information, product behavior, and market signal.
  3. A weighted shortlist with license, provenance, extension seams, health, upgrade cost, and evidence receipts.
  4. A reference architecture and ADR set for the smallest reversible composition.
  5. Thin experiments against representative workflows with explicit success and abandonment thresholds.
  6. An Answer Release stating what to reuse, integrate, build, defer, and watch—plus the assumptions that could reopen the decision.

First experiment: choose a small but representative workflow slice, implement it through the proposed kernel and one vertical pack, expose the same typed actions to a human UI and an agent, and measure delivery time, exception count, permission correctness, task success, and upgrade friction. This is more informative than committing to a universal CRM platform from a repository ranking alone.

Read the full research architecture, the Frontier Question identity model, or the SISO mission.

04

Evidence · version

what this page renders, from which bytes; the claim ceiling
fact · has a receiptproposal · not yet
Rendered from docs/frontier-question-template.html, 216 lines, 13,801 bytes, sha256 4612cbf1938e54a846553f6d676e85d7af5734b79063724a73a83eff74687f31.wc -l -c · shasum -a 256 · 6 Sep 20:08 UTC+07
Body taken verbatim between <main> and <footer>, split at its three <h2>s; h3s given ids for the contents column; the doc's own <style> dropped and the shell's tokens applied. No sentence rewritten.templates/U7/example.json chapters[].html
Last commit 781ea9c 2 Aug 2026 02:03 +07 "registry: dogfood GQ-009 learning return"; created at 100f07c 1 Aug 23:01 "docs: add question-driven research architecture"; 68386b8 in between. Repo head 477b775 6 Sep 13:42.git log -- docs/frontier-question-template.html
Author seat: the registry event "Mission and question-driven research architecture published" (1 Aug 23:01:50 +07) names owner Great Library research maintainer, branch codex/mission-question-architecture-20260801, and lists this doc among its changes.registry/events/2026-08-01-mission-question-architecture-completed.json
The live copy at /docs/frontier-question-template returns 200 (the .html path 308s to it) and carries no siso-sidebar: the reason this family exists (templates.json U7 why: "20 docs on the site carry no shell").curl -sL … | grep -c siso-sidebar → 0 · 6 Sep 20:08 UTC+07
The Library build should render every docs/*.html and docs/*.md through this family, with the contents column from headings and this evidence panel from git.not done; the Library pins siso-shell 0.1.0 and has not re-pinned (README Legacy note)
Limits
  • Claim ceiling: the document is a template and a worked example; it establishes no answer to any Frontier Question and the CRM example is illustrative, not a registered Work.
  • No date appears in the document body; the dates here are git commit dates.
  • Markdown docs (library-ui-spec.md and 12 others) need a markdown pass before this reader; this example is an HTML source.
Version
781ea9c
2 Aug 2026 02:03 +07 · Lordsisodia
06

Agent entry

Great_Library_of_SISO/docs/frontier-question-template.html
  1. shasum -a 256 docs/frontier-question-template.html
  2. git log --format='%h %ci %s' -- docs/frontier-question-template.html
  3. bin/compose U7 templates/U7/example.json --out /tmp/U7.html
Agent entry
Read first
Great_Library_of_SISO/docs/frontier-question-template.html
Owner
LIBRARY-ZERO (Library build) · last writeback 6 Sep 13:42 · 477b775
Done when
Open this page and see the grouped rail, a contents column built from the doc's three h2 and six h3, the same heading style as a Work page, and an evidence panel whose sha256 matches `shasum -a 256 docs/frontier-question-template.html`.