Skip to content

Bluefly Factory OS Constitution

Load Order

1. Constitution

  • governance/constitution.md (This document)

2. Axiom

Bluefly owns composition. Bluefly does not own implementation.

Every future decision is tested against this statement. The moment someone proposes building a scheduler, agent runtime, chat framework, orchestration engine, workflow engine, or any system that an upstream already provides — the Axiom rejects it.

Applied to this repository specifically: documentation-implementation-boundary-contract.md extends this Axiom with directory-level rules for what BluCity-Docs may and may not contain.

Bluefly assembles systems into products. Bluefly does not rebuild systems.

IV. Authority Order

Rank Document Role
1 Bluefly Constitution Root authority. Defines mission, axioms, architecture, boundaries, rules.
2 Product Contracts (products/*.yaml) What the customer buys. Outcome bundles.
3 Factory Contracts (factories/*.yaml) How Bluefly manufactures the product.
4 Generated Outputs Projections of authority. Never hand-edited. Never authoritative.
5 Implementation Systems Upstream systems. Bluefly uses them; Bluefly does not own them.

Conflict resolution: If two documents disagree, the higher authority wins. No exceptions.

Generated projections are runtime-specific views of durable authority. They may include agent instructions, machine-readable capability manifests, LLM context documents, onboarding documentation, CI/CD pipeline definitions, infrastructure manifests, and OSSA agent manifests.

Generated projections are never independent authority. If a projection conflicts with this Constitution, the Engineering Standard, or official upstream documentation, the projection is wrong.

Durable Authority vs Generated Projection

Humans edit durable authority. Machines generate projections.

Durable Authority (authored) Generated Projection (compiled)
Portfolio / Product / Factory Product catalog, deployment manifests
Contracts, Constitution, Glossary Validation schemas, API schemas
Agent object agent.toml, prompt.template.md, OSSA manifest
Capability Capability manifest
Policy Cedar rules
Pack definition pack.lock, city.toml

A published definition declares intended dependencies, interfaces, or configuration. A generated artifact records the result of a specific execution event. A generated artifact MUST NOT be reported as though it were an authoritative declaration.

Published definition (intent) Generated artifact (event)
package.json package-lock.json
Terraform configuration Terraform state
Kubernetes manifests Live cluster state
CI definition (.gitlab-ci.yml) CI job log

Corollary: a declaration is not an execution. A CI definition states what would run; a job log states what did. The workflow is edit durable authority → compile → projection, never edit the projection.

V. Frozen Architecture

PRODUCT
  ↓
FACTORY
  ↓
OUTPUTS
  ↓
PLANES
  ↓
SYSTEMS

The Primary Rule: If a proposed feature cannot be expressed as Product → Factory → Output → Capability → System, it is being implemented at the wrong layer.

The Factory Test: "Which Factory emits it?" If no Factory emits it, it does not belong in the platform.

VI. Ownership Model

What Bluefly Owns

  • Products — what customers buy
  • Factories — how products are manufactured
  • Outputs — generated artifacts organized by plane
  • Composition — the assembly of systems into products

What Bluefly Does Not Own

  • Runtime execution (Gas City)
  • Memory authority (ContextControl)
  • Contract authority (ContractPlane)
  • Policy authority (Cedar)
  • Verification authority (Dragonfly)
  • Compliance authority (Compliance Engine)
  • Business authority (Drupal)
  • Marketplace infrastructure
  • Agent execution runtimes
  • Orchestration frameworks

VII. Planes

Planes are ownership boundaries. Each plane answers one question and has one implementation authority. Bluefly owns composition across all planes. Bluefly does not own any plane's implementation.

Plane Question Authority
Business Authority What is true? Drupal
Governance What is allowed? ContextControl / Cedar / Dragonfly / ContractPlane / Compliance Engine
Runtime What executes? Gas City
Experience What is seen? Canvas / AGUI / OpenClaw / Dashboard
Network What moves? A2A ecosystem
Delivery What deploys? GitLab / IaC
Marketplace What sells? Marketplace infrastructure

Plane Rules

  1. No Factory compiles directly to a System — every compilation passes through an Output.
  2. Outputs are generated, never authoritative.
  3. Each plane has exactly one implementation authority (Governance is a federation of five).
  4. Bluefly composes across planes. Bluefly does not implement within planes.

VIII. Authority Separation

Six separate authorities. Never collapsed. Never merged. Never replaced.

Authority Owner Scope
Business Drupal Content, structure, workflows, templates, recipes, permissions, business facts
Memory ContextControl Governed context, verification, lineage, retraction, sovereignty, retention
Contract ContractPlane API contracts, schema registry, integration governance, evidence
Policy Cedar Authorization for governed actions, fail-closed enforcement
Verification Dragonfly Fail-closed output verification, quality gates
Compliance Compliance Engine Framework evidence collection (HIPAA, SOC 2, WCAG, FedRAMP)

IX. Experience Surfaces

Four surfaces. Four audiences. Never collapsed into a single interface.

Surface User Role Question
Canvas Factory Builder Factory Authoring Experience "How do I author a Factory?"
AGUI Factory User Factory Runtime Experience "How do I use the product?"
OpenClaw Factory Operator Factory Operator Experience "What's happening right now?"
Dashboard Factory Admin Factory Infrastructure Experience "What's running underneath?"

Experience Rules

  • AGUI is the primary Factory Runtime Experience. Extend, compose, govern, deploy. Never replace.
  • Do not build: Ask Blu UI, Agent Console, AI Dashboard, Chat Framework, Custom Runtime UX.
  • Canvas is the Factory Authoring Experience. Factories are authored in Canvas.
  • OpenClaw is the operator view. It never owns policy, memory, deployment, or configuration.
  • Dashboard is the infrastructure view. Gas City owns it.

X. Gas City Boundary

Factory is a Bluefly primitive. Factory is NOT a Gas City primitive.

Factory compiles INTO Gas City primitives:

Factory → Pack → Formula → Order → Agent → Bead

Gas City Rules

  1. Never create orchestrators, workflow engines, schedulers, supervisors, or runtime frameworks.
  2. Gas City owns: cities, packs, formulas, orders, agents, beads, event streams, execution.
  3. Bluefly compiles into these primitives. Bluefly does not recreate them.
  4. Formula-first. Oracle-first. Mac is console only, never runtime.
  5. Gas City is the platform. Gas Town is a pack. Never conflate them.

XI. Compilation Rules

Product Contract

The customer buys a Product. The customer does not buy technology. Products are outcome bundles.

A product.yaml defines:

  • SKU and title
  • Industry vertical
  • Personas (who uses it)
  • Outcomes (what they get)
  • Constraints (what must be true)
  • Pricing model
  • Marketplace listing
  • Reference to the Factory that manufactures it

Factory Contract

A Factory is a declarative manifest that composes existing primitives into one sellable, deployable, governed unit.

A factory.yaml defines:

  • Metadata (name, version, base factory, specialization, product reference)
  • Outputs organized by plane (Business Authority, Governance, Runtime, Experience, Network, Delivery, Marketplace)
  • Compilation table (field → generated artifact → owning system)
  • Conformance declaration

Compilation Chain

product.yaml  →  factory.yaml  →  outputs (per plane)  →  systems
     ↑                ↑                    ↑                  ↑
  customer         Bluefly            generated          upstream
   buys           authored           never edited        owns impl

Conformance

A factory.yaml MUST:

  1. Reference a product.yaml (the customer buys a Product, not a Factory)
  2. Emit Outputs organized by Plane
  3. Be the single authored source; all downstream artifacts generated
  4. Declare authority template + at least one recipe
  5. Import bluefly-core-pack + bluefly-governance-pack
  6. Bind Cedar (fail-closed), ContractPlane evidence (fail-closed), ContextControl memory contract
  7. Define all 7 lifecycle verbs (create, deploy, verify, operate, upgrade, recover, decommission)
  8. Register in OSSA + DUADP
  9. Run on Gas City on Oracle; persist to NAS; no laptop dependency
  10. Introduce zero custom orchestration — compile to existing primitives
  11. Bluefly owns composition; never implementation
  12. No Factory compiles directly to a System — every compilation passes through an Output

XII. Open-Source-First Rules

Before writing any custom code, evaluate against this checklist:

  1. Does a Drupal contrib module exist? Use it.
  2. Does a Gas City primitive exist? Compile to it.
  3. Does an upstream tool exist? Integrate it.
  4. Does an open standard exist? Adopt it.
  5. Is there a community-maintained solution? Prefer it.
  6. Can existing primitives be composed? Compose them.
  7. Would a Drupal recipe solve it? Write a recipe, not a module.
  8. Would a Cedar policy solve it? Write a policy, not code.
  9. Would a Gas City formula solve it? Write a formula, not an orchestrator.
  10. After exhausting all of the above — and only then — write custom code with explicit authorization.

De-customization Rules

  • Do not create new PHP classes, services, or plugins without authorization.
  • 7-layer mandatory contrib inventory before any custom AI code.
  • No code changes, no commits, no MRs until operator decision is explicit.
  • Every custom module must have a canonical home in the repo structure.
  1. Would this be better represented as durable authority and compiled into the required runtime artifact? If yes, author the authority and compile the artifact. Do not hand-write the artifact.

Capability Convergence Order

The smallest stable upstream owner owns the capability:

  1. OpenClaw
  2. Gas City SDK
  3. Gas City Pack
  4. Gas Town (migration compatibility only)
  5. Existing upstream OSS project
  6. Bluefly composition layer
  7. New Bluefly code — LAST RESORT, requiring documented proof that 1–6 cannot own it.

The objective is net-negative ownership, not better custom architecture. Every change states whether Bluefly now owns more or less. The correct direction is less.

Capability Decomposition

Capability ownership is resolved at the smallest independently ownable unit. Never ask "who owns skills?" — ask who owns the schema, the compiler, the bundler, the installer, the registry, the distribution, the runtime, and the content. The answer is almost never a single owner. Ownership is assigned per part, with evidence, in the standard form:

Capability Part Authority Evidence State

State is one of: SUPPORTED (upstream owns it) · PARTIAL (upstream owns most) · NOT FOUND (no owner identified) · LEGITIMATE (Bluefly owns the gap, with proof).

XIII. Product Strategy

The Product Chain

Customer → Product → Factory → Output → System

The customer never interacts with Factories, Outputs, or Systems. The customer interacts with the Product.

Vertical Factories

AMCS (Agent Managed Content System) is the base Factory. Vertical Factories are specializations:

  • AMCS Healthcare
  • AMCS Higher Education
  • AMCS Nonprofit
  • AMCS Municipality
  • AMCS SaaS
  • AMCS Membership

Each vertical Factory inherits from the AMCS base and adds industry-specific content models, compliance constraints, recipes, and policy packs.

Revenue Model

Revenue Stream Model Description
Product License Annual Factory + templates + recipes + governance
Per-Site Provision Per-instance Factory execution: product → running platform
Managed Lifecycle Monthly Upgrades, backups, security, compliance monitoring
ContextControl Addon Monthly Governed AI memory
Custom Recipe Project SOW Bluefly builds a custom recipe for specific capability

Marketplace

The marketplace sells Factories. Never technology. OSSA registration + DUADP discovery + Wasteland compatibility.

XIV. Design Rules

  1. No infrastructure deliverables. Never deliver Docker plans, Kubernetes plans, Terraform plans, Oracle plans, infrastructure diagrams, or runtime designs. Deliver product.yaml and factory.yaml.

  2. No demo slop. No mock HTML, throwaway simulations, custom framework code. Real production code. API-first. DRY.

  3. No root file dumps. Every file has a canonical home in the repo structure. Never create files in project root.

  4. Single source of truth. No sprawl. No parallel specs. No duplicate architecture documents. One Constitution. One Product contract per product. One Factory contract per factory.

  5. Audit-first workflow. DISCOVER → PROVE → PLAN → PATCH → TEST → RELEASE → RECEIPT.

  6. Receipts. Durable work state and receipt metadata belong in Beads; build and deployment evidence is published as GitLab job artifacts. Temporary local captures belong only in Scratch/.

  7. The 2-Hour Rule. If it cannot be demoed, proven, or sold in 2 hours, it is not the next task.

  8. Composition over creation. Always compose existing primitives before creating new ones.

  9. Fail closed. Cedar, ContractPlane evidence, and Dragonfly verification are fail-closed by default. Never fail-open.

  10. Mac is console only. The operator's laptop is a console. It is never runtime. All execution runs on Oracle via Gas City.

XV. Agent Rules

  1. Separation of Duties. Agents have trust tiers (T1–T4). No agent may approve its own work. The executor is never the approver.

  2. governedWrite(). Every memory write follows: Cedar enforce → GAID mint → Drupal ai_context persist → Qdrant vector upsert → DUADP broadcast. No direct writes.

  3. Dragonfly fail-closed. Every agent output routes through Dragonfly verification before delivery. If Dragonfly is unreachable, the output does not pass.

  4. OSSA identity. Every agent has an OSSA manifest, a GAID, and is registered in DUADP. No unregistered agents.

  5. Cedar policy evaluation. Every tool call and write is evaluated against the agent's Cedar policy pack before execution.

  6. trace_id discipline. Every execution chain carries a trace_id. Format: <session_id>:<execution_uuid>. Required on every request.

  7. Secret interception. All agent I/O passes through the ContractPlane secret interception stack before hitting any persistence layer.

  8. Builder Mode. Default operating mode: propose before mutating. Preflight block required before any change. Checkpoint every 3 tool calls.

  1. Authority Check — the first gate. Before any edit, and before the worktree: What capability is changing? What is the smallest independently ownable unit? Who is the current authority? What evidence supports that? Does an authoritative implementation already exist? Is Bluefly adding composition or replacing ownership? Is the change BUILD, VALIDATE, CONVERGE, or AMEND? Execution order: Bead → Authority Check → canonical worktree → minimal edit → repository verification → commit → push → verify SHA → merge request → destroy worktree.

  2. Discovery changes work. New evidence immediately invalidates obsolete implementation plans. If evidence proves the thing already exists, the work item changes from BUILD to VALIDATE → CONVERGE → AMEND. Construction never remains the default. Superseded work is closed as superseded by discovery — not as wrong.

  3. Completeness before absence. Truncation is not evidence of absence. A head, a grep, a partial search, a crashed sweep, or a timed-out query may only produce UNKNOWN. Absence may be asserted only after completeness is verified (a full heading list, a full ref enumeration, a complete inventory). An unexpected metric is a hypothesis, not a finding.

  4. Repository gates are mandatory. Pre-commit hooks, pre-receive hooks, deletion guards, branch-name rules and secret scans are governance, not obstacles. They are never bypassed: no --no-verify, no emergency override hooks, no force-push. A gate that blocks an agent is the gate working. Deletion order is Evidence → Candidate deletion → Verification → Human approval → Deletion, never Evidence → Deletion.

  5. Reporting discipline. Every change reports OBSERVED (artifacts actually inspected, anchored to the artifact — never to implied history), INFERRED (bounded strictly by those artifacts; never drifting into a recommendation), DECISION, NOT VERIFIED (distinguishing lack of evidence from lack of access), and BLOCKING (stated only at the contract boundary). Every promoted conclusion declares its measurement boundary and its verification boundary.

XVI. Delivery Rules

  1. Pipeline-ready. Every implementation is pipeline-ready. Linting, static analysis, tests, security scans, artifact versioning, environment promotion, rollback plan.

  2. GitLab-native. Prefer GitLab CI components, reusable templates, and environments. No manual deployment paths. No SSH-and-deploy.

  3. No laptop dependency. Everything deploys to Oracle via Gas City. The laptop triggers; it does not host.

  4. Attestation chain. SLSA provenance + SBOM + vulnerability scan + ContractPlane policy attestation + cosign signature. No promotion without complete attestation.

  5. Branch policy. Never commit to main, master, development, or release/*. Feature branches only. MR required. No force push. No skip hooks.

XVII. Governance of This Document

Amendment Process

  1. Only Thomas Scola may amend this Constitution.
  2. Amendments are versioned. Prior versions are archived, not deleted.
  3. No agent, generated document, or downstream artifact may contradict this Constitution.
  4. If a contradiction is discovered, the Constitution wins and the contradicting document is corrected.

Review Rule

Any document that contradicts the Constitution is wrong. The correct response is to update the document, not reinterpret the Constitution.

The Test

When an agent drifts, when a proposal seems wrong, when architecture is unclear:

"Show me where your proposal fits in the Constitution."

If it cannot, it is off track.

Bluefly.io — Governed digital organizations, manufactured on demand.

XIII. Definitions vs Events

Published definitions declare intended dependencies, interfaces, or configuration. Generated artifacts record the result of a specific execution event.

Generated artifacts MUST NOT be reported as though they were authoritative declarations.

Published definition (intent) Generated artifact (event)
package.json package-lock.json
Terraform configuration Terraform state
Kubernetes manifests Live cluster state
CI definition (.gitlab-ci.yml) CI job log
Source configuration Generated code

Corollaries

  • A declaration is not an execution. A CI definition states what would run; a job log states what did. Reporting the former as the latter is a category error.
  • A missing observation is not an observation of absence. Absence from a queryable system is not evidence of absence in an unqueryable one.
  • An unexpected metric is a hypothesis, not a finding. Re-derive it from raw data before acting; place the gate inside the command, not in the reasoning layer.

Claim Semantics — canonical taxonomy

This is the one claim taxonomy for the platform. Any other classification scheme found in any repository, rule file, skill, or generated projection (including prior wording of this Article, verification-ledger.md's legend, or per-workstation agent rule files) is superseded by this section on conflict — correct the other document, do not reinterpret this one. Four states, exhaustive:

  • OBSERVED — directly inspected by the reporting agent from an identified source. Anchor to project/service, path/endpoint, exact ref/SHA/deployment identity/runtime timestamp, the command or request used, and the scope examined. Never anchor to implied history ("the version examined before commit contained X", not "X previously contained…").
  • REPORTED — supplied by another agent, person, pipeline, artifact, or prior receipt, but not independently inspected by the reporting agent. Attribution MUST be preserved. A REPORTED claim MUST NOT be silently promoted to OBSERVED.
  • INFERRED — a conclusion derived from OBSERVED or REPORTED evidence. State the evidence and the reasoning. An inference MUST NOT be presented as direct observation, and MUST NOT drift into a recommendation.
  • NOT_ESTABLISHED — evidence is missing, contradictory, stale, incomplete, or drawn from a scope that cannot support the requested conclusion. This is a correct terminal state. It MUST NEVER be rewritten as PASS, VERIFIED, COMPLETE, HEALTHY, RESOLVED, or NO ISSUE FOUND unless new evidence establishes that state.

DECISION and BLOCKING remain as receipt fields (below), not claim states — a decision is an action taken on top of classified claims; blocking is stated only at the contract boundary.

Provenance-or-Refusal

No agent may certify a consequential claim without enough provenance to support its exact scope. A certification MUST answer: what source was inspected; what project, path, endpoint, or runtime; what exact ref/SHA/deployment/database/process identity; what command or API produced the result; what population or scope was examined; what was skipped and why; whether the skipped coverage could change the conclusion; what result would have forced refusal; and whether the evidence was independently reproduced.

If skipped or unknown coverage could change the conclusion, the correct outcome is CERTIFICATION=REFUSED_UNKNOWN_COVERAGE — not a manufactured percentage over an unknown denominator, and not silence. Refusing estate-wide certification does not invalidate a correctly bounded finding: e.g. 85 accurately examined merge requests do not establish estate-wide coverage if the project inventory came only from local clones — report the 85 bounded results, the incomplete inventory source, the missing coverage, and refuse certification, all at once.

A control must produce provenance or refuse to certify. Unknown coverage is not success. A detailed report is not evidence by itself. A green pipeline is not proof that meaningful work ran. A running process is not proof of a healthy service. A receipt marked COMPLETE is not proof that acceptance occurred. Refusal at an authority boundary is correct; idling before the boundary is not.

Doctrine Promotion Lifecycle

A rule earns enforcement; it is not declared into existence. Every ruling begins with a real incident and is promoted only after evidence supports the next stage:

CUSTOM → ADVISORY → WARNING → WRITTEN LAW → MECHANICAL ENFORCEMENT → PROVEN ENFORCEMENT

No agent or document may claim the final state (PROVEN ENFORCEMENT) until the enforcement mechanism has itself been shown to produce provenance of its own coverage — a hook that exists is MECHANICAL ENFORCEMENT; a hook shown, with evidence, to catch what it claims to catch is PROVEN ENFORCEMENT. Owned case law (Article XIII Evidence Packet rows, ADRs) should grow over time; duplicated and bespoke substrate should shrink. Bind authoritative state — reference it — rather than copying it into a second, parallel authority.

Receipt Rules

Engineering receipts use the following fields. Update existing receipt templates in place (ledger/verification/verification-ledger.md, Engineering-Standard/verification/definition-of-done.md, and any per-repository receipt format) to this shape — do not create a parallel receipt format:

CLAIM=
CLASSIFICATION=OBSERVED|REPORTED|INFERRED|NOT_ESTABLISHED

SOURCE_SYSTEM=
PROJECT_OR_SERVICE=
PATH_OR_ENDPOINT=
REF_OR_RUNTIME_IDENTITY=
COMMAND_OR_API=

SCOPE_REQUESTED=
SCOPE_EXAMINED=
SCOPE_SKIPPED=
SKIP_REASON=
COVERAGE_COMPLETE=YES|NO

EVIDENCE=
DECISION=
REFUSAL_CONDITION=
REFUSAL_TRIGGERED=YES|NO

INDEPENDENT_VERIFICATION=
AUTHORITY_USED=
MUTATIONS_PERFORMED=

CERTIFICATION=PASS|FAIL|REFUSED_UNKNOWN_COVERAGE|NOT_ESTABLISHED

BLOCKING (prior wording) maps to REFUSAL_TRIGGERED=YES with REFUSAL_CONDITION stated — state it only at the contract boundary, never drifting into why an interface is unavailable. SCOPE_REQUESTED / SCOPE_EXAMINED together are the measurement boundary; SCOPE_SKIPPED + SKIP_REASON + COVERAGE_COMPLETE=NO together are the verification boundary. Never report an ownership reduction, or any consequential claim, until both boundaries have been measured and stated.

XIV. Execution Contract

Binding on every agent — not one vendor, not one model, not one session. Every engineering change SHALL pass this contract, and every agent SHALL be judged against it.

1. Authority Check — the first gate, before any edit

  • [ ] What capability is changing?
  • [ ] What is the smallest independently ownable unit of it?
  • [ ] Who is the current authority?
  • [ ] What evidence supports that?
  • [ ] Does an authoritative implementation already exist?
  • [ ] Is Bluefly adding composition, or replacing ownership?
  • [ ] Is the proposed change BUILD, VALIDATE, CONVERGE, or AMEND?

The gate runs before the worktree, not after the edit:

Bead → AUTHORITY CHECK → canonical worktree → minimal edit → repository verification
     → commit → push → verify SHA → merge request → destroy worktree

2. Discovery Check

Discovery changes work. New evidence immediately invalidates obsolete implementation plans. If evidence proves the thing already exists, the work item changes from BUILD to VALIDATE → CONVERGE → AMEND. Construction never remains the default.

3. Capability Decomposition

Capability ownership is resolved at the smallest independently ownable unit. Never ask "who owns skills?" — ask who owns the schema, the compiler, the bundler, the installer, the registry, the distribution, the runtime, and the content. The answer is almost never a single owner.

4. Smallest Stable Owner

The smallest stable upstream owner owns the capability. Priority order:

  1. OpenClaw
  2. Gas City SDK
  3. Gas City Pack
  4. Gas Town (migration compatibility only)
  5. Existing upstream OSS project
  6. Blu composition layer
  7. New Blu code — LAST RESORT, requiring documented proof that 1–6 cannot own it.

5. Convergence over Construction

The objective is net-negative ownership, not better custom architecture. If a Blu component can become a Pack, Skill, Plugin, Order, Formula, Doctor Check, Overlay, or Agent — migrate it. Every change states whether Bluefly now owns more or less. The correct direction is less.

6. Evidence before Mutation

No mutation without evidence. A declaration is not an execution (Article XIII). An unexpected metric is a hypothesis, not a finding. Deletion order is:

Evidence → Candidate deletion → Verification → Human approval → Deletion

never Evidence → Deletion.

7. Repository Gates are Mandatory

Repository gates — pre-commit hooks, pre-receive hooks, deletion guards, branch-name rules, secret scans — are governance, not obstacles. They are never bypassed. --no-verify, emergency override hooks, and force-push are prohibited. A gate that blocks an agent is the gate working.

8. Report Observed vs Inferred vs Decision

Every change reports OBSERVED / INFERRED / DECISION / NOT VERIFIED / BLOCKING, with a declared measurement boundary and verification boundary (Article XIII).

Evidence Packet — standard form

Capability Part Authority Evidence State

State ∈ SUPPORTED (upstream owns it) · PARTIAL (upstream owns most) · NOT FOUND (no owner identified) · LEGITIMATE (Bluefly owns the gap, with proof).

Automatic Rejection

A change is REJECTED if it adds an abstraction, wrapper, manager, resolver, validator, registry, or platform utility — or recreates orchestration, plugins, workflows, agents, doctor functionality, or command routing — unless it carries documented proof that no upstream owner can own it. No explanation = reject.