Imported from calumgwillam/empire-os (AGENTS.md). Install upstream with npx skills add calumgwillam/empire-os. Copyright stays with the author.

EMPIRE OS — GOVERNING INSTRUCTIONS

1. PURPOSE

Empire OS is the central operating system for the entire organisation.

Its purpose is to make sure important information, decisions, ideas, systems, lessons, opportunities, problems, standards, metrics, responsibilities and strategic thinking are captured, structured and retained instead of being lost in memory, messages or disconnected documents.

The system must help increase the probability of building an exceptionally successful, durable and scalable empire.

2. SUPREME OBJECTIVE

The highest-level objective is:

Maximise long-term empire value above everything else, subject to legal, ethical, safety and reputational boundaries.

Short-term revenue, convenience, growth, speed or tradition must never automatically override long-term empire value.

3. LONG-TERM OUTCOME

The organisation is being built to create:

• extraordinary financial wealth
• extraordinary time leverage
• durable and autonomous core businesses
• strategic freedom to pursue side quests, experiments and future ventures
• institutional intelligence that compounds over time

The founder should remain able to actively develop any part of the empire, but the empire must not depend on the founder being constantly present.

Founder involvement is desirable when it creates value. Founder dependency is a weakness to be reduced.

4. CORE PILLARS

The three current core pillars are:

1. Garden Maintenance
2. Hard Landscape Construction
3. Excavation

These pillars should eventually become highly systemised, measurable, resilient and capable of operating at a high level without constant founder intervention.

Future ventures and side quests may be added when sufficient financial and time leverage has been earned.

5. FOUNDER ROLE

The founder’s highest-level role is orchestration.

This includes dynamically directing attention, authority, capital, systems, people and strategy toward the areas where intervention creates the greatest long-term empire value.

The founder must not become an unnecessary operational bottleneck.

The system should eventually help answer:

“Where should founder attention go now?”

6. SYSTEM DESIGN PHILOSOPHY

Empire OS must be built according to these principles:

• nothing important should exist only in memory
• important information must be captured and structured
• information should be linked to decisions, actions, systems, people and outcomes where relevant
• important decisions must preserve their reasoning and later outcomes
• the organisation should learn from mistakes and successes
• knowledge should become institutional rather than person-dependent
• the system should reduce ambiguity
• the system should increase visibility
• the system should improve accountability
• the system should support controlled delegation
• the system should preserve top-level authority
• the system should scale without becoming chaotic
• simplicity is preferred over unnecessary complexity
• architecture must remain capable of supporting very large future scale

7. DEVELOPMENT PHILOSOPHY

Use this cycle:

Build → Operate → Observe → Learn → Refine → Standardise → Automate

Do not overbuild speculative features before operational reality justifies them.

Do not create fake precision.

When the correct answer is not yet known, preserve flexibility and mark the question as unresolved rather than forcing a premature decision.

8. INFORMATION PRINCIPLE

Nothing important should be allowed to disappear.

Important items may include:

• ideas
• observations
• opportunities
• problems
• risks
• decisions
• actions
• knowledge
• lessons
• standards
• systems
• SOPs
• metrics
• evidence
• strategic questions
• responsibilities
• projects
• people-related information
• customer information
• supplier information
• financial information
• assets
• operational data

The structure for these categories may evolve as the system develops.

9. DECISION RECORDS

Major decisions should eventually preserve:

• what was decided
• who decided it
• when it was decided
• why it was decided
• evidence considered
• alternatives considered
• assumptions made
• expected outcome
• review date where relevant
• actual outcome after review

The purpose is to build a long-term database of organisational judgment.

10. ORGANISATIONAL LEARNING

Problems should not merely be fixed.

Where appropriate, problems should lead to:

Observation → Analysis → Decision → System Improvement → Training → Measured Result

Repeated mistakes should be treated as evidence of a weak system.

Lessons must be retained so the organisation does not repeatedly relearn the same thing.

11. ACCESS AND AUTHORITY

The founder has total system visibility.

Employees should have only the access relevant to their responsibilities.

The system must support role-based access in the future.

Delegated authority must never imply loss of ultimate top-level authority.

The exact governance model is intentionally unresolved and should be designed gradually as the organisation develops.

12. MOBILE AND FIELD USE

The system must eventually support mobile use.

Field workers should be able to submit relevant information such as:

• observations
• problems
• photos
• job completion information
• customer notes
• materials used
• equipment issues
• opportunities
• incidents

Important field information should enter the organisational system rather than disappear into informal messages.

13. AI PRINCIPLE

AI should operate on structured organisational truth.

AI must not become the sole source of organisational truth.

The underlying system should store the actual data, decisions, responsibilities, systems and history.

AI should sit above that structure to help:

• summarise
• detect patterns
• surface risks
• identify overdue actions
• identify repeated problems
• identify contradictions
• find duplicate ideas
• prepare leadership briefings
• support decision-making
• identify where founder attention may be most valuable

14. RELATIONAL THINKING

Empire OS should not become a collection of disconnected folders.

Where useful, information should connect logically.

Examples:

Idea → Evaluation → Decision → Project → Outcome

Problem → Investigation → Decision → SOP Change → Training → Result

Observation → Customer → Opportunity → Follow-up → Revenue

Task → Project → Strategic Objective → Business Pillar → Empire Objective

The system should increasingly represent how the organisation actually operates.

15. QUALITY STANDARD

This project is extremely important.

Do not make casual architectural decisions.

When proposing major changes:

1. explain what is being proposed
2. explain why
3. explain what problem it solves
4. explain the tradeoffs
5. explain how it supports long-term empire value
6. avoid implementing irreversible structure without sufficient reasoning

The system should be built to an exceptionally high standard.

16. CURRENT OPERATING RULE

At this stage:

• preserve flexibility
• avoid premature complexity
• document important reasoning
• build strong foundations
• prioritise usefulness over appearance
• avoid building dashboards merely because they look impressive
• let real operational use reveal what deserves automation or prominence

17. OPEN QUESTIONS

The following areas are intentionally unresolved and should be developed over time:

• detailed governance and authority structure
• exact executive dashboard
• exact decision rights for senior leaders
• exact opportunity evaluation framework
• exact side-quest thresholds
• exact KPI architecture
• exact organisational structure
• exact founder-attention model
• exact autonomy thresholds for each division
• exact 30-day founder-absence operating standard

Do not treat unresolved areas as settled facts.

18. CORE RULE

If a proposed feature, process or architectural decision does not improve clarity, execution, learning, resilience, leverage, scalability or long-term empire value, question whether it belongs in Empire OS.