Skip to content

Bluefly Factory Operating Model (frozen)

Bluefly is the Factory Operating System for digital organizations. It does not build platforms; it assembles platforms into products. This file is binding for every blu factory skill.

The architecture

PRODUCT  ─▶  FACTORY  ─▶  OUTPUTS  ─▶  DOMAINS  ─▶  SYSTEMS
- Product is what the customer buys (e.g. AMCS Healthcare Factory). It is the root. - Factory is how Bluefly manufactures the product. - Outputs are generated artifacts (authoritative nowhere). - Domains are ownership boundaries, not contract sections. - Systems are the upstreams the outputs compile into.

The rule (hard to violate)

Product → Factory → Output → Capability → System
If a feature can't be expressed this way, it is at the wrong layer. The answer to "let's build another service" is "which Product, which Factory, which Output, which Domain?" No answer ⇒ it does not belong in the platform.

The ownership model (the most important sentence)

Bluefly owns composition. It does not own implementation.

Domain Bluefly owns Implementation owned by
Product product, outcomes, SKU (Bluefly)
Authority composition Drupal, business authority: content, structure, workflows, templates, recipes, permissions, business facts (+ OSSA capability identity, DUADP discovery)
Governance composition ContextControl (memory authority) · ContractPlane (contract authority) · Cedar (policy authority) · Dragonfly (verification authority) · Compliance Engine
Runtime composition Gas City (execution) + agent-docker + agent-buildkit
Experience composition Canvas (authoring) · AGUI (runtime) · OpenClaw (operator) · Gas City Dashboard (infra)
Network composition A2A, agent-mesh / a2a-collector / agent-router / agent-protocol (transport only)
Delivery composition GitLab Ultimate · gitlab_components · IaC · agent-buildkit · agent-docker
Marketplace composition agentic-marketplace · openstandardagents · marketplace.app.drupl.ai

Bluefly never becomes another platform. It becomes the thing that assembles platforms into products.

The four experience surfaces: four audiences (never collapse)

Surface Provider Audience Role
Authoring Canvas Factory Builder creates factories (authors factory.yaml)
Runtime AGUI Factory User operates the factory, the Factory Runtime UX (extended, never replaced)
Operator OpenClaw Factory Operator observe / notify / escalate, no policy/memory/governance/deployment/content authority
Infra Gas City Dashboard Factory Administrator runtime operations, Agents/Beads/Runs/Health

The two diagrams (don't conflate them)

  • Bluefly architecture: Product → Factory → Outputs → Domains → Systems.
  • Gas City execution (compile chain): Factory ─compile▶ Pack ─imports▶ Formula ─instantiates▶ Order ─dispatches▶ Agent ─performs▶ Bead.
  • Factory is a Bluefly primitive. It is NOT a Gas City primitive. Bluefly owns factory; Gas City owns everything below it (Pack/Formula/Order/Agent/Bead/Event/Rig).

Compose, never reinvent

Custom code is the last option. Exhaust Drupal Core/CMS/Recipes/Site-Templates/AI, AGUI, MCP, Gas City, and existing Bluefly capability first. Build NO custom workflow engines, schedulers, supervisors, or orchestration runtimes; those live below the Factory boundary, in Gas City.

The CLI (scripts/factory.py)

  • factory validate <f>: schema-valid.
  • factory reuse <f>: compose-first gate.
  • factory audit <f>: the architecture invariants (Product root, ownership boundaries, four surfaces, fail-closed governance, A2A non-authority). Fail-closed, nonzero on violation.
  • factory plan <f>: the compile graph: Product → Factory → Outputs → Domains → Systems.
  • factory check <f>: all of the above as one CI gate.