The Dettonville Framework on Dettonville

Platform Architecture Guidelines

Thu, 21 May 2026 00:00:00 +0000

To achieve deterministic and immutable runtime states across an entire organizational domain, the underlying infrastructure must eliminate manual adjustments, ephemeral staging, and environmental drift.

The Dettonville framework enforces this by applying rigorous Configuration-as-Code (CaC) principles directly to the Control-Plane Fixtures that anchor the domain before application layers are ever introduced.

The Immutable Control-Plane Foundation

In an air-gapped or corporate datacenter environment, applications cannot rely on external, cloud-managed primitives. Instead, core network and operational fixtures must be stood up locally. The framework categorizes these foundational elements as the domain’s Deterministic Control Plane:

Local Hardening Standards

Thu, 21 May 2026 00:00:00 +0000

Operating infrastructure in private or regulated environments requires moving away from reactive security patches and public trust assumptions. The Dettonville framework integrates cryptographic verification and operating system hardening directly into its execution loop, treating security as an immutable system property rather than a post-provisioning checklist.

Defensive Boundary Architecture

The framework operates under a zero-trust execution model inside your local network perimeter, structuring defensive layers into three clear operational vectors:

graph LR
A[Cryptographic PKI<br/><code>Isolated Trust Anchors</code>] --> B[OS Level Hardening<br/><code>CIS Baselines / PAM</code>]
B --> C[Supply Chain Lock<br/><code>Signed Payload Ingest</code>]
style A fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;
style B fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;
style C fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;

1. Cryptographic PKI & Local Trust Anchors

Without access to external public Certificate Authorities (CAs), the domain must maintain a self-contained, high-integrity cryptographic anchor.

Automation Engineering Standards

Thu, 21 May 2026 00:00:00 +0000

To ensure that the datacenter orchestration remains predictable, repeatable, and maintainable across long-term lifecycles, all playbook and role development must conform to strict structural programming standards.

By treating infrastructure code with the same rigor as compiled application software, the platform completely eliminates ad-hoc modifications, fragile shell-script loops, and opaque node states.

Core Development Patterns

The framework enforces three primary software engineering concepts across the entire code repository:

graph TD
A[Decoupled Logic & Data<br/><code>Tasks vs inventory/group_vars</code>] --> B[Strict Idempotency Proofs<br/><code>Molecule Testing Lifecycle</code>]
B --> C[Flat-File Schema Output<br/><code>No External Database States</code>]
style A fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;
style B fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;
style C fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;

1. Decoupling Execution Logic from State Data

Tasks and roles must operate as generic, abstract machines. No hardcoded hostnames, interface strings, IP assignments, or target configuration blocks are permitted inside a role’s tasks/main.yml.

Programmatic Inventory Lifecycle

Thu, 21 May 2026 00:00:00 +0000

The platform maintains absolute alignment between live compute assets and your declarative code definitions by eliminating manual inventory adjustments. When a virtual machine or bare-metal host is spun up or decommissioned, the lifecycle event is programmatically committed to the Git-backed inventory repository via API integration patterns.

Programmatic Provisioning & Git Loop

The host enrollment lifecycle transitions an initial provisioning request into a git-versioned inventory alignment loop without operator intervention:

graph TD
A[1. Provisioning Requested<br/><code>In-House System</code>] --> B[2. Automated API Signal<br/><code>AAP / AWX / Jenkins</code>]
B --> C[3. Execute Provisioning Job<br/><code>Playbook / Runner Bubble</code>]
C --> D[4. Ingest & Target State<br/><code>git_inventory.update_inventory</code>]
D --> E[5. Mutate & Lock Blueprint<br/><code>Clone ➔ Update ➔ Commit ➔ Push</code>]
E --> F[6. Core Site Realization<br/><code>site.yml Active Deployment</code>]
style A fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;
style B fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;
style C fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;
style D fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;
style E fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;
style F fill:#f1f5f9,stroke:#cbd5e1,stroke-width:2px;

Architectural Lifecycle Steps

1. In-House Provisioning Request

An infrastructure scaling event or machine decommissioning request is initiated inside your internal, in-house provisioning system. This request carries key asset markers including IP addresses, hostnames, and targeted functional groups (such as GPU capabilities or specific application tags).