Skip to content

Authority Model

This engineering standard establishes the governing principles, terminology, responsibilities, and invariants for how ownership and operational responsibilities are separated across the Bluefly platform.

1. Architectural Layers

The authority architecture enforces a strict separation between policy, authoritative data, and human-readable projections:

Authority Model (Defines concepts and governance)
        ↓
Authority Registry (Validated data: Authority-Registry.yaml)
        ↓
Catalog Generator (Extracts and formats)
        ↓
Human Views (HTML / Markdown / Dashboards)
        ↓
Convergence Engine (Audits)
        ↓
Compliance Reports

Users MUST NOT edit generated artifacts directly. All changes to authority must be made in the schema-validated authoritative registry.

2. Platform Invariants

The following invariants define strict rules for the Authority Registry. They must never be violated, and the convergence engine actively validates against them:

  • Invariant 1: Exactly one authoritative record exists for each repository.
  • Invariant 2: Every deployment references exactly one runtime.
  • Invariant 3: Generated artifacts SHALL NOT be edited.
  • Invariant 4: Observed compliance SHALL NOT overwrite declared compliance.
  • Invariant 5: Authority domains are mutually independent.

3. Authority Separation Principle

Code ownership, deployment ownership, runtime ownership, execution authority, and documentation ownership are independent responsibilities and SHALL be documented independently.

A repository may own the source code while another repository owns deployment, and a third system owns runtime execution.

Continuous Integration validates changes. Deployment is performed only by the declared Deployment Owner using the authoritative deployment mechanism. Runtime execution is governed by the declared Runtime Owner. Documentation is maintained by the declared Documentation Owner.

4. The Responsibility Model

Every repository SHALL declare the following five distinct responsibilities in the Authority Registry:

Responsibility Question it answers
Code Who changes it?
Deployment Who publishes it?
Runtime Who executes it?
Operational Who responds when it breaks?
Documentation Who defines how it works?

5. Repository Context Compliance

Every repository must declare local contextual knowledge. The runtime audits this via .agents/context compliance levels. The model distinguishes between what a repository declares it complies with and what the convergence engine observes.

Compliance Levels

Level Requirements Description
Level 0 No context Non-compliant. Missing implementation knowledge.
Level 1 PROJECT.md Basic understanding of repository purpose.
Level 2 PROJECT.md, ARCHITECTURE.md, BOUNDARIES.md Defined boundaries and architectural invariants.
Level 3 Full context Validated automatically by the convergence engine.

Auditing Output

The convergence engine audits the declared context against reality, producing reproducible output in the following format:

context:
  declared_level: 3
  observed_level: 2
  compliance: non_compliant
  evidence:
    - ARCHITECTURE.md missing

6. Bluefly Master Executive Reference

Executive Description

Bluefly manufactures governed digital organizations through a "Composition over Implementation" methodology. It operates as a governed digital-service factory for regulated and mission-driven organizations, utilizing Gas City as the orchestration "Light Factory" (a highly observable supervisor plane) to coordinate "Dark Factories" of autonomous multi-agent teams. The primary product is a Drupal-based Agent-Managed Content System (AMCS) that treats Drupal as a repository of crystallized knowledge, assembled strictly via declarative Recipes and Site Templates. The architecture prioritizes accountability, verifiable execution, and a strict governance layer over shipping bespoke code or monolithic harnesses.

System Model

  • SOURCE/DELIVERY: GitLab is the primary authority for source control, CI/CD pipelines, package management, and release artifacts.
  • RUNTIME/EXECUTION: Oracle VM infrastructure, managed via Infrastructure as Code (Terraform/Ansible), serves as the authoritative host for Gas City orchestration and persistent agents.
  • WORK AUTHORITY: Beads represent the unit of durable work state, managed via a Dolt-backed, Git-versioned ledger to ensure every action is auditable and reversible.
  • BUSINESS AUTHORITY: Drupal 11 provides the durable content models, editorial workflows, and authorization structures.
  • KNOWLEDGE/DOCTRINE: BluCity-Docs (GitLab repository) serves as the canonical Git-based source for engineering and operational documentation.
  • AI/AGENT INTERFACES: OpenClaw acts as the operator cockpit and mission control surface; OSSA (Open Standard Agents) defines the identity and contract specification for agents.
  • OBSERVABILITY/EVIDENCE: Network Attached Storage (NAS) provides durable canonical storage for evidence receipts, snapshots, and long-term release archives.

Authority Model

  • Work State: Beads via the authoritative Dolt store.
  • Engineering Doctrine: BluCity-Docs hosted on GitLab.
  • Business/Product State: Drupal 11 production environment.
  • Runtime State: Deployed execution environments on Oracle VM.
  • Source of Truth: GitLab repository identity and commit history.
  • Human Collaboration: Google Drive functions as a projection and collaboration surface but is never considered a source of authority.

Capability Registry

Capability Description Owner Authority Implementation Status Maturity
Gas City Declarative orchestration-builder SDK providing runtime primitives. Gas Town Hall Gas City Gas City Packs ACTIVE PRODUCTION
Drupal AMCS Agent-Managed Content System for autonomous platform assembly. Bluefly Drupal Recipes/Templates ACTIVE PROTOTYPE
ContractPlane Policy enforcement and immutable evidence ledger. Bluefly ContractPlane Cedar Policies ACTIVE PROTOTYPE
OSSA Vendor-neutral agent contract and identity specification. Bluefly OSSA Manifests/GAID ACTIVE MATURE

Ownership Model

  • Governance/Contracts: Bluefly owns the cryptographic policies, compliance mappings, and execution contracts (ContractPlane).
  • Execution Runtime: Upstream projects (Gas City) provide the underlying runtime orchestration and execution primitives.
  • Infrastructure Orchestration: Bluefly manages the automated provisioning and deployment via IaC (Terraform) and GitLab components.
  • Business/Content Plane: Bluefly manages the AMCS blueprints and the assembly of Drupal-based products.

Current Products and Platforms

  • Bluefly Factory: The core manufacturing engine combining Gas City orchestration with AMCS assembly lines to produce governed digital platforms.
  • AMCS: The Agent-Managed Content System, a Drupal-based foundation designed specifically for AI agent management.
  • OpenClaw: The mission control operator surface for managing multi-agent workflows and factory operations.

Current Architecture Decisions

  • Composition over Implementation: Strict adherence to declarative assembly; custom PHP or monolithic code is forbidden unless a capability gap is proven.
  • Oracle 3-VM Setup: The current production authority for the host and services, requiring full reproducibility from IaC.
  • Zero Manual SSH: A critical failure metric; if a human must manually SSH into a server to deploy or fix a script, the factory has failed.

Current State vs Target Direction

  • Current State: Focused on establishing runtime authority on Oracle and stabilizing the core Gas City toolchain (Phase 0-1).
  • Target Direction: Achieving full factory autonomy through a "destroy/rebuild gate" that certifies zero-manual-intervention recovery.

Capability Evolution

  • 2026-06-25: Strategic shift from a general "Agent Factory" to a specialized "Governed Digital-Service Factory" for mission-driven organizations.
  • 2026-07-22: Formalization of the AMCS (Agent-Managed Content System) as the flagship product manufactured by the Bluefly Factory.

Explicit Non-Authorities

  • Local developer laptops: Disposable workstations that hold no unique runtime truth or authoritative archives.
  • Google Drive: A surface for projection and human collaboration, not a source of canonical engineering state.
  • Agent summaries: Inferred information from disposable sessions; not a substitute for canonical state or the Beads ledger.

This standard summarizes and cross-references: