STD-FACT-001: Bluefly Digital Estate Factory Architecture & Product Thesis¶

Status: Approved Governing Standard
Authority: Thomas P. Scola Jr. — Product/Factory Direction
Date: 2026-09-23
Bead: bc-6zns / bc-bwoi

1. Product Thesis¶

Bluefly builds one governed digital-estate operations factory capable of continuously maintaining, securing, updating, upgrading, optimizing, hardening, and migrating complex Drupal estates and other web platforms.

Primary Commercial Wedge: Bluefly Drupal Security & Release Operations¶

The customer promise:

You should not have to think about Drupal security updates, routine core and contributed-module updates, release readiness, or whether those changes were actually safe. Bluefly continuously handles the operation, brings you into decisions that require your authority, independently verifies the result, and keeps the evidence.

This is not a migration factory.
This is not an AI-agent product.
This is not a collection of scripts.
This is not a dashboard.
This is not managed hosting.
It is a governed digital operations factory. Migration is an operational pack inside it.

2. The Four-Layer Product Stack¶

CUSTOMER
    ↓
CONTEXTCONTROL          Customer control room
    ↓
BLUEFLY GOVERNANCE      Identity + Authority + Policy + Approval
    ↓
BLUCITY FACTORY         Gas City orchestration + Beads work graph + Packs + Formulas + Agents
    ↓
CUSTOMER ESTATES        Drupal / GitLab / hosting / cloud / repositories / APIs

These layers must remain strictly decoupled.

3. What the Customer Buys: An Operational Outcome¶

Customers do not buy Gas City, Beads, agents, or formulas. They buy ongoing responsibility for an operational outcome:

SUPPORTED  ·  SECURE  ·  UPDATED  ·  VERIFIED  ·  EXPLAINABLE  ·  RECOVERABLE

Bluefly continuously: 1. Detects core and contrib security advisories & updates. 2. Analyzes dependencies, compatibility, and custom code impact. 3. Formulates a bounded update plan. 4. Validates customer authority and safety policy. 5. Implements updates in source via governed worktrees. 6. Executes static, functional, visual, and behavioral verification. 7. Submits merge requests and verifies CI execution. 8. Obtains required human approvals. 9. Releases through customer deployment pipelines. 10. Verifies post-deploy runtime behavior and records immutable evidence.

4. One Factory Topology¶

Internal Name: Bluefly Digital Estate Factory
Distribution: BluCity
Underlying Orchestrator: Gas City

ONE CITY  ──►  MANY RIGS  ──►  MANY OPERATION PACKS  ──►  MANY CUSTOMER ESTATES

Never create fragmented cities (Migration City, Security City, Customer X City). Isolation is managed by Bead namespaces, Rigs, and Group tenancy.

5. Gas City Model & Separation of Concerns¶

Keep the six native primitives exact:

AGENT   = WHO executes
BEAD    = WHAT work exists
FORMULA = HOW work is executed (reusable method)
RIG     = WHERE work applies (project scope)
PACK    = CONFIGURES behavior & distribution
EVENT   = OBSERVES what happened (immutable audit)

Customer terminology translates to: Estate · Operation · Work · Decision · Approval · Evidence · Result · Capability

6. The Two Bluefly Loops¶

A. Verified Operations Loop (Customer Delivery)¶

DETECT ──► UNDERSTAND ──► MATCH ──► AUTHORIZE ──► ACT ──► VERIFY ──► PROVE ──► IMPROVE

B. Capability Flywheel (Factory Improvement)¶

VERIFIED OPERATION ──► LEARNING ──► CANDIDATE ──► REUSE ──► SECOND-ESTATE PROOF ──► PROVEN CAPABILITY ──► PACKAGE

7. Pack Portfolio (Productized Operating Knowledge)¶

Pack	Operational Domain	Primary Focus
PACK 1	Drupal Security & Release	Core/contrib advisories, composer updates, regression testing
PACK 2	Drupal Upgrade & Modernization	Major core/PHP upgrades, recipe conversion, SDC/Canvas adoption
PACK 3	Custom Module Assurance	Static analysis, deprecation repair, Net Negative Ownership
PACK 4	Migration	Legacy CMS (D7/D8/WP/Sitecore) into modern Drupal
PACK 5	Accessibility	Automated/manual WCAG 2.1 AA audits and remediation
PACK 6	Performance & Reliability	Cacheability, database optimization, Core Web Vitals
PACK 7	Content & Configuration Quality	Config drift, schema integrity, entity structure

8. Separation of Duties (Agent Roles)¶

Role	Permitted Actions	Prohibited Actions
Observer / Dog	Detect, observe, inventory, measure signals	Cannot mutate source or databases
Analyst	Analyze, match capabilities, assess risk, plan	Cannot implement code
Authority Gate	Validate Cedar policies, delegations, approvals	Cannot generate code
Executor / Polecat	Implement code, run tests, open MRs	Cannot approve own work or verify alone
Witness	Verify, disprove, exercise runtime, attest proof	Cannot fix what it tests
Refinery	Merge readiness, train sequencing, release	Cannot author feature changes
Mayor	Factory operational health, unconsumed signals	Cannot bypass governance
BLU	Factory coordination, board ownership, routing	Does not perform manual coding tasks

9. Customer Operating Modes¶

Autonomy is earned per operation class: - Observe: Read-only detection and reporting. - Assist: Remediation prepared; human approval required before execution. - Operate: Autonomous execution inside pre-delegated policy boundaries.

10. Operational Receipts¶

Every operation generates an immutable receipt:

ORGANIZATION=  PROJECT=  ESTATE=  OPERATION=  RUN=  SIGNAL=
SCOPE=  COVERAGE=  ACTOR=  AUTHORITY=  CHANGE=  SOURCE_COMMIT=
MR=  RELEASE=  DEPLOYMENT=  EXECUTION_RESULT=  INDEPENDENT_VERIFICATION=
FAILURES=  HUMAN_DECISIONS=  MODEL_COST=  HUMAN_TIME=  REUSED=  EVIDENCE=