coulomb/binky-control
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add company canon v0 and bootstrap workplan

Browse source 
Canon: INTENT, CompanyReactivationPlan, EcosystemMap, AutonomyPolicy,
SuccessMilestones, OfferCatalog, DogfoodPolicy, ControlLoopCatalog,
DecisionQueue, OfficeHourQueue, RiskRegister, plus founding exploration
in history/. Workplan BNKY-WP-0001 covers canon ratification, the first
internal audit, ecosystem cartography, flagship offer, and operating rhythm.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-07-16 02:48:50 +02:00
parent 67d735ddec
commit d6d5cf1a1d
11 changed files with 698 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

104
AutonomyPolicy.md Normal file
View file

@ -0,0 +1,104 @@
# Autonomy Policy
> Status: draft v0.1 — 2026-07-16. Governs what agents may do without the
> founder. In force once ratified. The operating rule: **"ask Bernd" is never
> the default.**
## The rule
> If the founder is unavailable, the system must either continue safely,
> prepare the next decision, or explicitly defer with evidence. It must not
> silently idle.
Valid states: `proceeding` | `prepared for review` | `deferred by policy`.
Invalid state: `waiting because unsure`. Uncertainty triggers research,
comparison, preparation, or risk classification — not paralysis.
## Autonomy lanes
| Lane | Name | Agent may | Human needed? |
| --- | --- | --- | --- |
| **Green** | Safe autonomous | Research, summarize, classify, draft, organize, test, prepare | No |
| **Blue** | Reversible execution | Internal docs, backlog updates, local scripts, reports, local commits | No, but logged |
| **Yellow** | Deferred approval | Prepare external emails, invoices, offers, releases, payments | Yes, async via decision queue |
| **Orange** | Time-window approval | Customer/legal/accounting/banking actions needing business hours | Yes, on office-hour days |
| **Red** | Human-only | Signing, strategic commitments, bank changes, sensitive legal/HR/security | Always |
Optimization target: maximize Green+Blue throughput, queue Yellow, batch
Orange into office-hour days, protect Red from automation.
## Default policies
- **Research:** if uncertain, collect evidence and produce a comparison. Ask
only if ambiguity changes risk or external commitment.
- **Documentation:** agents may create/improve internal markdown freely; must
preserve provenance and mark assumptions.
- **Email:** draft freely; send only pre-approved low-risk routine categories.
Pricing, commitments, complaints, contracts, legal → decision queue.
- **Spending:** recommend freely; never spend outside approved recurring
budgets or explicit thresholds.
- **Product:** refine specs, use cases, architecture, backlog freely; strategic
direction is never final without founder approval.
- **Code:** branches, tests, prototypes, docs, local commits freely; no
production deploys without policy-approved checks.
## Approval packages
When an agent hits a lane boundary it prepares a complete decision package,
not a bare question:
```yaml
decision: ""
recommended_action: ""
reason: ""
evidence: []
risk_level: yellow
reversibility: low | medium | high
deadline: ""
attention_cost: "15 min"
fallback_if_no_approval: ""
options: [approve, reject, revise, defer]
```
## Founder attention budget
```yaml
daily_attention_budget:
available_minutes: 90 # typical of the 1–3 h window
max_decisions_per_day: 7
max_deep_topics_per_day: 1
interaction_style: [concise briefs, approve/reject options, evidence links]
```
## Founder availability is first-class state
```yaml
founder_availability:
state: available | evening_window | unavailable | office_hour_day
allowed_escalation_when_unavailable:
- critical security incident
- payment failure
- legal deadline
```
On return from absence, agents produce a **Return Brief**: what changed, what
progressed, what waits, what went stale, what risks increased, recommended
decisions for today.
## Initial autonomy thresholds
| Area | Autonomous? | Limit |
| --- | ---: | --- |
| Internal docs | Yes | Preserve previous versions |
| Research | Yes | Cite/store sources |
| Backlog refinement | Yes | Propose, don't delete major items |
| Code prototypes | Yes | Branch only, no production deploy |
| Customer emails | Draft only | Send after approval |
| Social/publishing | Draft only | Publish after approval |
| Payments | No | Prepare only |
| Contracts | No | Analyze/draft only |
| Security changes | Mostly no | Prepare/test only |
| Cloud infra | Limited | Non-production only |
Raise autonomy per area only after the system proves reliable there, by
explicit founder decision recorded in `DecisionQueue.md`.

63
CompanyReactivationPlan.md Normal file
View file

@ -0,0 +1,63 @@
# Company Reactivation Plan
> Status: draft v0.1 — 2026-07-16. Turns the dormant legal shell (founded 2019)
> into an operating company. Phase model from `history/260715-InitialExploration.md`.
## Phase overview
| Phase | Name | Goal | Status |
| --- | --- | --- | --- |
| 0 | Dormant legal shell | — | current |
| 1 | Reactivation | Administratively alive, clean, compliant, usable | **next** |
| 2 | Operating company | First offers sold and delivered | planned |
| 3 | Ecosystem provider | Provider of Coulomb / Net Kingdom / Railiance products | planned |
| 4 | Operational Knowledge GmbH | Rename when identity has caught up with mission | planned |
| 5 | OK-level ambition | Category-defining; ok.com becomes rational | north star |
## Phase 1 checklist — Reactivation
Each item needs: current-state evidence, required action, owner (Bernd /
accountant / bank / agent-preparable), and autonomy lane.
### Legal & registry
- [ ] Verify Handelsregister entry, registered address, Geschäftsführer details are current
- [ ] Locate articles of association and shareholder documents; file in evidence store
- [ ] Review company purpose (Unternehmensgegenstand) — is it compatible with the OK mission? (Red lane: change requires notary)
### Tax & accounting
- [ ] Establish accountant relationship (or confirm existing one) — Orange lane
- [ ] Confirm status of past filings (annual accounts, corporate tax, VAT) — identify any arrears
- [ ] Set up bookkeeping workflow (invoice inbox → ledger → evidence)
### Banking & finance
- [ ] Confirm business bank account state and access — Red lane for changes
- [ ] Inventory current costs, subscriptions, and obligations
- [ ] Establish cash/runway view (Finance Steward loop)
### Digital presence
- [ ] Domains: inventory owned domains, decide primary company domain
- [ ] Company email on own domain
- [ ] Minimal website: one page stating what the company does (transition wording below)
### Contracts & IP
- [ ] Inventory existing contracts and obligations
- [ ] Clarify IP ownership: which repos/assets belong to the GmbH vs. Bernd privately — needed before selling ecosystem products
- [ ] Contract templates (NDA, service agreement) — draft lane only
### Internal governance
- [ ] Company canon in this repo (this document set) — v0 done, founder ratification pending
- [ ] Decision records started (`DecisionQueue.md`)
- [ ] Autonomy policy in force (`AutonomyPolicy.md`)
## Transition wording (external, during Phases 1–3)
> Binky Hedgehog GmbH develops operational knowledge infrastructure for
> agentic, secure, and self-improving organizations.
## First internal deliverable
**Binky Operational Knowledge Audit v0** — run the company's own flagship
offer on itself: assess legal, tax, banking, domains, email, contracts,
products, repos, IP ownership, obligations, costs, revenue paths, assets,
missing capabilities, risks. Output feeds this checklist, the
`RiskRegister.md`, and becomes the reusable audit template (dogfood evidence).

75
ControlLoopCatalog.md Normal file
View file

@ -0,0 +1,75 @@
# Control Loop Catalog
> Status: draft v0.1 — 2026-07-16. The company modeled as control loops:
> Sense → Interpret → Decide → Act → Record → Learn. Six initial loops; expand
> as operations grow.
## Loop 1: Company Reactivation Loop
```text
Sense: unresolved legal/admin/tax/company setup issues
Interpret: classify blockers, deadlines, external dependencies
Decide: what must be handled by Bernd / accountant / legal / bank
Act: prepare documents, emails, appointments, checklists
Record: decisions, evidence, status (CompanyReactivationPlan.md)
Learn: update reactivation playbook
```
Lanes: mostly Green/Blue preparation; execution Orange/Red. Maturity: L1.
## Loop 2: Ecosystem Cartography Loop
```text
Sense: repos, notes, documents, project ideas
Interpret: classify into Coulomb / Net Kingdom / Railiance / other
Decide: maturity, product relevance, next action
Act: update registries and maps (EcosystemMap.md)
Record: capability entries
Learn: improve classification standard
```
Lanes: Green/Blue. Maturity: L1.
## Loop 3: Dogfood Loop
See `DogfoodPolicy.md`. Lanes: Green/Blue internally. Maturity: L1.
## Loop 4: Offer Formation Loop
```text
Sense: capability + market pain + proof
Interpret: package into offer
Decide: target customer and promise (founder for direction)
Act: draft offer page, outreach, proposal
Record: OfferCatalog.md and validation evidence
Learn: adjust pricing/scope
```
Lanes: Green drafting; publishing Yellow. Maturity: L1.
## Loop 5: Revenue Development Loop
```text
Sense: leads, conversations, opportunities
Interpret: fit, urgency, ability to pay
Decide: pursue / nurture / ignore
Act: prepare outreach and proposals
Record: CRM/evidence
Learn: improve segment focus
```
Lanes: Green research; outreach Yellow. Maturity: L0.
## Loop 6: Founder Attention Loop
```text
Sense: available time and decision backlog
Interpret: highest-leverage use of the next 1–3 hours
Decide: what Bernd should review now
Act: present decision packages (DecisionQueue.md)
Record: decisions and new policies
Learn: reduce future attention cost
```
Lanes: Green/Blue. Maturity: L1. **This loop is the keystone.**
## Automation maturity levels
L0 Manual · L1 Assisted · L2 Structured · L3 Recommended · L4 Supervised
execution · L5 Conditional autonomy · L6 Closed-loop optimization ·
L7 Auditable subsystem

46
DecisionQueue.md Normal file
View file

@ -0,0 +1,46 @@
# Decision Queue
> Status: live document — decisions awaiting the founder, as prepared
> approval packages (`AutonomyPolicy.md`). Agents append; Bernd resolves.
> Resolved decisions move to the log below with outcome and date.
## Item template
```yaml
id: DEC-2026-NNN
title: ""
lane: yellow | orange | red
status: prepared | resolved | deferred
created_at: ""
needed_by: ""
attention_cost: ""
agent_recommendation: ""
evidence: []
options: [approve, reject, revise, defer]
fallback_if_no_response: ""
```
## Open decisions
### DEC-2026-001 — Ratify company canon v0
```yaml
id: DEC-2026-001
title: "Ratify company canon v0 (INTENT, AutonomyPolicy, and companion docs)"
lane: red
status: prepared
created_at: "2026-07-16"
needed_by: "2026-07-23"
attention_cost: "30 min"
agent_recommendation: "Review INTENT.md and AutonomyPolicy.md closely (they govern everything else); skim the rest. Approve with edits."
evidence:
- INTENT.md
- AutonomyPolicy.md
- history/260715-InitialExploration.md
options: [approve, reject, revise, defer]
fallback_if_no_response: "Canon stays draft; agents operate under conservative lane defaults; no external-facing artifacts produced."
```
## Resolved decisions
*(append resolved items here: id, title, outcome, date, evidence)*

46
DogfoodPolicy.md Normal file
View file

@ -0,0 +1,46 @@
# Dogfood Policy
> Status: draft v0.1 — 2026-07-16. How internal operations become product
> evidence. Dogfooding is the metabolism of the OK Flywheel.
## Policy
1. **Every internal operational pain is a product signal.** Before buying or
hand-rolling a one-off solution, check whether an ecosystem capability can
solve it (`EcosystemMap.md`).
2. **Every internal solution is documented as evidence**: before/after state,
capability used, effort, outcome, reusable pattern, product implication.
3. **The company sells nothing it hasn't run on itself** where feasible — the
Operational Knowledge Audit runs on Binky before any customer.
4. **Evidence is recorded at solution time, not reconstructed later.**
## The dogfood loop
```text
Sense: internal operational pain
Interpret: map pain to ecosystem capability
Decide: use / build / adapt capability
Act: solve internally
Record: evidence and reusable pattern
Learn: update productization backlog (OfferCatalog.md)
```
## Evidence entry template
```yaml
dogfood_case: ""
date: ""
pain: ""
capability_used: ""
pillar: coulomb | net_kingdom | railiance | cross
before: ""
after: ""
effort: ""
reusable_pattern: ""
product_implication: ""
evidence_links: []
```
## Evidence log
*(append entries below)*

66
EcosystemMap.md Normal file
View file

@ -0,0 +1,66 @@
# Ecosystem Map
> Status: draft v0.1 — 2026-07-16. Skeleton; to be populated by repo/capability
> cartography (see workplan). Ecosystem ≠ company: the ecosystem generates and
> matures capabilities; the company commercializes and consumes them.
## Pillars
### Coulomb — capability formation surface
> Discovers, clusters, matures, and packages reusable capabilities.
Commercial angles: capability registry, reuse marketplace, product ideation
surface, repo/product intelligence, adaptive pricing experiments,
membership/community layer.
Known assets (to verify/expand): reuse-surface, adaptive-pricing, Coulomb
membership concepts.
### Net Kingdom — sovereign secure operating substrate
> Provides identity, access, security, governance, and operational sovereignty
> for agentic and human systems.
Commercial angles: IAM/security stack, controlled agent access, audit/security
architecture.
Known assets (to verify/expand): OpsBridge, Keycape, OpenBao patterns, PECS,
identity-canon, user-engine.
### Railiance — reliable execution and coordination layer
> Coordinates reliable workflows, deliveries, evidence chains, and operational
> commitments.
Commercial angles: coordination products, evidence-backed communications,
delivery/result tracking, workflow reliability.
Known assets (to verify/expand): coordination-engine, email-connect,
citation-evidence.
## Cross-pillar / unassigned assets
To classify during cartography: ConfigAtlas, feature-control,
consistency-frame, HelixForge-style software factory, markitect, personhood,
foerster_capabilities, the-custodian / state-hub itself (candidate product:
agentic company cockpit).
## Capability entry template
```yaml
capability: <name>
pillar: coulomb | net_kingdom | railiance | cross
repos: []
maturity: idea | prototype | internal_use | productizable | product
dogfood_status: not_used | in_use | proven
product_candidates: []
owner: bernd
notes: ""
```
## Triad summary
```text
Coulomb → discover and shape capability
Net Kingdom → secure and govern capability
Railiance → coordinate and deliver capability
Binky / OK → sell, operate, and prove capability
```

58
OfferCatalog.md Normal file
View file

@ -0,0 +1,58 @@
# Offer Catalog
> Status: draft v0.1 — 2026-07-16. Offers, not just products — an offer can
> exist before the software is complete. Earn from Level 1–2 while maturing
> Level 3.
## Initial commercial category
> **Operational Knowledge Readiness for Agentic Companies** — before agents
> can run company processes, operational knowledge must become visible,
> structured, governable, and executable.
## Level 1 — Advisory / service offers (fastest to monetize)
| Offer | Status |
| --- | --- |
| **Operational Knowledge Audit** (flagship candidate) | candidate — dogfood on Binky first |
| Configuration Surface Assessment | candidate |
| Agentic Operations Readiness Review | candidate |
| Security / Access Control Architecture Review | candidate |
| Capability Registry Workshop | candidate |
| Digital Communication Evidence Assessment | candidate |
### Flagship: Operational Knowledge Audit — deliverables
- Operational knowledge map
- Capability inventory
- Configuration surface map
- Access / identity risk notes
- Process/control-loop catalog
- Automation readiness score
- Agentic autonomy lane recommendations
- Prioritized implementation roadmap
## Level 2 — Productized service offers (repeatable packages)
ConfigAtlas Discovery Sprint · Net Kingdom IAM/Security Bootstrap ·
Coordination Evidence Setup · Solo-Founder Agentic Cockpit Setup ·
Capability Registry Implementation · Feature-Control Introduction Package
## Level 3 — Software products (scalable assets)
ConfigAtlas · reuse-surface · coordination-engine · email-connect ·
feature-control · OpsBridge · Keycape · Agentic Company Cockpit
## Offer entry template
```yaml
offer: ""
level: 1 | 2 | 3
status: candidate | drafted | published | sold | retired
target_segment: ""
promise: ""
deliverables: []
price_hypothesis: ""
dogfood_evidence: []
dependencies: []
```

41
OfficeHourQueue.md Normal file
View file

@ -0,0 +1,41 @@
# Office-Hour Queue
> Status: live document — Orange-lane items that need business-hour
> interaction (calls, banks, authorities, accountant, notary). Batched into
> ~two office-hour command days per month. Agents preload each day with a
> runbook; the day is scarce strategic infrastructure — protect it from
> low-leverage work.
## Item template
```yaml
id: OH-2026-NNN
title: ""
counterparty: "" # accountant, bank, authority, customer, vendor
status: queued | prepared | done
prepared_material: [] # briefings, drafts, documents ready before the call
deadline_pressure: none | soft | hard (date)
```
## Queued items
*(populated by the Binky Operational Knowledge Audit — expected: accountant
contact/filing status, bank account access verification, registry detail
check)*
## Office-Hour Runbook template
```markdown
# Office-Hour Command Day — <date>
## Must do today
1. ...
## Prepared material
- ...
## Do not spend time on
- internal documentation
- repo cleanup
- speculative naming
```

75
RiskRegister.md Normal file
View file

@ -0,0 +1,75 @@
# Risk Register
> Status: draft v0.1 — 2026-07-16. Known failure modes, mitigations, and
> escalation paths. Reviewed in the daily brief; updated whenever a risk
> changes.
## Risk entry template
```yaml
id: RISK-NNN
title: ""
class: legal | financial | security | product | attention | ecosystem
likelihood: low | medium | high
impact: low | medium | high
status: open | mitigating | accepted | closed
mitigation: ""
escalation: ""
```
## Open risks
```yaml
id: RISK-001
title: "Unknown compliance state of dormant GmbH (filings, tax, registry)"
class: legal
likelihood: medium
impact: high
status: open
mitigation: "Binky Operational Knowledge Audit v0; accountant engagement (Orange lane)"
escalation: "Hard legal deadline discovered → allowed escalation even when founder unavailable"
```
```yaml
id: RISK-002
title: "IP ownership between Bernd (private) and GmbH unclarified"
class: legal
likelihood: high
impact: high
status: open
mitigation: "Inventory during audit; clarify before any ecosystem product is sold"
escalation: "Blocks S4 (first external offer) if unresolved"
```
```yaml
id: RISK-003
title: "Founder attention is the single point of failure"
class: attention
likelihood: high
impact: high
status: mitigating
mitigation: "AutonomyPolicy lanes; decision packages; unattended-progress design"
escalation: "Decision queue older than 14 days → prune and re-prioritize"
```
```yaml
id: RISK-004
title: "Too many parallel product ideas dilute focus (idea cloud > portfolio)"
class: product
likelihood: high
impact: medium
status: open
mitigation: "Offer Catalog levels; one flagship offer first; success ladder discipline"
escalation: "Founder decision on focus if >3 offers active simultaneously"
```
```yaml
id: RISK-005
title: "Agentic stack becomes busywork generator instead of progress engine"
class: product
likelihood: medium
impact: medium
status: open
mitigation: "Every loop must feed a queue, a decision, or evidence; brutalist founder interface; token budgets"
escalation: "Weekly review shows activity without milestone movement"
```

41
SuccessMilestones.md Normal file
View file

@ -0,0 +1,41 @@
# Success Milestones
> Status: draft v0.1 — 2026-07-16. The ladder from legal shell to "ok.com is a
> rational acquisition". Intermediate rungs keep the mythic endpoint from
> distorting the present.
## Success ladder
| Rung | Milestone | Status |
| --- | --- | --- |
| S0 | Legal vessel exists | ✅ done (2019) |
| S1 | Company is administratively clean | ⬜ in progress (Phase 1) |
| S2 | Company has an active operating system | ⬜ started (this repo) |
| S3 | First internal dogfood loop works | ⬜ |
| S4 | First external offer published | ⬜ |
| S5 | First paid revenue | ⬜ |
| S6 | Repeatable productized service | ⬜ |
| S7 | Software-supported delivery | ⬜ |
| S8 | Multiple customers | ⬜ |
| S9 | Operational Knowledge rename makes sense | ⬜ |
| S10 | Category identity emerges | ⬜ |
| S11 | OK becomes a serious brand | ⬜ |
| S12 | ok.com becomes a rational acquisition | ⬜ |
## Rename readiness criteria (gate for S9)
Rename to **Operational Knowledge GmbH** when most of these are true:
- [ ] First repeatable offer exists
- [ ] Clean accounting/admin operations
- [ ] Website and messaging are coherent
- [ ] At least one paying customer or serious pilot
- [ ] Ecosystem map is understandable to outsiders
- [ ] Dogfood evidence exists
- [ ] Product direction is narrower than the full idea cloud
- [ ] "Operational Knowledge" clearly describes what is being sold
## Rule
Milestone status changes are founder decisions, recorded in
`DecisionQueue.md` with evidence.

83
workplans/BNKY-WP-0001-operating-kernel-bootstrap.md Normal file
View file

@ -0,0 +1,83 @@
---
id: BNKY-WP-0001
title: "Binky / OK Operating Kernel Bootstrap"
status: active
---
Make Binky Hedgehog GmbH practically operable and strategically aimed at
becoming Operational Knowledge GmbH. Scope: ratify the company canon, run the
first internal audit, populate the ecosystem map, form the flagship offer, and
get the queue-driven operating rhythm running. Corresponds to reactivation
Phase 1 and success-ladder rungs S1–S3.
## Task: Founder ratifies company canon v0
Review and approve/revise INTENT.md, AutonomyPolicy.md, and companion docs
(DEC-2026-001 in DecisionQueue.md). Red lane — founder only.
```task
id: BNKY-WP-0001-T01
status: todo
priority: high
```
## Task: Run Binky Operational Knowledge Audit v0
Dogfood the flagship offer on the company itself: inventory legal, tax,
banking, domains, email, contracts, repos, IP ownership, obligations, costs,
revenue paths, risks. Output feeds CompanyReactivationPlan.md checklist,
RiskRegister.md, OfficeHourQueue.md, and becomes the reusable audit template.
Green/Blue preparation; findings needing external action go to queues.
```task
id: BNKY-WP-0001-T02
status: todo
priority: high
```
## Task: Populate Ecosystem Map via repo cartography
Classify actual repos and assets into Coulomb / Net Kingdom / Railiance /
cross, using the capability entry template in EcosystemMap.md. Record maturity
and product candidates. Green lane.
```task
id: BNKY-WP-0001-T03
status: todo
priority: medium
```
## Task: Draft flagship offer — Operational Knowledge Audit
Turn the audit template plus Binky dogfood evidence into a drafted Level-1
offer in OfferCatalog.md: target segment, promise, deliverables, price
hypothesis. Drafting is Green; publishing is Yellow (decision package).
```task
id: BNKY-WP-0001-T04
status: todo
priority: medium
```
## Task: Establish operating rhythm (daily brief + queue hygiene)
Define and exercise the daily brief format (decide now / progress / risks /
best next hour), keep DecisionQueue and OfficeHourQueue current, and seed the
Autopilot Work Queue with evergreen Green/Blue work. Blue lane.
```task
id: BNKY-WP-0001-T05
status: todo
priority: medium
```
## Task: Prepare first Office-Hour Command Day runbook
From audit findings, batch all Orange-lane items (accountant, bank, registry)
into a prepared runbook per the OfficeHourQueue.md template. Green preparation.
```task
id: BNKY-WP-0001-T06
status: todo
priority: low
```