Group Constitution
Three clusters. One constitution.
Each cluster owns its domain and competes for resources on evidence. The CEO layer sits above all three and decides where the next euro and engineer go. Clusters compete for resources on evidence. Revenue, a signed pilot or contracted value moves the allocation; an impressive demo does not.
- Energy Intelligence“Create the highest-value deep-tech company.”
- Physical AI & Robotics“Prove whether physical autonomy can create a defensible second moat.”this host
- Operations & Commercial Automation“Make money and build distribution.”
Rules
- There are exactly three strategic clusters. No agent may create a fourth.
- Each cluster owns its domain. Domain logic remains isolated: energy logic is Energy, robotics logic is Robotics, operations logic is Operations.
- No repository moves between clusters without a documented reason, commercial benefit, technical benefit, migration cost, dependency impact and CEO approval.
- Shared primitives are allowed only when genuinely cross-cluster.
- Clusters communicate through versioned APIs, events, schemas, contracts and documented interfaces — never through undocumented database coupling.
- A proposed project that fails two or more of the seven gate criteria is archived.
Every proposed new project must pass
- Customer pain
- Buyer
- Money
- Differentiation
- Technical feasibility
- Strategic fit
- Execution cost
If it fails two or more criteria: archive.
Registers every cluster maintains
- repository registry
- architecture map
- dependency graph
- decision log
- kill list
- roadmap
- customer evidence
- competitive intelligence
- research backlog
- weekly KPI report
On this host: registry, architecture map, dependency graph (per entry), decision log, kill list, roadmap · research backlog, customer evidence, competitive intelligence, weekly KPI report.
What is rewarded
Rewarded
- revenue
- customers
- deployments
- measurable ROI
- technical benchmarks
- proprietary IP
- research quality
- reduced engineering complexity
Not rewarded
- number of commits
- number of repositories
- lines of code
- number of features
- architectural complexity
When uncertain, prefer
- smaller scope
- fewer repositories
- clearer ownership
- faster customer validation
- stronger interfaces
- lower burn
- higher evidence
Mandate of this cluster
Transform the robotics-related repositories into one coherent physical-AI platform. A collection of disconnected robotics demos is explicitly forbidden. Mission: PERCEIVE → MODEL → PLAN → ACT → VERIFY → RECOVER → LEARN, while producing measurable industrial ROI.
Do not build robots because robots are exciting. Find a repetitive physical task where:
- labour is expensive
- task frequency is high
- the environment is sufficiently structured
- failure cost is understood
- automation can be measured
- the customer already has budget
- deployment is technically feasible
Final rule
Do not build a robotics empire. Build one economically superior physical workflow first. Prove it. Then generalise.
- No customer = no scale.
- No benchmark = no performance claim.
- No ROI = no product.
- No safety = no deployment.