Introduction and Purpose (CEM-000)

The Catalyx Engineering Manifest (CEM) defines concise, enforceable recommendations to ensure consistency, accelerate adoption via reusable blueprints, and formalize business intent using state machines for Outcome Driven Development (ODD).

Emphasis

  • Unique IDs: Each recommendation has a stable, traceable identifier.

  • Versioned Rules: Recommendations evolve independently via versioning.

  • Actionable Blueprints: Rules are paired with ready-to-use repositories.

  • Formal Intent: Outcomes are modeled with machine-readable state machines.

Getting Started (CEM-000-000)

Back decisions with a CEM rule ID wherever possible:

  • PR reviews

  • Git hooks

  • Technology choices (e.g., vector store database)

If a rule is missing or needs refinement, see CEM-000-001.

Contributing (CEM-000-001)

To add or refine a rule, follow CEM-001-000.

Warning

Maintenance Overhead

Use existing sessions (e.g., architecture reviews) to update the manifest immediately when decisions are made.

Note

Specifications, not Rules

Follow recommendations, but alternative implementations are welcome if you document the choice and inform the team.

Agent Ingestion Guidelines (CEM-000-002)

Keep agent-loaded specs minimal and enforceable:

  • Write enforceable specs in CEM-###-###.rst files only.

  • Put context, rationale, and examples in CEM-###.rst (ignored by agent).

  • Build exports only CEM-###-###.rst into manifest.json; CEM-###.rst remains for humans.

Include (examples):

  • Prescriptive rules the agent must enforce.

  • Type-safety requirements for external data.

  • Architectural constraints (ports/adapters; depend on interfaces).

  • State management rules (immutability; dedicated UI stores).

Exclude (examples):

  • Non-actionable tooling preferences.

  • Cadence, meeting notes, or narrative rationale.

  • ADRs or historical commentary.

  • Platform choices that do not affect code generation.

Glossary (CEM-000-003)