tegwick
0777e5b2f0
- canon/standards/credential-management_v0.1.md: single root-of-trust credential hierarchy standard - canon/standards/federated-organization-standard_v1.0.md: FOS reference architecture (VSM-based) - wiki/BigPictureGuidance.md: integration guidance for OAS + FOS orthogonal layers - workplans/CUST-WP-0025-fos-hub-bootstrap.md: 4-phase plan (identity, hub-core extraction, ops-hub, fin-hub) - state-hub/Makefile: treat exit 2 (warnings-only) as success in check-consistency targets Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
119 lines
8.4 KiB
Markdown
119 lines
8.4 KiB
Markdown
We will set up a federated autonomous organization and IT infrastructure based on two VSM based
|
||
standards according to the following guidance about how to integrate them and adress conflicts
|
||
and blind spots.
|
||
|
||
This document is the current Big Picture Guidance for the Custodian and should inform creation
|
||
and priority of how to spend time, money and tokens bootstrapping the infrastructure efficiently.
|
||
|
||
**Integration Guidance: Orthogonal Architecture Standard (OAS) + Federated Organisation Standard (FOS)**
|
||
|
||
Note: The standards are available under canon/standards/
|
||
|
||
Both standards are **explicitly built on the same foundation** — Stafford Beer’s Viable System Model (VSM). This is not a coincidence; it is the single strongest reason they integrate cleanly. OAS applies VSM to **compute systems** (Kubernetes/cloud-native infra), while FOS applies the identical VSM logic to **organizational structure** (including humans + AI agents). Together they form a complete “cybernetic stack”: FOS gives you the viable *organization*, OAS gives you the viable *infrastructure* that the organization actually runs on.
|
||
|
||
### 1. How to Integrate Them (Recommended Architecture)
|
||
|
||
Treat the two standards as **orthogonal layers of one recursive system**:
|
||
|
||
- **FOS = System-of-Systems layer** (organizational recursion L0–L3)
|
||
- **OAS = Compute substrate layer** (technical recursion inside every hub and every domain)
|
||
|
||
**Core mapping (one-to-one VSM alignment)**
|
||
|
||
| VSM Role | FOS Hub(s) | OAS Dimension(s) Used to Realize It | Concrete Implementation Pattern |
|
||
|----------------|--------------------------------|------------------------------------------------------|---------------------------------|
|
||
| System 5 | Canon Hub | Plane P2 + Capability C1 + Quality Q7 + Intelligence I5 | GitOps repo + policy-as-code + AI agents that *must* route through control plane |
|
||
| System 4 | Fin Hub + parts of Dev Hub | Intelligence I4 + Capability C4 + Stack S4 | Adaptive autoscaling + AI config assistants + cost-optimization loops |
|
||
| System 3 / 3* | Sec Hub + Ops Hub | Plane P2/P3 + Quality (all Q) + Stack S2/S3 | Kubernetes control plane + policy engines + observability + audit probes |
|
||
| System 2 | Dev Hub + Ops Hub cross-talk | Logic L3 + Plane P2 + Relation “governs”/“observes” | Workflow engines + GitOps controllers + cross-hub protocol |
|
||
| System 1 | All operational domains + workloads | Stack S5 + Logic L2/L4 + Capability C3/C5 | Actual pods/services/APIs that deliver value |
|
||
|
||
**Practical bootstrap sequence (start small, stay viable at every level)**
|
||
|
||
1. **Day 0–30: Canon Hub first**
|
||
Create a single sparse Git repository (or lightweight Notion/Obsidian + Git sync). This becomes your System 5.
|
||
Declare: mandates, delegation matrix, non-delegable boundaries, and the rule “*All AI actions MUST route through the control plane*” (directly from OAS I5 + FOS 5.6).
|
||
|
||
2. **Day 30–60: Seed the four core hubs as derived-state services**
|
||
- Dev Hub → Backstage or custom portal on top of your repos + ADRs + capability catalog (OAS Logic L1 + Capability C1–C3).
|
||
- Ops Hub → ArgoCD + Prometheus + custom “now view” dashboard (OAS Stack S1–S3 + Plane P2).
|
||
- Sec Hub → OPA/Gatekeeper + Vault + Trivy + exception register (OAS Quality Q1 + Plane P2).
|
||
- Fin Hub → OpenCost + Git-based budget manifests + runway calculator (OAS Quality Q6 + Intelligence I4).
|
||
|
||
All four hubs expose the **minimal cross-hub contract** from FOS §10 (get_domain_summary, request_capability, escalate_issue, etc.). Implement it once as a small Kubernetes operator or simple REST + NATS/event bus.
|
||
|
||
3. **Ongoing: Make every hub itself a recursive OAS system**
|
||
Each hub runs on its own namespace/cluster slice. Apply the full OAS dimensions inside it:
|
||
- Its workloads = OAS Stack S5
|
||
- Its internal control = OAS Plane P2
|
||
- Its AI agents = OAS Intelligence I5 (always governed)
|
||
This satisfies FOS recursion principle automatically.
|
||
|
||
4. **AI Agent Integration (the autonomous part)**
|
||
- All agents live in the **Intelligence dimension** of OAS.
|
||
- They are treated as **System 1 units** inside the relevant FOS domain (e.g., coding agents in Dev Hub).
|
||
- They *never* bypass the control plane (OAS P3 + FOS 10.1).
|
||
- Canon Hub policies (e.g., “no agent may spend >€500 without escalation”) are enforced by OAS Quality Q7 + Sec Hub.
|
||
|
||
### 2. Conflicts to Mitigate (there are only two real ones)
|
||
|
||
**Conflict 1: Centralised Control Plane vs. Derived-State Hubs**
|
||
OAS insists “all changes go through control plane”.
|
||
FOS insists “hubs must remain derived, rebuildable, not sole source of truth”.
|
||
|
||
**Mitigation (already built into both standards):**
|
||
- Make the control plane itself **derived** (GitOps + reconciliation loops).
|
||
- Source of truth = canonical Git repos + policy documents.
|
||
- Hubs only index, summarise, and route.
|
||
- Delete/rebuild any hub → it re-derives everything from source (FOS 5.2 + OAS Plane P2).
|
||
|
||
**Conflict 2: Time-horizon mixing**
|
||
Ops Hub wants seconds-to-weeks view; Fin Hub wants quarters-to-years; Canon wants “forever”.
|
||
|
||
**Mitigation:**
|
||
- Enforce FOS §8.2 time-horizon separation at the data model level (different retention, different dashboards, different escalation SLAs).
|
||
- Use OAS Quality Q7 governance policies to forbid a single dashboard that mixes horizons.
|
||
|
||
No other structural conflicts exist — the standards were clearly designed to interlock.
|
||
|
||
### 3. Blindspots to Address (these are the real gaps)
|
||
|
||
1. **Legal / Regulatory Reality (FOS mentions Legal Hub as optional — make it mandatory in EU)**
|
||
You are in Germany. Add a lightweight Legal Hub (or at least Canon Hub section) for DSGVO, AI Act, GmbH law, tax, etc. OAS does not mention compliance jurisdiction — you must layer it on top of Quality Q1 + Canon Hub.
|
||
|
||
2. **Bootstrapping & Initial Capital**
|
||
Neither standard tells you how to fund the first €10k or hire the first human.
|
||
→ Create a one-time “Bootstrap Protocol” document in Canon Hub that defines seed funding, MVP scope, and first three mandated roles (Constitutional Steward + Technical Operator + Financial Allocator).
|
||
|
||
3. **Human–AI Handover & Psychological Safety**
|
||
FOS talks about “humans and artificial agents” but gives no guidance on when a human must override an agent or how to handle agent mistakes that affect people.
|
||
→ Add explicit “Human Override” policy in Canon Hub + OAS Intelligence I5 rule: every agent action must be auditable and reversible by a human in <5 min.
|
||
|
||
4. **External Interfaces & Customers**
|
||
Both standards are inward-focused.
|
||
→ Explicitly model “Customer Capability” in OAS Capability C5 and expose it through a public-facing API gateway (OAS Stack S5) that is still governed by the same control plane.
|
||
|
||
5. **Exit / Dissolution / Succession**
|
||
No standard covers “what happens if the founder disappears or the org needs to be wound down”.
|
||
→ Canon Hub must contain a “Sunset Clause” and delegation-of-dissolution rules.
|
||
|
||
6. **Concrete Tooling & Cost Control**
|
||
The standards are abstract. A practical minimal stack that satisfies both at once (all open-source, EU-hostable):
|
||
- Kubernetes (k3s or Talos) + ArgoCD + Crossplane (for OAS Stack)
|
||
- Backstage (Dev Hub)
|
||
- Grafana + Loki + Tempo + OpenCost (Ops + Fin)
|
||
- OPA + Kyverno + Vault (Sec)
|
||
- NATS/JetStream or Temporal for cross-hub protocol
|
||
- Ollama / local LLM agents routed through control plane (Intelligence)
|
||
|
||
### Recommended Next Steps (30-day plan)
|
||
|
||
Week 1: Create Canon Hub repo + write the 10 non-delegable policies (including “AI must go through control plane”).
|
||
Week 2: Spin up minimal Kubernetes + ArgoCD + the four hubs as simple operators/portals.
|
||
Week 3: Implement the cross-hub contract (5 generic functions).
|
||
Week 4: Seed first operational workload + first AI agent (coding assistant) and prove it cannot bypass governance.
|
||
|
||
If you follow this integration path you will have a **genuinely autonomous, viable, auditable, rebuildable organization + infrastructure** that grows recursively without collapsing into central mud or fragmented drift — exactly what both standards promise.
|
||
|
||
Both documents are still “Draft Standard” (v1.0). Treat them as living artefacts: version them inside the Canon Hub and evolve them together as your system learns. That is the ultimate recursive move.
|