Evidence lineage
Claims, calculations, decisions, and source bytes retain exact provenance instead of inheriting confidence from prose.
System, not shelf
How Founder Hub works
A registry entry begins with a bounded job and becomes useful only when its runtime, context, gates, cost, and review evidence can be inspected together.
The unit of work
A skill is a repeatable practice with an interface.
It names what goes in, what should come out, where judgment is required, and what evidence would make the result credible.
role+skill+runtime+ tools+context+gate+ cost+rubric
All present; none needlessly elaborated. A missing component is a visible design gap, not something a confident paragraph can conceal.
Proposed v0.1 distribution
One self-contained plugin, many atomic skills.
Until architecture ratification, this is the reference design—not a frozen compatibility promise. Shared contracts stay inside the distribution so a copied skill cannot quietly depend on an unverified sibling package.
Shared venture state
Skills reconcile against one proposed venture record rather than inventing a fresh version of the company.
Executable adversaries
Negative, boundary, non-transfer, and deliberately broken fixtures prove that validators can reject bad work.
Repairable artifacts
Failures remain typed, retained, and versioned so another steward can reproduce and repair them.
Independent grading
A producer can test rigorously but cannot certify its own bytes; a different vendor grades the frozen candidate.
Authority recovery is gate zero
The expected Startup Coach chassis handoff has not been recovered.
Founder Hub therefore withholds compatibility, frozen-Stoa, and installability claims. The recovery session must locate authoritative inputs or record a typed gap; it may not invent the missing contract.
Factory sequence
Five gates precede the dependency waves.
- 01
Ratify authority
Recover the missing chassis handoff or ratify visibly proposed Founder Hub-specific Stoa and RUN_RECORD contracts.
- 02
Build Assumption Ledger
Implement the harness, shared venture-state substrate, and first foundation candidate together.
- 03
Grade exact bytes
Freeze the candidate and ask a fresh different-vendor grader to falsify it without editing the target.
- 04
Prove composition with Liability of Newness
The second foundation must consume accepted Assumption Ledger state without rewriting claims, evidence, decisions, lineage, or run records.
- 05
Freeze and fan out
Gate the two-capability replay, freeze Stoa v0.1, and only then open dependency-safe producer waves.
Dependency waves
The 21 records are a capability map, not 21 parallel builds.
Wave A · 9 candidates
Begin only after Stoa v0.1 is frozen; each candidate depends on the shared substrate and accepted foundation interface.
Wave B · 7 candidates
Start after their named upstream skill interfaces are accepted, frozen, and available for composition replay.
Wave C · 3 candidates
Sales operator, promo video, and fundraise readiness wait for their full dependency chains to land.
First composition proof
Shared venture state must survive the handoff.
The proposed Assumption Ledger → Liability of Newness replay must preserve claims, evidence, decisions, lineage, and RUN_RECORD history across two independently reviewable capabilities. That interoperability has not yet been demonstrated.
Development preview
The current registry exposes planned contracts and lineage. It does not publish runnable artifacts or represent any record as reviewed.