Operating Principles from Field Practice

The research pages describe what a modern company operating system should contain. This page adds the rules that repeatedly survived contact with real engineering, product, business, documentation, and technology-intelligence work.

These are operating candidates, not claims that every discussion automatically becomes policy. Each rule should be adopted only when it is useful, observable, and easy to revise.

The five planes

The Company OS should remain separable across five planes:

1. Context — durable knowledge, ownership, decisions, dependencies, and constraints.
2. Execution — people, agents, tools, services, and sandboxes that do the work.
3. Control — routing, budgets, permissions, escalation, and policy.
4. Verification — tests, adversarial review, source corroboration, safety gates, and reconciliation.
5. Delivery — PRs, releases, deployment, observability, and audit trails.

This prevents the business from coupling its context, execution tools, and governance to one model vendor, coding CLI, or agent interface.

The principles

Five operating loops

1. Evidence → decision → documentation

1. State the problem and the decision owner.
2. Gather primary sources, customer evidence, or production data.
3. Mark what is verified versus inferred.
4. Record options, trade-offs, decision, expected outcome, and review date.
5. Update the canonical document and link the supporting evidence.

This prevents a plausible conversation from quietly turning into company doctrine.

2. Customer-funded product loop

1. Find a customer with an expensive, urgent problem and a budget.
2. Sell a narrow outcome, not an undifferentiated platform.
3. Build reusable capabilities in a shared core.
4. Keep customer data and configuration isolated from reusable platform IP.
5. Contract development, licensing, and support as separate concerns.
6. Reuse the resulting capability with the next customer where the problem repeats.

The commercial test is not "can agents build it?" It is "does a specific buyer pay enough for the outcome, and can the capability be reused without turning the company into a services shop?"

3. AI delivery loop

problem and acceptance criteria
        ↓
small, explicit implementation
        ↓
automated checks and focused review
        ↓
independent verification of the actual artifact
        ↓
measured release and feedback
        ↓
document the pattern or failure

Use proportional process:

• Simple/mechanical work: direct execution with a focused check.
• Complex, risky, cross-cutting, or unclear work: reconnaissance, design, implementation, and independent review.
• Research-only work: read-only investigation with no modification rights.
• Shared checkout work: isolate concurrent agents with worktrees or equivalent boundaries.

AI-assisted velocity is only leverage when the verification loop is faster than the cost of repairing silent mistakes. Flat, explicit, convention-driven code helps agents; it does not remove the need for review.

For money-bearing or high-consequence workflows, keep the boundary hard: the model can classify intent or propose an action, while deterministic code performs calculations, validates permissions and dates, records audit events, calls provider webhooks, and requires human approval for ambiguous commitments.

4. Knowledge loop

capture → classify → verify → route to canonical home → cross-link → stale review

The company should distinguish three consumers:

• Human handbook: durable company policy, strategy, and department guidance.
• Operational knowledge base: searchable runbooks, architecture, references, and procedures.
• Agent memory: user preferences, temporal context, and working decisions needed for agent behavior.

Duplicating the same fact across all three creates drift. Link between layers instead of copying blindly.

Evidence pipeline

The knowledge loop needs an explicit evidence pipeline before content reaches a canonical surface:

1. Raw evidence — preserve the original URL, capture/transcript/source file, retrieval date, and relevant hash or version. Do not overwrite the source while synthesizing it.
2. Curated knowledge — turn validated material into entity pages, concepts, comparisons, research summaries, or decisions. Cross-link related ideas and record contradictions.
3. Governance and navigation — register the page in the correct index, assign ownership and review dates, and make its confidence and provenance visible.

This prevents a polished summary from becoming an untraceable source of truth.

5. Technology-intelligence loop

1. Monitor a small set of high-signal sources.
2. Separate fact, interpretation, and speculation.
3. Cross-check material claims and validate links.
4. Limit the briefing to changes that could affect product, cost, risk, or distribution.
5. Convert relevant signals into a decision, experiment, watch item, or explicit ignore.
6. Revisit the prediction after the outcome is known.

A news item is not an input to strategy until it changes what the company should do.

Self-improving company loop

The operating system should connect:

customer interaction
→ evidence
→ knowledge system
→ product/process change
→ measured result
→ updated operating system

This makes the Company OS a learning system rather than a static collection of policies. Every important change should leave behind a decision, evidence, owner, review trigger, and reusable procedure where applicable.

Technology adoption scorecard

Before adopting a tool, model, platform, or protocol, assess:

1. Real task performance, not only benchmarks.
2. Reliability under long-running and failure conditions.
3. Security and isolation model.
4. Cost, latency, quota, and review behavior.
5. Exportability and provider independence.
6. API/protocol stability and deprecation path.
7. Migration and rollback path.
8. Maintenance and ecosystem health.
9. Observability and auditability.
10. Fit with existing context, control, verification, and delivery planes.

Agent-native interface checklist

Every internal capability should be evaluated for whether an agent can:

• Discover it through a structured interface.
• Use explicit schemas and concise outputs.
• Perform idempotent actions where possible.
• Operate under scoped permissions.
• Distinguish read, propose, approve, and execute actions.
• Be tested without fragile browser imitation.

Required controls for the first version

Add these to the initial SOP set:

• Evidence and citation policy — source hierarchy, claim labels, link validation, and a rule against laundering speculation into policy.
• AI delivery quality gate — owner, scope, tests, independent review, and proof of the real artifact.
• Product wedge review — buyer, painful job, willingness to pay, distribution path, and reuse potential before platform expansion.
• Infrastructure risk review — traffic, data sensitivity, RTO/RPO, backup/restore proof, and the trigger for adding operational complexity.
• Exploration log — hypothesis, budget, timebox, result, and whether the company should continue, stop, or productize it.

What was deliberately not promoted

• Individual PR numbers, commit IDs, tool versions, and one-off debugging outcomes.
• Unverified social posts, unattributed quotes, and model-release hype.
• A specific framework treated as universal when the underlying problem has not been observed.
• Headcount or cost multipliers presented as laws rather than planning estimates.
• A platform build justified only by technical elegance instead of a paying customer and a reusable economic model.

Field evidence

The rules above were synthesized from recurring work in these internal sessions:

• Engineering: Fintech Engineering Handbook PR, GitHub PR Workflow, Maestria Hermes Plugin Update, Timezone storage golden rule, and Hermes Agent Server Architecture Breakdown.
• Knowledge: Adding Headscale to LLM Wiki, Initializing Design Engineering Wiki, agentOS Apps Launch Ingested, Penjelasan box.ascii.dev untuk AI Agents, and What Crossplane Is.
• Business: SaaS Tiered Pricing with Overage, SaaS Pricing for Indonesia MSMEs, SaaS Pricing Case Study Analysis, and SaaS Pricing for MSME Market.
• Technology intelligence: PostgreSQL HA Cluster Explanation, Why APIs Fail AI Agents, OpenShip vs Coolify vs Dokploy, Improving Quality and Reducing Noise, and Omnigent Intelligence Briefing.
• Current research thread: the original company-OS research and the subsequent verification of a DeepSeek operating-model claim. The latter is useful as an evidence-policy example: real substance does not make an unattributed quote safe to institutionalize.

Related

• Foundation & First Principles
• Knowledge System
• Decision-Making
• AI-Native Architecture & Delivery
• Product
• The 6 SOPs to Write First
• References