{ "schema_version": "1.1.0", "manifest_type": "DRH_FACET_WORLD_MANIFEST", "runtime_version": "12.0.0", "generated_at": "2026-10-04T10:45:00.090Z", "host": "darkrangeholdings.com", "architecture": "interactive_operating_environment", "interaction_contract": { "playable_facets": true, "facet_state_machine": true, "world_coupled_stage_highlighting": true, "exploration_memory": "session", "guided_flow_playback": true }, "default_facet": "overview", "path_index": { "/": "overview", "/systems/": "systems", "/about/": "about", "/projects/": "projects", "/automation/": "automation", "/services/": "services", "/infrastructure/": "infrastructure", "/distribution/": "distribution", "/case-studies/": "proof", "/contact/": "contact", "/privacy/": "privacy", "/projects/minimindslab/": "project-minimindslab", "/projects/omegift-ideas/": "project-omegift-ideas", "/projects/drh-sentinel/": "project-drh-sentinel", "/case-studies/artifact-lifecycle/": "case-artifact-lifecycle", "/case-studies/minimindslab-software-factory/": "case-minimindslab-software-factory", "/case-studies/minimindslab-ai-factory/": "case-minimindslab-ai-factory", "/case-studies/release-to-distribution-automation/": "case-release-to-distribution-automation", "/case-studies/multi-brand-distribution-factory/": "case-multi-brand-distribution-factory", "/case-studies/extending-multi-brand-distribution-to-youtube/": "case-extending-multi-brand-distribution-to-youtube", "/case-studies/closing-the-loop-on-autonomous-products/": "case-closing-the-loop-on-autonomous-products", "/case-studies/autonomous-software-factory-to-mcp/": "case-autonomous-software-factory-to-mcp" }, "facets": { "overview": { "id": "overview", "kind": "company", "index": "DRH / 00", "eyebrow": "Dark Range Holdings", "short_title": "System", "title": "Build small. Operate deep.", "status": "OPERATING", "summary": "Focused products on the surface. Automation, infrastructure, distribution, verification, and recovery underneath.", "body": "Dark Range Holdings is an independent technology operation built around a simple idea: keep the product narrow and make the operating system behind it unusually strong.", "context": "The company is intentionally small. The leverage comes from making build, operation, publishing, verification, and recovery reusable enough that a small team can run systems that would normally require far more manual attention.", "notes": [ "The visible site, tool, or service is only the public edge. DRH also owns the build path, deployment state, verification, measurement, backup, and recovery needed to keep that edge useful.", "Automation absorbs repeatable work, but authority stays explicit. Ambiguous decisions, credentials, destructive changes, and public actions remain bounded by human or policy gates.", "This constellation is a presentation model of that estate. It explains relationships without exposing live private infrastructure telemetry." ], "route": "/", "camera": "overview", "facts": [ [ "Model", "Focused products" ], [ "Operation", "Owned systems" ], [ "Delivery", "Web + MCP + automation" ], [ "Control", "Operator-owned" ], [ "Proof", "Production-grounded" ] ], "actions": [ { "label": "Explore projects", "href": "/projects/" }, { "label": "Operating model", "href": "/systems/" }, { "label": "Engineering proof", "href": "/case-studies/" } ], "related": [ "projects", "systems", "automation", "infrastructure", "distribution", "proof" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "PRODUCT", "AUTOMATE", "OPERATE", "DISTRIBUTE", "PROVE" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "systems": { "id": "systems", "kind": "system", "index": "DRH / 01A", "eyebrow": "Operating model", "short_title": "Systems", "title": "One estate. Clear operating boundaries.", "status": "OPERATING", "summary": "Product, automation, infrastructure, distribution, and proof are designed as one connected operating system.", "body": "Instead of treating a website, automation workflow, server, social channel, and verification record as unrelated concerns, DRH models them as layers of the same production path.", "context": "The relationships matter as much as the individual parts. Automation changes products; infrastructure keeps them available; distribution moves approved work outward; proof records whether the intended result actually happened.", "notes": [ "Product defines the useful public edge. Automation turns repetition into system behavior. Infrastructure holds state and recovery paths. Distribution moves approved work outward. Proof records what actually happened.", "The boundaries between those layers are deliberate: build does not imply deploy, deploy does not imply success, and public action does not imply unlimited authority.", "That separation makes failures easier to locate and successful patterns easier to reuse." ], "route": "/systems/", "camera": "systems", "facts": [ [ "Layers", "5" ], [ "Authority", "Bounded" ], [ "Recovery", "Designed in" ], [ "Evidence", "First-class" ], [ "State", "Explicit" ] ], "actions": [ { "label": "Services", "href": "/services/" }, { "label": "Automation", "href": "/automation/" } ], "related": [ "overview", "automation", "infrastructure", "distribution", "proof" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "PRODUCT", "AUTOMATE", "OPERATE", "DISTRIBUTE", "PROVE" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "services": { "id": "services", "kind": "company", "index": "DRH / 02A", "eyebrow": "Services", "short_title": "Services", "title": "Build it. Make it operable.", "status": "AVAILABLE", "summary": "Bounded software, automation, infrastructure, deployment, verification, and operational-hardening work.", "body": "Client work uses the same discipline as the DRH estate: defined scope, explicit authority, recoverable changes, and proof at the end of the path.", "context": "The useful deliverable is not just code. It is a bounded system that can be deployed, inspected, verified, handed off, and recovered without depending on undocumented knowledge.", "notes": [ "A useful engagement can be a focused application, an automation lane, an infrastructure repair, a deployment path, or an operating procedure that needs to become reliable system behavior.", "DRH favors narrow responsibilities and reversible changes over sprawling rewrites. Existing systems are adapted when they already solve the problem safely.", "The handoff should leave the client with something understandable enough to operate, inspect, and recover—not a black box that only its builder can touch." ], "route": "/services/", "camera": "services", "facts": [ [ "Work", "Software + automation" ], [ "Infrastructure", "Deploy + recover" ], [ "Authority", "Explicit" ], [ "Delivery", "Production-grounded" ], [ "Change model", "Bounded" ] ], "actions": [ { "label": "Start a conversation", "href": "/contact/" }, { "label": "Operating model", "href": "/systems/" } ], "related": [ "systems", "automation", "infrastructure", "proof" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "DISCOVER", "DESIGN", "BUILD", "VERIFY", "HANDOFF" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "about": { "id": "about", "kind": "company", "index": "DRH / COMPANY", "eyebrow": "Company", "short_title": "About", "title": "Small operation. Serious systems.", "status": "PUBLIC", "summary": "Dark Range Holdings is an independent technology operation building focused products and the systems required to operate them.", "body": "The company is intentionally small. Reusable automation, explicit contracts, and owned infrastructure provide leverage that would otherwise require a much larger operating team.", "context": "DRH is organized around ownership of the operating path. Products can stay small because deployment, verification, recovery, distribution, and evidence are treated as reusable company capabilities instead of being reinvented around every project.", "notes": [ "DRH does not pursue scale for its own sake. Products are expected to have a clear job, an understandable operating path, and a reason to exist economically.", "Self-hosting is used where control and observability matter; managed services are used when ownership would add complexity without adding leverage.", "The result is an estate designed to be operated, repaired, and extended by explicit systems rather than institutional memory." ], "route": "/about/", "camera": "about", "facts": [ [ "Structure", "Independent" ], [ "Model", "Focused products" ], [ "Operations", "Automation + infrastructure" ], [ "Bias", "Inspectable systems" ] ], "actions": [ { "label": "Projects", "href": "/projects/" }, { "label": "Contact", "href": "/contact/" } ], "related": [ "overview", "systems", "projects" ], "interaction": { "schema_version": "1.0.0", "mode": "informational", "stages": [], "world_coupled": false, "playback": false, "completion_scope": "session" } }, "projects": { "id": "projects", "kind": "cluster", "index": "DRH / 01", "eyebrow": "Portfolio", "short_title": "Projects", "title": "Small products. Shared machinery.", "status": "OPERATING", "summary": "Focused public products backed by a shared operating layer instead of isolated one-off deployments.", "body": "Each project is intentionally narrow at the surface. The compounding leverage comes from shared automation, deployment, verification, measurement, and recovery patterns underneath.", "context": "The portfolio is not a collection of disconnected websites. Each product plugs into the same operating disciplines, which means improvements to build, verification, recovery, and distribution can compound across the estate.", "notes": [ "MiniMindsLab turns narrowly defined software ideas into production tools and delivery surfaces. Omegift Ideas applies automated commerce-content generation and publication. DRH Sentinel represents the monitoring and operational-proof side of the estate.", "Projects can evolve independently while reusing the same controlled infrastructure and automation primitives.", "A project only counts as operating when there is a real path behind it—not merely a prototype or a polished screenshot." ], "route": "/projects/", "camera": "projects", "facts": [ [ "Projects", "3" ], [ "Pattern", "Focused products" ], [ "Shared layer", "Automation + infrastructure" ], [ "Qualification", "Real operating path" ] ], "actions": [ { "label": "MiniMindsLab", "href": "/projects/minimindslab/" }, { "label": "Omegift Ideas", "href": "/projects/omegift-ideas/" }, { "label": "DRH Sentinel", "href": "/projects/drh-sentinel/" } ], "related": [ "project-minimindslab", "project-omegift-ideas", "project-drh-sentinel", "automation", "infrastructure", "distribution", "proof" ], "interaction": { "schema_version": "1.0.0", "mode": "informational", "stages": [], "world_coupled": false, "playback": false, "completion_scope": "session" } }, "automation": { "id": "automation", "kind": "system", "index": "DRH / 02", "eyebrow": "Automation", "short_title": "Automation", "title": "Repeatable work becomes infrastructure.", "status": "OPERATING", "summary": "Discovery, build, QA, deployment, verification, and evidence are separated into explicit operating stages.", "body": "Automation exists to remove repetition without hiding authority or failure. A workflow should know what it may change, what must be approved, and what evidence proves the result.", "context": "The goal is not maximum automation. The goal is reliable system behavior: repeatable work becomes deterministic, ambiguous work is surfaced for judgment, and side effects remain bounded and traceable.", "notes": [ "Idempotency prevents a repeated run from becoming a repeated side effect. Deterministic manifests and state records make it possible to compare intent with what is actually deployed.", "QA and policy gates are separate from execution. The system can decide that doing nothing is the correct result.", "Verification happens after deployment against the real target or public edge; a successful transport step is not treated as proof of a successful outcome." ], "route": "/automation/", "camera": "automation", "facts": [ [ "Orchestration", "n8n" ], [ "Pattern", "Deterministic + idempotent" ], [ "QA", "Explicit gates" ], [ "State", "Durable evidence" ], [ "Authority", "Bounded" ] ], "actions": [ { "label": "Operating model", "href": "/systems/" }, { "label": "Engineering proof", "href": "/case-studies/" } ], "related": [ "projects", "infrastructure", "proof", "systems" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "DISCOVER", "BUILD", "QA", "DEPLOY", "VERIFY" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "infrastructure": { "id": "infrastructure", "kind": "system", "index": "DRH / 03", "eyebrow": "Infrastructure", "short_title": "Infrastructure", "title": "Infrastructure you can explain under pressure.", "status": "OPERATING", "summary": "Linux hosts, containers, private networking, explicit state, backups, bounded deployment, and recovery.", "body": "The infrastructure stack is intentionally boring where boring improves inspectability. Complexity has to earn its place by increasing reliability, visibility, or operating leverage.", "context": "Named hosts, explicit storage, bounded deployment, private networking, and independent verification make the estate easier to repair under pressure because there is less invisible state to rediscover.", "notes": [ "Build, audit, deploy, and live verification are separate responsibilities. That keeps a transport failure from looking like a content failure and keeps a successful copy from masquerading as a verified release.", "Mutable deployment preserves backup state before overwrite. Configuration and evidence are treated as artifacts that can be compared rather than assumptions held in somebody’s head.", "Private networking and small, named hosts keep the estate understandable enough to reason about during failure." ], "route": "/infrastructure/", "camera": "infrastructure", "facts": [ [ "Hosts", "Linux" ], [ "Runtime", "Docker" ], [ "Network", "Private overlay" ], [ "Edge", "Caddy + Cloudflare" ], [ "State", "Nextcloud" ], [ "Deploy", "Bounded + verified" ] ], "actions": [ { "label": "Automation", "href": "/automation/" }, { "label": "Engineering proof", "href": "/case-studies/" } ], "related": [ "projects", "automation", "proof", "systems" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "CORE", "WEB", "STATE", "BACKUP", "RECOVER" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "distribution": { "id": "distribution", "kind": "system", "index": "DRH / 04", "eyebrow": "Distribution", "short_title": "Distribution", "title": "Automate the path. Keep the authority.", "status": "CONTROLLED", "summary": "Candidate routing, review, approval, publishing, interaction handling, and measurement are distinct states.", "body": "Distribution automation moves work toward public channels without collapsing preparation and authority into the same step.", "context": "Preparation can be automated aggressively while authority remains explicit. The system can route, format, validate, and queue work without silently granting itself unlimited permission to publish or reply.", "notes": [ "Brand and account routing are resolved before execution so a valid message cannot silently publish through the wrong identity.", "Public replies and other authority-bearing actions can require an explicit approval record before the channel adapter is allowed to execute.", "Publishing receipts and measurement flow back into the evidence layer so distribution is observable rather than fire-and-forget." ], "route": "/distribution/", "camera": "distribution", "facts": [ [ "Publishing", "Multi-channel" ], [ "Responses", "Approval-gated" ], [ "Measurement", "Analytics" ], [ "Authority", "Operator controlled" ], [ "Replay", "Controlled" ] ], "actions": [ { "label": "Automation", "href": "/automation/" }, { "label": "Projects", "href": "/projects/" } ], "related": [ "projects", "automation", "proof", "systems" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "ROUTE", "REVIEW", "APPROVE", "PUBLISH", "MEASURE" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "proof": { "id": "proof", "kind": "archive", "index": "DRH / 05", "eyebrow": "Engineering proof", "short_title": "Proof", "title": "Evidence before claims.", "status": "VERIFIED", "summary": "Changes, failures, corrections, verification results, and operating lessons are preserved as engineering evidence.", "body": "DRH treats proof as part of the system rather than documentation written after everybody has forgotten what happened.", "context": "A system is not considered proven because a command returned zero. Proof comes from comparing intended state with the real target, keeping receipts, and preserving enough history to explain both success and failure.", "notes": [ "A deployment receipt proves a transport action happened. A live verification proves the resulting public or operational state matches the intended artifact. Those are different facts and are recorded separately.", "Failures remain useful when the correction is captured with enough context to prevent the same blind spot from returning.", "Case studies are built from production-grounded work so the public record reflects systems that actually survived contact with reality." ], "route": "/case-studies/", "camera": "proof", "facts": [ [ "Case studies", "8" ], [ "Basis", "Production evidence" ], [ "Style", "Engineering record" ], [ "Verification", "Independent stage" ] ], "actions": [ { "label": "Extending an Autonomous Software Factory to MCP", "href": "/case-studies/autonomous-software-factory-to-mcp/" }, { "label": "Closing the Loop on Autonomous Products", "href": "/case-studies/closing-the-loop-on-autonomous-products/" }, { "label": "Extending a Multi-Brand Distribution Factory to YouTube", "href": "/case-studies/extending-multi-brand-distribution-to-youtube/" } ], "related": [ "projects", "automation", "infrastructure", "distribution", "systems" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "EVIDENCE", "CHANGE", "VERIFY", "RECORD" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "contact": { "id": "contact", "kind": "company", "index": "DRH / CONTACT", "eyebrow": "Contact", "short_title": "Contact", "title": "Bring a real problem.", "status": "OPEN", "summary": "Software, automation, infrastructure, deployment, verification, or bounded operating-system work.", "body": "Use the company address directly. A useful first message is the problem, the environment it lives in, the authority available to change it, and what a successful result would look like.", "context": "The fastest path to a useful technical conversation is concrete scope: what exists now, what is failing or missing, what DRH would be allowed to change, and how both sides will know the work is complete.", "notes": [ "DRH works best when the scope can be made explicit enough to build, verify, and hand off cleanly.", "Existing systems do not need to be replaced simply because they are old; adaptation is often safer and cheaper when the current system can be made reliable." ], "route": "/contact/", "camera": "overview", "facts": [ [ "Channel", "Company email" ], [ "Address", "admin@darkrangeholdings.com" ], [ "Engagement", "Bounded scope" ] ], "actions": [ { "label": "admin@darkrangeholdings.com", "href": "mailto:admin@darkrangeholdings.com", "external": false } ], "related": [ "overview", "projects", "services" ], "interaction": { "schema_version": "1.0.0", "mode": "informational", "stages": [], "world_coupled": false, "playback": false, "completion_scope": "session" } }, "privacy": { "id": "privacy", "kind": "legal", "index": "DRH / PRIVACY", "eyebrow": "Privacy", "short_title": "Privacy", "title": "Limited collection. Plain language.", "status": "PUBLIC", "summary": "Basic analytics and standard infrastructure logging support measurement, reliability, diagnostics, and abuse prevention.", "body": "The public DRH surface is primarily static and does not currently provide public user accounts, comments, or a general application backend.", "context": "The interactive environment changes presentation, not the underlying privacy model. The public site remains a primarily static surface with analytics and ordinary operational logging rather than a hidden account or profile system.", "notes": [ "Google Analytics 4 is used for aggregate traffic and engagement measurement. Standard edge and server logs may be retained for security and operational diagnostics.", "Individual DRH projects can have their own measurement or operational tooling; those practices belong to the relevant project surface." ], "route": "/privacy/", "camera": "overview", "facts": [ [ "Analytics", "GA4" ], [ "Accounts", "None" ], [ "Public backend", "Limited" ], [ "Purpose", "Operations + measurement" ] ], "actions": [], "related": [ "overview" ], "interaction": { "schema_version": "1.0.0", "mode": "informational", "stages": [], "world_coupled": false, "playback": false, "completion_scope": "session" } }, "project-minimindslab": { "id": "project-minimindslab", "kind": "project", "index": "PROJECT / 01", "eyebrow": "Multi-target software factory", "short_title": "MiniMindsLab", "title": "MiniMindsLab", "status": "OPERATING", "summary": "An autonomous multi-target software factory that discovers useful capabilities, builds and verifies web tools, and selectively recompiles suitable capabilities for Model Context Protocol.", "body": "MiniMindsLab turns narrowly scoped software ideas into public tools, then carries those tools through build, QA, publication, measurement, and additional delivery surfaces.", "context": "Its place in the constellation is deliberate: the product is generated by automation, served by shared infrastructure, verified after release, and can be delivered through both Web and MCP rather than living as a one-off website.", "notes": [ "The software-factory model separates opportunity discovery, evidence, implementation, QA, publication, and live verification so each stage can fail without pretending the entire product failed.", "The public tool catalog is the visible edge; reusable build and operating lanes are the compounding asset underneath it.", "An autonomous multi-target software factory that discovers useful capabilities, builds and verifies web tools, and selectively recompiles suitable capabilities for Model Context Protocol.", "Open the full DRH project page for the operating record, or follow the live-project action to leave the DRH environment." ], "route": "/projects/minimindslab/", "camera": "projects", "facts": [ [ "Status", "Operating" ], [ "Delivery", "Web + MCP" ], [ "Operating layer", "DRH-managed" ] ], "actions": [ { "label": "Visit project", "href": "https://minimindslab.com", "external": true } ], "related": [ "projects", "automation", "infrastructure", "distribution", "proof" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "IDEA", "EVIDENCE", "BUILD", "QA", "WEB", "MCP" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "project-omegift-ideas": { "id": "project-omegift-ideas", "kind": "project", "index": "PROJECT / 02", "eyebrow": "Search publishing system", "short_title": "Omegift Ideas", "title": "Omegift Ideas", "status": "OPERATING", "summary": "An automated static publishing experiment focused on gift-idea discovery and search-driven content.", "body": "Omegift Ideas connects product discovery, commerce matching, editorial composition, publication, and distribution into one bounded content-production path.", "context": "The project is useful as a topology example because it crosses several DRH layers at once: automation creates the artifact, infrastructure publishes it, distribution moves approved output outward, and verification confirms the public result.", "notes": [ "Commerce data and editorial output remain distinct stages so product selection does not silently become publication authority.", "The DRH record describes the operating path while the live site remains the destination for the resulting content.", "An automated static publishing experiment focused on gift-idea discovery and search-driven content.", "Open the full DRH project page for the operating record, or follow the live-project action to leave the DRH environment." ], "route": "/projects/omegift-ideas/", "camera": "projects", "facts": [ [ "Status", "Operating" ], [ "Delivery", "Web" ], [ "Operating layer", "DRH-managed" ] ], "actions": [ { "label": "Visit project", "href": "https://ideas.omegift.com", "external": true } ], "related": [ "projects", "automation", "infrastructure", "distribution", "proof" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "DISCOVER", "MATCH", "COMPOSE", "PUBLISH" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "project-drh-sentinel": { "id": "project-drh-sentinel", "kind": "project", "index": "PROJECT / 03", "eyebrow": "External heartbeat monitoring", "short_title": "DRH Sentinel", "title": "DRH Sentinel", "status": "PRIVATE BETA", "summary": "External heartbeat and dead-man monitoring for scheduled jobs, backups, and other critical automated processes.", "body": "DRH Sentinel represents the independent watch-and-verify side of the estate: external checks observe important surfaces without depending on the same runtime they are checking.", "context": "Its role is operational rather than decorative. Independent observation, bounded alerts, recovery evidence, and failure history give DRH a second point of view when the primary environment is unhealthy.", "notes": [ "External checks are most useful when they fail independently from the systems they observe.", "The project sits close to infrastructure and proof because its value comes from confirming state, not merely drawing a dashboard.", "External heartbeat and dead-man monitoring for scheduled jobs, backups, and other critical automated processes.", "Open the full DRH project page for the operating record, or follow the live-project action to leave the DRH environment." ], "route": "/projects/drh-sentinel/", "camera": "projects", "facts": [ [ "Status", "Private Beta" ], [ "Delivery", "Web" ], [ "Operating layer", "DRH-managed" ] ], "actions": [ { "label": "Open Sentinel", "href": "https://sentinel.darkrangeholdings.com", "external": true } ], "related": [ "projects", "automation", "infrastructure", "distribution", "proof" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "WATCH", "CHECK", "ALERT", "RECOVER" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "case-artifact-lifecycle": { "id": "case-artifact-lifecycle", "kind": "case-study", "index": "PROOF / 01", "eyebrow": "Engineering record", "short_title": "Safe Artifact Lifecycle Automation", "title": "Safe Artifact Lifecycle Automation", "status": "VERIFIED", "summary": "A staged automation system that inventories, classifies, plans, quarantines, and only permits destructive cleanup after fresh evidence and explicit approval.", "body": "Production evidence first. The record captures what changed, what failed, what was proven, and what the system learned.", "context": "The short facet is an index into the engineering record. The complete document page preserves the larger sequence of problem, implementation, failure modes, correction, and verification.", "notes": [ "Long-lived automation estates accumulate archives, intermediate artifacts, duplicates, and files whose producer is no longer obvious. Cleanup has to reduce clutter without treating age, size, or unknown ownership as permission to delete.", "DRH built the 00.07.a–f lifecycle chain around discovery first: census and producer mapping, lifecycle classification, cleanup planning, reversible quarantine, delayed destructive cleanup, and read-only storage reporting. Unknown artifacts stay protected, duplicate decisions require evidence, and destructive actions remain separately gated.", "The canonical engineering record remains available as a full document page." ], "route": "/case-studies/artifact-lifecycle/", "camera": "proof", "document_title": "Safe Artifact Lifecycle Automation · Dark Range Holdings", "description": "A staged automation system that inventories, classifies, plans, quarantines, and only permits destructive cleanup after fresh evidence and explicit approval.", "facts": [ [ "Status", "Operating" ], [ "Technologies", "n8n · Nextcloud · Linux" ], [ "Basis", "Production evidence" ] ], "actions": [ { "label": "Open engineering record", "href": "/case-studies/artifact-lifecycle/" } ], "related": [ "proof", "automation", "infrastructure" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "CONTEXT", "CHANGE", "VERIFY", "RESULT" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "case-minimindslab-software-factory": { "id": "case-minimindslab-software-factory", "kind": "case-study", "index": "PROOF / 02", "eyebrow": "Engineering record", "short_title": "MiniMindsLab Software Factory", "title": "MiniMindsLab Software Factory", "status": "VERIFIED", "summary": "A browser-tool production line that turns small software ideas and legacy utilities into tested, canonical static tools through frozen specs, bounded repair, deterministic QA, browser verification, and controlled deployment.", "body": "Production evidence first. The record captures what changed, what failed, what was proven, and what the system learned.", "context": "The short facet is an index into the engineering record. The complete document page preserves the larger sequence of problem, implementation, failure modes, correction, and verification.", "notes": [ "Small browser utilities are easy to prototype and surprisingly hard to operate as a growing catalog. Each tool can arrive with different assumptions, dependencies, UI patterns, failure modes, and deployment requirements. Manual cleanup works for a few tools, but it does not create a repeatable software operation.", "MiniMindsLab separates the work into explicit stages: intake and deduplication, frozen tool specification, Codex-assisted implementation, deterministic build QA, targeted repair, browser QA, canonical commit, site build, deploy, and live verification. A tool cannot become canonical simply because it renders; it has to satisfy the contract created upstream.", "The canonical engineering record remains available as a full document page." ], "route": "/case-studies/minimindslab-software-factory/", "camera": "proof", "document_title": "MiniMindsLab Software Factory · Dark Range Holdings", "description": "A browser-tool production line that turns small software ideas and legacy utilities into tested, canonical static tools through frozen specs, bounded repair, deterministic QA, browser verification, and controlled deployment.", "facts": [ [ "Status", "Operating" ], [ "Technologies", "n8n · Codex · Playwright" ], [ "Basis", "Production evidence" ] ], "actions": [ { "label": "Open engineering record", "href": "/case-studies/minimindslab-software-factory/" } ], "related": [ "proof", "automation", "infrastructure" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "IDEA", "EVIDENCE", "BUILD", "QA", "WEB", "MCP" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "case-minimindslab-ai-factory": { "id": "case-minimindslab-ai-factory", "kind": "case-study", "index": "PROOF / 03", "eyebrow": "Engineering record", "short_title": "MiniMindsLab AI Tool Factory", "title": "MiniMindsLab AI Tool Factory", "status": "VERIFIED", "summary": "A structured AI application pipeline that converts tool ideas into server-backed OpenAI utilities with contract tests, real staged-model semantics, isolated browser/API QA, canonical releases, deployment, and live-edge verification.", "body": "Production evidence first. The record captures what changed, what failed, what was proven, and what the system learned.", "context": "The short facet is an index into the engineering record. The complete document page preserves the larger sequence of problem, implementation, failure modes, correction, and verification.", "notes": [ "An AI tool can return valid JSON and still be wrong in ways that matter: unsupported claims, weak grounding, broken browser behavior, schema drift, accidental external requests, or runtime behavior that only fails after deployment. A production AI factory therefore has to test both deterministic structure and nondeterministic meaning.", "The MiniMindsLab AI lane starts with idea intake and semantic deduplication, freezes an explicit structured-tool spec, builds the runtime bundle, runs deterministic contract QA, then launches the exact staged bundle against a real OpenAI runtime. Semantic cases are evaluated, the browser UI is exercised in isolated Chromium, canonical commit is gated, and separate release, deploy, and live-verification stages confirm the public runtime.", "The canonical engineering record remains available as a full document page." ], "route": "/case-studies/minimindslab-ai-factory/", "camera": "proof", "document_title": "MiniMindsLab AI Tool Factory · Dark Range Holdings", "description": "A structured AI application pipeline that converts tool ideas into server-backed OpenAI utilities with contract tests, real staged-model semantics, isolated browser/API QA, canonical releases, deployment, and live-edge verification.", "facts": [ [ "Status", "Operating" ], [ "Technologies", "n8n · OpenAI · Docker" ], [ "Basis", "Production evidence" ] ], "actions": [ { "label": "Open engineering record", "href": "/case-studies/minimindslab-ai-factory/" } ], "related": [ "proof", "automation", "infrastructure" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "IDEA", "EVIDENCE", "BUILD", "QA", "WEB", "MCP" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "case-release-to-distribution-automation": { "id": "case-release-to-distribution-automation", "kind": "case-study", "index": "PROOF / 04", "eyebrow": "Engineering record", "short_title": "Release-to-Distribution Automation", "title": "Release-to-Distribution Automation", "status": "VERIFIED", "summary": "A surface-agnostic marketing control plane that turns verified releases into channel-specific, human-approved posts with account isolation and replay-safe publishing.", "body": "Production evidence first. The record captures what changed, what failed, what was proven, and what the system learned.", "context": "The short facet is an index into the engineering record. The complete document page preserves the larger sequence of problem, implementation, failure modes, correction, and verification.", "notes": [ "Shipping useful software was already automated, but distribution still risked becoming a separate manual process for every product and social network. A release could pass build, QA, deployment, and live verification while the work required to announce it remained duplicated across channels.", "DRH separated release production from distribution. A live verifier emits one canonical distribution candidate only after the public artifact is proven healthy. A shared 04.xx control plane then matches the candidate to eligible channels, builds channel-specific plans, freezes approved copy, and routes a single authorized job to the correct platform adapter.", "The canonical engineering record remains available as a full document page." ], "route": "/case-studies/release-to-distribution-automation/", "camera": "proof", "document_title": "Release-to-Distribution Automation · Dark Range Holdings", "description": "A surface-agnostic marketing control plane that turns verified releases into channel-specific, human-approved posts with account isolation and replay-safe publishing.", "facts": [ [ "Status", "Operating" ], [ "Technologies", "n8n · Nextcloud · OAuth 2.0" ], [ "Basis", "Production evidence" ] ], "actions": [ { "label": "Open engineering record", "href": "/case-studies/release-to-distribution-automation/" } ], "related": [ "proof", "automation", "infrastructure" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "CONTEXT", "CHANGE", "VERIFY", "RESULT" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "case-multi-brand-distribution-factory": { "id": "case-multi-brand-distribution-factory", "kind": "case-study", "index": "PROOF / 05", "eyebrow": "Engineering record", "short_title": "Building a Human-Gated Multi-Brand Distribution Factory", "title": "Building a Human-Gated Multi-Brand Distribution Factory", "status": "VERIFIED", "summary": "How Dark Range Holdings built a shared distribution system that takes verified releases from multiple brands through channel routing, media generation, QA, human approval, account-specific publication, and durable execution receipts.", "body": "Production evidence first. The record captures what changed, what failed, what was proven, and what the system learned.", "context": "The short facet is an index into the engineering record. The complete document page preserves the larger sequence of problem, implementation, failure modes, correction, and verification.", "notes": [ "Dark Range Holdings needed one reusable marketing system for multiple independent brands without mixing their identities, credentials, publication policies, or media requirements. MiniMindsLab, Omegift, and Dark Range Holdings each needed to enter the same distribution machinery while retaining their own account routes and operating rules.", "The resulting pipeline begins with a live-verified release and moves through a canonical distribution contract, channel matching, distribution planning, media generation, deterministic QA, human approval, execution routing, platform-specific adapters, and durable publication receipts. Shared machinery handles the common operating model while surface-specific account routes preserve brand identity.", "The canonical engineering record remains available as a full document page." ], "route": "/case-studies/multi-brand-distribution-factory/", "camera": "proof", "document_title": "Building a Human-Gated Multi-Brand Distribution Factory · Dark Range Holdings", "description": "How Dark Range Holdings built a shared distribution system that takes verified releases from multiple brands through channel routing, media generation, QA, human approval, account-specific publication, and durable execution receipts.", "facts": [ [ "Status", "Production" ], [ "Technologies", "n8n · Node.js · Docker" ], [ "Basis", "Production evidence" ] ], "actions": [ { "label": "Open engineering record", "href": "/case-studies/multi-brand-distribution-factory/" } ], "related": [ "proof", "automation", "infrastructure" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "CONTEXT", "CHANGE", "VERIFY", "RESULT" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "case-extending-multi-brand-distribution-to-youtube": { "id": "case-extending-multi-brand-distribution-to-youtube", "kind": "case-study", "index": "PROOF / 06", "eyebrow": "Engineering record", "short_title": "Extending a Multi-Brand Distribution Factory to YouTube", "title": "Extending a Multi-Brand Distribution Factory to YouTube", "status": "VERIFIED", "summary": "How Dark Range Holdings added YouTube as a native, human-approved distribution channel for three brands without rebuilding the shared marketing control plane.", "body": "Production evidence first. The record captures what changed, what failed, what was proven, and what the system learned.", "context": "The short facet is an index into the engineering record. The complete document page preserves the larger sequence of problem, implementation, failure modes, correction, and verification.", "notes": [ "The distribution factory already knew how to turn verified releases into channel-specific work for Bluesky, Threads, Mastodon, Instagram, and X. Adding YouTube could not become a second marketing architecture. The goal was to add a video channel while preserving the same candidate, planning, QA, human-approval, execution, ledger, recovery, and reconciliation boundaries.", "Dark Range Holdings, MiniMindsLab, and Omegift each use a separate native n8n YouTube OAuth credential and a separately verified YouTube channel ID. The shared adapter routes by surface and account identity instead of inferring the destination from copy, URLs, or credential order. One adapter therefore serves all three brands without collapsing their identities together.", "The canonical engineering record remains available as a full document page." ], "route": "/case-studies/extending-multi-brand-distribution-to-youtube/", "camera": "proof", "document_title": "Extending a Multi-Brand Distribution Factory to YouTube · Dark Range Holdings", "description": "How Dark Range Holdings added YouTube as a native, human-approved distribution channel for three brands without rebuilding the shared marketing control plane.", "facts": [ [ "Status", "Operating" ], [ "Technologies", "n8n · YouTube Data API · OAuth 2.0" ], [ "Basis", "Production evidence" ] ], "actions": [ { "label": "Open engineering record", "href": "/case-studies/extending-multi-brand-distribution-to-youtube/" } ], "related": [ "proof", "automation", "infrastructure" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "CONTEXT", "CHANGE", "VERIFY", "RESULT" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "case-closing-the-loop-on-autonomous-products": { "id": "case-closing-the-loop-on-autonomous-products", "kind": "case-study", "index": "PROOF / 07", "eyebrow": "Engineering record", "short_title": "Closing the Loop on Autonomous Products", "title": "Closing the Loop on Autonomous Products", "status": "VERIFIED", "summary": "How Dark Range Holdings connected comparative search and traffic measurement, behavioral funnels, runtime economics, intervention attribution, and decision history so automated products can be judged after release instead of merely shipped.", "body": "Production evidence first. The record captures what changed, what failed, what was proven, and what the system learned.", "context": "The short facet is an index into the engineering record. The complete document page preserves the larger sequence of problem, implementation, failure modes, correction, and verification.", "notes": [ "DRH already had factories that could create, test, deploy, and verify products, but a successful release was still only proof that software shipped. It did not answer whether people found the product, used it successfully, whether a revision helped, or what the successful use actually cost to serve. The missing layer was a control loop that could distinguish delivery success from product success.", "The measurement lane was rebuilt around coherent completed windows rather than isolated latest files. Search Console and GA4 evidence compare the current complete seven-day period with the immediately preceding complete period, and every report carries a measurement identity. Mixed windows fail closed instead of producing a convincing but invalid trend.", "The canonical engineering record remains available as a full document page." ], "route": "/case-studies/closing-the-loop-on-autonomous-products/", "camera": "proof", "document_title": "Closing the Loop on Autonomous Products · Dark Range Holdings", "description": "How Dark Range Holdings connected comparative search and traffic measurement, behavioral funnels, runtime economics, intervention attribution, and decision history so automated products can be judged after release instead of merely shipped.", "facts": [ [ "Status", "Operating" ], [ "Technologies", "n8n · Google Analytics 4 · Google Search Console" ], [ "Basis", "Production evidence" ] ], "actions": [ { "label": "Open engineering record", "href": "/case-studies/closing-the-loop-on-autonomous-products/" } ], "related": [ "proof", "automation", "infrastructure" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "CONTEXT", "CHANGE", "VERIFY", "RESULT" ], "world_coupled": true, "playback": true, "completion_scope": "session" } }, "case-autonomous-software-factory-to-mcp": { "id": "case-autonomous-software-factory-to-mcp", "kind": "case-study", "index": "PROOF / 08", "eyebrow": "Engineering record", "short_title": "Extending an Autonomous Software Factory to MCP", "title": "Extending an Autonomous Software Factory to MCP", "status": "VERIFIED", "summary": "How MiniMindsLab evolved from an autonomous browser-tool factory into a multi-target software system that selectively recompiles production capabilities for Model Context Protocol.", "body": "Production evidence first. The record captures what changed, what failed, what was proven, and what the system learned.", "context": "The short facet is an index into the engineering record. The complete document page preserves the larger sequence of problem, implementation, failure modes, correction, and verification.", "notes": [ "MiniMindsLab already discovered, specified, generated, repaired, browser-tested, committed, deployed, and live-verified web tools. The next question was whether a proven capability could become something other software could call without duplicating the entire product factory.", "The factory was split at the delivery boundary. Product discovery and the frozen capability contract remain upstream. After a canonical web build exists, a delivery-target decision determines whether the capability stops at the web or continues into another implementation factory.", "The canonical engineering record remains available as a full document page." ], "route": "/case-studies/autonomous-software-factory-to-mcp/", "camera": "proof", "document_title": "Extending an Autonomous Software Factory to MCP · Dark Range Holdings", "description": "How MiniMindsLab evolved from an autonomous browser-tool factory into a multi-target software system that selectively recompiles production capabilities for Model Context Protocol.", "facts": [ [ "Status", "Operating" ], [ "Technologies", "n8n · Model Context Protocol · Node.js" ], [ "Basis", "Production evidence" ] ], "actions": [ { "label": "Open engineering record", "href": "/case-studies/autonomous-software-factory-to-mcp/" } ], "related": [ "proof", "automation", "infrastructure" ], "interaction": { "schema_version": "1.0.0", "mode": "progressive_flow", "stages": [ "CONTEXT", "CHANGE", "VERIFY", "RESULT" ], "world_coupled": true, "playback": true, "completion_scope": "session" } } } }