Frontier Questions · Reusable dossier

One question.
One living evidence spine.

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.

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:

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."
  }]
}

Worked example · composable CRM

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

Evidence map

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.

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