Skip to content

Schema draft: first-principles company OS plan, primitive specs, compound loop, repo consolidation #2

@moel-kim

Description

@moel-kim

Why

Moel dropped a scattered but strong set of constraints in Slack. This issue turns that into a single discussion packet and executable todo thread.

Core thesis

We should design this as a first-principles company substrate, not as a bundled AI chat product.

Key constraints:

  • CLI must be atomically decomposed.
  • Data must be atomically decomposed so compositions can change without forced migrations.
  • Compound loop and reflection pipeline must be explicit.
  • CEO / chief / lead / worker role allocation must be encoded.
  • Repo consolidation and rename planning should be intentional.
  • DECISION.md should exist near code boundaries so future models can rebuild from design intent.
  • Backup / rollback plan is mandatory.

Drafts added locally

  • DECISION.md
  • docs/company-os-schema-draft.md
  • specs/action-primitives.schema.json
  • specs/memory-state-machine.yaml
  • specs/persona-object.schema.json
  • specs/compound-event-engine.yaml

Proposed todo breakdown

0. Alignment

  • Confirm this repo is the target substrate for the broader company OS direction
  • Confirm monorepo-first vs submodule fallback
  • Confirm whether agenthub stays the engine name or becomes umbrella product name

1. Primitive layer first

  • Finalize Action Primitive Catalog
  • Finalize Memory State Machine
  • Finalize Persona Object Schema
  • Finalize Compound Event Engine
  • Add validation tests for each

2. Storage and migration boundary

  • Refactor canonical schema around atomic records
  • Separate append-only event log from derived read models
  • Define additive migration policy and supersession semantics

3. CLI decomposition

  • Split commands so each one is one bounded mutation/query
  • Map all CLI commands to primitive catalog
  • Keep convenience wrappers as compilations, not hidden multi-write commands

4. Org / approval model

  • Encode CEO / chief / lead / worker role bindings
  • Add explicit approval requests for strategic / money / irreversible actions
  • Add mention-routing for missing ownership and required consensus

5. Compound loop / retrospection

  • Add work-end reflection primitive
  • Add repeated-signal promotion flow
  • Add contradiction detection and supersession flow
  • Let reflections mutate memory / policy / persona recommendations
  • Reference the daangn-work-end and kromakey-work-end pattern explicitly

6. Repo consolidation and naming

  • Inventory current repos by role
  • Decide merge candidates vs detached components
  • Draft rename sequence and compatibility aliases
  • Use submodules only where boundaries are genuinely stable

7. Reliability

  • Nightly DB snapshot
  • Append-only event export
  • Bare git mirror backup
  • Restore drill in clean environment
  • Emergency runbook with rollback thresholds

Socratic gap checks

  1. What is the smallest irreversible mutation?
  2. Which facts are canonical vs cached views?
  3. What should still work if UI disappears?
  4. Which commands are secretly doing more than one thing?
  5. Which memory promotions would become harmful if automated?
  6. Where are we still designing around Slack instead of around company primitives?
  7. Which decisions truly need CEO approval?
  8. What must be preserved so a better future model can rebuild the system?

Munger-style failure paths

  • beautiful concept map, weak machine-readable substrate
  • persona devolves into fancy prompts
  • compound loop devolves into hoarding
  • repo merge creates a confused monolith
  • approval model stays implicit
  • reflection remains notes-only and changes nothing
  • rename breaks continuity

Suggested owners

  • CEO: strategy, rename, consolidation, irreversible policy approval
  • Chief architect: primitive boundary integrity
  • Platform lead: event substrate, approvals, persona runtime contract
  • Data lead: canonical schema, additive migration strategy, backup portability
  • CLI lead: command decomposition and composability
  • Learning-loop lead: reflection, promotion, contradiction handling
  • PM/operator: todo routing and consensus packetization

Mentions needed

I think this now needs owner assignment + argument on:

  • repo strategy
  • primitive-first sequencing
  • compound loop implementation surface
  • rename timing
  • backup expectations

@moel-kim please assign the right people to debate each section, especially whoever should own data boundary / CLI decomposition / learning loop.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions