ADR-0024 — Continuity Plan for Founder Unavailability

Context

Synth Nova operates under Monopreneur Principle (ADR-0023) — single human founder (Denis) + LLM workforce. This creates single-point-of-failure risk that must be addressed before serious fundraise conversations.

The question investors will ask: “What happens if Denis is unavailable for 1 week / 1 month / permanently?”

Current state: No documented protocol. Clients, infrastructure, and data are informally managed through Denis’s personal accounts and Termius access.

Specific risks:

• Denis hospitalized / incommunicado → client campaigns fail silently
• Active Navigator runs die with no fallback operator
• GeeLark-maintained Instagram accounts get banned if anti-detect updates aren’t applied
• Synergia RK (current paying client) KPI missed, reputation damage
• Passwords, API keys, server access all in personal devices (iPhone Termius)
• Chamber/M3 sessions in progress → decisions frozen indefinitely
• Contractor (Разработчик-1 for GeeLark anti-detect) has no escalation path

Why this blocks serious fundraise: Due diligence will uncover this gap. Investors need to see either (a) a documented continuity plan or (b) acceptance that this is a solo-founder risk priced into the deal. Option (b) caps valuation.

Decision

Document a tiered continuity protocol with these components:

1. Three-tier unavailability classification

Tier A — Short (1-7 days): Expected absence (vacation, illness, travel without connectivity)

• Pre-announce to clients via scheduled email
• Pause non-critical pipeline runs (no new M1 runs; in-progress can complete)
• GeeLark orchestration: ensure 7-day buffer before anti-detect updates needed
• Active client campaigns continue on auto-pilot if pre-scheduled

Tier B — Medium (1-4 weeks): Extended absence (surgery, family emergency, extended travel)

• Activate “slow mode” — no new client onboarding
• Synergia RK campaign: assign observer (trusted advisor to monitor dashboards, not make decisions)
• All Chamber L3 decisions deferred until Denis returns
• Systems put in read-only mode where possible

Tier C — Indefinite (1+ months or permanent): Catastrophic (serious illness, death)

• Trusted party activates escrow (see Section 5)
• Client notifications sent from designated escrow holder
• GitHub organization transfer triggered
• Infrastructure (VPS, domains, Cloudflare) transfer per documented handoff

2. Dead-man switch

Mechanism: Automated check-in system.

• Weekly email/SMS to escrow contact: “Denis still operational, code: XXXX”
• If 2 consecutive weeks missed → Tier B auto-activated, escrow contact receives alert + limited access
• If 4 consecutive weeks missed → Tier C auto-activated, full escrow activation

Implementation: Simple script on VPS with cron job, sends via Telegram / email. Requires Denis to respond with OTP each week.

3. Escrow contact

Role: Designated trusted party with escrow access to critical credentials.

Not a co-founder or operator. Only role is to execute Continuity Plan if triggered.

Access held:

• Master password manager vault (1Password / Bitwarden family backup)
• GitHub organization admin handoff key
• Domain registrar recovery email
• VPS provider (Hetzner) recovery contact
• Cloudflare account recovery

Responsibilities:

• Monitor dead-man switch
• On Tier B/C trigger: execute Tier B/C protocol
• Contact designated clients (Synergia RK, any others)
• Initiate GitHub / domain / infrastructure transfer

Who: To be selected by Denis. Requirements: personally trusted, technically literate (can read protocol), not in same jurisdiction as Denis (for diversity), not connected to competitors.

Compensation: Minimal retainer ($100-200/month) or pro-bono with explicit written agreement.

4. Documentation requirements

Every system component must have:

Runbooks (stored in manifest/12-Operations/Runbooks/):

• How to restart M1 pipeline
• How to rotate LLM API keys
• How to handle GeeLark anti-detect updates (escalate to Разработчик-1)
• How to access each VPS, what runs on each
• How to bill / invoice clients (in-progress setup)
• How to pause Synergia campaign gracefully

Credential inventory (stored in encrypted vault, NOT in manifest):

• All API keys with provider, purpose, rotation date
• All server access with IP, SSH key location, user accounts
• All third-party accounts (Cloudflare, domain registrar, payment processors)

Client roster (stored in encrypted vault):

• Each client’s primary contact, commercial terms, KPIs, current campaigns
• Escalation path per client

5. GitHub + infrastructure transfer protocol

GitHub:

• Synth Nova organization with Denis as owner
• Escrow contact listed as backup owner with limited current access but full transfer rights
• On Tier C: GitHub Support contacted with transfer request

VPS (Hetzner):

• Primary account in Denis’s name
• Escrow contact listed in account recovery contact
• On Tier C: account control transferred per Hetzner policy

Domains (synth-nova.com, etc):

• Registrar account with escrow recovery email
• DNS managed through Cloudflare with MFA recovery codes in vault

Cloudflare:

• Similar — escrow has recovery access via documented protocol

6. Client protocol

Active clients (as of 2026-04-20: only Synergia RK):

Explicit written agreement with each client including:

• What happens if Denis is unavailable Tier A (campaign continues, no decisions made)
• What happens Tier B (campaign pauses or continues per pre-agreed auto-rules)
• What happens Tier C (escrow contact communicates, arranges refund or transition)

Client is informed upfront about solo-operator structure. This is part of the Monopreneur positioning — transparent risk for premium service.

For future clients: Continuity clause embedded in all standard agreements.

7. LLM workforce “handoff”

Observation: LLM agents don’t care if Denis is unavailable. They continue running per schedule.

Risk: If pipeline runs are misconfigured or hang, no human intervention. Runaway costs possible.

Mitigations in place:

• Budget caps per run ($5 hard limit per M1 run)
• Per-agent timeouts (Fix C from ADR-0018 work)
• Daily spend monitoring via API provider dashboards
• Kill switches (systemd service disabling, cron pause)

Additional mitigation for Continuity:

• Escrow contact has authority to invoke “emergency pause” — runs systemd command that halts all scheduled pipeline executions
• Documented procedure in runbook

8. Review cadence

• This ADR reviewed quarterly for accuracy
• Runbooks tested twice yearly (full dry-run — does escrow contact actually have what they need?)
• Dead-man switch tested monthly
• After any significant architecture change, continuity implications evaluated

Consequences

Positive:

• Fundraise conversations can address continuity directly with documented answer
• Reduced anxiety for Denis (knowing that sudden absence doesn’t destroy company value)
• Client trust increased by transparent risk communication
• Forces documentation discipline (runbooks, credential inventory)
• Aligns with Monopreneur Principle (no equity dilution, no co-founder required)

Negative / tradeoffs:

• Ongoing operational overhead (monthly dead-man switch, quarterly review)
• Requires trusted party (single point of trust — if escrow contact is compromised, risk shifts there)
• Modest monthly cost ($100-200 for escrow retainer + password manager plus plan)
• Initial setup time (runbooks + vault seeding): 20-40 hours of Denis’s time

Neutral:

• Plan is mostly dormant — active only on triggers
• Most of the plan is paper; value realized only in actual emergency

Status: proposed

Implementation gates:

• Identify and approach escrow contact candidate
• Select password manager for family/escrow features (likely 1Password Families)
• Write 5-7 core runbooks (M1 pipeline, Chamber, OpenClaw, GeeLark, Synergia campaign management)
• Set up dead-man switch script (simple cron + Telegram notification)
• Draft client continuity clause template
• Execute full dry-run once with escrow candidate
• Add to Session-Context / Active-Plan with quarterly review reminder

Estimated time to “functional Tier A handling”: 1 week. Estimated time to “functional Tier B+C handling”: 3-4 weeks including escrow contact onboarding.

Alternatives considered

Alt 1: Co-founder with equity. Rejected — violates ADR-0023 Monopreneur Principle. Also doesn’t solve the problem; co-founder unavailability is similar risk.

Alt 2: Operations manager hire. Rejected — violates ADR-0023. Current scale doesn’t need it anyway.

Alt 3: Accept risk, no plan. Rejected for fundraise. Acceptable only if deliberately staying bootstrapped and never raising. Denis has stated intention to raise eventually, so plan is needed.

Alt 4: Sell company / acquihire if unavailable. Considered for Tier C. May be explicit path in escrow contact’s instructions — “find acquirer, transfer assets, distribute proceeds per will.” Not primary plan but valid endgame.

References

• ADR-0023 Monopreneur Principle — why we can’t solve this via hire/partner
• 00-Core/Constitution.md Law 5 — Human Veto on irreversible actions (Tier C actions are irreversible, need clear authorization)
• 00-Core/EscalationPolicy.md — formal escalation process, extends to Continuity
• 07-Roadmap/Active-Plan.md — fundraise timeline (this ADR unblocks)

Open questions

• Q1: Escrow contact candidate — who? (Denis’s decision, personal)
• Q2: Dead-man switch cadence — weekly too noisy? Monthly too slow? Suggestion: biweekly with auto-escalation.
• Q3: Should Anthropic / OpenAI / Gemini be notified of continuity plan? (API keys would be revoked per provider policy on death — need clarification)
• Q4: Is there a insurance product for founder disability that would fund business continuity? Worth investigating.

Next actions

1. Denis reviews this draft and approves direction (or proposes edits)
2. Denis identifies escrow contact candidate
3. Conversion to “accepted” ADR status once candidate confirmed
4. Implementation sprint (1-4 weeks)