Appropriately licensed open-source CRM, database, grid, document, workflow, form, permission, integration, and agent-interface projects; architecture and extension seams; test and upgrade behavior.
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.
Abstract
the document's own opening, verbatimCreate 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.
- 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
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."
}]
}
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.Worked example · composable CRM
6 subheadingsThis 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
| ID | Candidate assumption | Useful falsifier |
|---|---|---|
| QA-CRM-01 | A 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-02 | Adapting 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-03 | A 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-04 | Agents 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-05 | Upstream 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
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.
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.
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
- A capability graph separating kernel, optional modules, vertical packs, integrations, and agent interfaces.
- A source landscape that distinguishes executable code, architectural information, product behavior, and market signal.
- A weighted shortlist with license, provenance, extension seams, health, upgrade cost, and evidence receipts.
- A reference architecture and ADR set for the smallest reversible composition.
- Thin experiments against representative workflows with explicit success and abandonment thresholds.
- 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.
Evidence · version
what this page renders, from which bytes; the claim ceilingdocs/frontier-question-template.html, 216 lines, 13,801 bytes, sha256 4612cbf1938e54a846553f6d676e85d7af5734b79063724a73a83eff74687f31.wc -l -c · shasum -a 256 · 6 Sep 20:08 UTC+07<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[].html781ea9c 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.htmlcodex/mission-question-architecture-20260801, and lists this doc among its changes.registry/events/2026-08-01-mission-question-architecture-completed.jsonsiso-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+07docs/*.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)- 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.
781ea9cAgent entry
shasum -a 256 docs/frontier-question-template.htmlgit log --format='%h %ci %s' -- docs/frontier-question-template.htmlbin/compose U7 templates/U7/example.json --out /tmp/U7.html
- 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`.