---
id: CUST-BSP-2026-000001
type: procedure
title: "Bootstrap Protocol v0.1"
status: draft
owners: ["Bernd", "Custodian"]
created: "2026-07-08"
updated: "2026-07-08"
scope:
  domains: ["Custodian", "Railiance"]
  sensitivity: internal
tags: ["bootstrap", "capital", "roles", "fos", "mvp"]
---

# Bootstrap Protocol v0.1

Addresses FOS blindspot #2: **bootstrapping and initial capital**. Neither FOS
nor OAS defines how the first €10k is funded, what MVP must exist before the
first customer, or which roles are mandatory at formation.

This protocol applies to the Railiance/Custodian ecosystem until a formal GmbH
and multi-stakeholder governance structure supersedes it.

## 1. Seed Funding Strategy

### Minimum Viable Budget (12-month bootstrap)

| Category | Estimate (EUR) | Notes |
| --- | --- | --- |
| Infrastructure (HostEurope, domains) | 3,000–5,000 | Existing fleet partially covers this |
| LLM/API tokens | 1,500–3,000 | Tracked via fin-hub; burn alerts at 80% budget |
| Legal/GmbH formation | 2,000–4,000 | Deferred until first revenue signal |
| Tooling/licenses | 500–1,000 | Prefer OSS; EU-hostable |
| Contingency | 2,000 | Restore drills, hardware failure |
| **Total** | **€9,000–15,000** | Founder-funded in v0.1 |

### Funding Sources (v0.1)

1. **Founder capital** — primary source until first paying customer.
2. **Consulting revenue** — Railiance architecture reviews (pre-GmbH: freelance
   invoice under existing legal entity or transitional structure).
3. **Grants** — EU digital sovereignty programs (exploratory, not blocking).

No external investment required for MVP. External capital triggers formal
Financial Allocator role and updated constitution clauses.

## 2. MVP Scope Definition

The bootstrap MVP is **not** a full FOS Level 5 federation. It is the minimum
viable stack that proves:

1. Reproducible deploy + restore for the Custodian/Railiance substrate.
2. Multi-hub separation at Level 3 boundary (dev, ops, fin conceptually distinct).
3. Identity integration via IAM Profile v0.2.
4. Ops evidence on Core Hub production surface.
5. Cost visibility sufficient to compute runway.

### Must Exist Before First Customer

| # | Capability | Status (2026-07-08) |
| --- | --- | --- |
| 1 | dev-hub (State Hub) workplan coordination | done |
| 2 | hub-core extracted package | done |
| 3 | Core Hub ops evidence (production) | done |
| 4 | IAM Profile integration template | done |
| 5 | fin-hub with runway calculator | in progress (T22–T24) |
| 6 | Restore drill evidence (Railiance) | partial |
| 7 | RaaS onboarding runbook | draft (business-model-canvas) |
| 8 | Legal/GmbH review | not started (T26) |

### Explicitly Out of MVP

- Full Keycloak enterprise federation (`NK-WP-0011` lane)
- Autonomous agent scheduling
- Multi-customer tenancy
- NATS cross-hub transport
- Haskell Inter-Hub retirement (gated on stabilization sign-off)

## 3. First Three Mandated Roles

Per FOS §12 and the Big Picture Guidance blindspot analysis, three roles are
mandatory at bootstrap — they may be held by the same human initially but must
remain **explicitly separable**:

### Constitutional Steward (System 5)

- Owns canon, values, constitution, and non-delegable policies.
- Approves canon promotions and escalation when agent actions affect legal,
  financial, or reputational posture.
- Cannot be silently merged with Technical Operator authority.

**v0.1 holder:** Bernd (founder).

### Technical Operator (System 3 / Ops)

- Owns infrastructure substrate, deployment, restore drills, and Core Hub
  production surface.
- Executes cutover, rollback, and stabilization decisions.
- Routes credentials through approved custody paths only.

**v0.1 holder:** Bernd (founder), with agent assistance under tool-boundary policy.

### Financial Allocator (System 3* / Fin)

- Owns budget, burn rate, runway projection, and spend approval thresholds.
- Surfaces resource pressure signals to dev-hub and viability alerts to canon.
- Escalates when runway drops below alert threshold.

**v0.1 holder:** Bernd (founder) until fin-hub automation exists; then
fin-hub surfaces data, human retains approval for transactions.

## 4. Revenue Threshold for Role Formalization

| Milestone | Trigger | Action |
| --- | --- | --- |
| **Role separation** | First €5,000 external revenue OR first non-founder contributor | Split Technical Operator and Financial Allocator if same person; document in constitution amendment. |
| **GmbH formation** | First €10,000 annual revenue or first managed-tier customer | Engage legal counsel; update liability, SLA, and invoicing structure. |
| **Board/advisory** | €50,000 annual revenue or 3+ paying customers | Add Constitutional Steward separation if not already independent. |

Until thresholds are met, founder-held multiple roles are acceptable provided
authority boundaries are documented and audited.

## 5. Escalation and Human Override

Bootstrap operations inherit `custodian_constitution_v0.1.md`:

- Financial transactions, legal commitments, and external representations require
  explicit human approval.
- Agent actions must be auditable and reversible within 5 minutes where they
  affect production infrastructure.
- Runway below 3 months triggers mandatory Financial Allocator review and
  dev-hub workstream deprioritization signal (fin→dev coupling, T25).

## 6. Success Criteria for Bootstrap Exit

Bootstrap phase ends when:

1. FOS maturity Level 3 is operational (dev, ops, fin hubs distinct).
2. First external customer onboarded OR €10k consulting revenue recorded.
3. GmbH or equivalent legal entity formed.
4. Runway calculator shows ≥6 months at current burn.
5. Restore drill evidence exists for production Railiance cluster.

## References

- `wiki/BigPictureGuidance.md` — blindspot #2 origin
- `canon/constitution/custodian_constitution_v0.1.md`
- `canon/standards/federated-organization-standard_v1.0.md` — §12 roles, §14 maturity
- `canon/projects/railiance/business-model-canvas_v0.1.md`
- `workplans/CUST-WP-0025-fos-hub-bootstrap.md`