Developum EST. 2026

Developum Operator Manual

B2B FIELD OPERATIONS · VERSION 1.0 · CONFIDENTIAL

1 · Core Philosophy

Developum is a modular B2B operational system designed to scale multi-agent services securely and predictably. We build on real-world workflow delegation rather than leaving agent behavior completely unstructured.

The First AD Framework

In film production, the First Assistant Director (First AD) is responsible for set safety, scheduling, and keeping the workforce coordinated. The Director sets the high-level goal; the First AD makes sure the crew executes it safely within budget constraints.

Your Developum engine is structured the exact same way. The Comms Room Coordinator acts as your First AD, overseeing specialized sub-agents and ensuring they collaborate without drift.

The Golden Rules of Delegation

Span of Control (≤ 4): Never let a single Coordinator manage more than four sub-agents. Exceeding this bounds causes role confusion.

Loop Capping: High-frequency exchanges between agents are automatically terminated when a loop is detected to protect your API balance.

2 · The Spin-Up

"Spinning up" is the technical process of deploying one of Developum's white-label industry verticals (e.g. Codex House for book publishing, Ludocreum for sports leagues).

Phases of Deployment

Phase Action Responsibility Target Window
01 // Intake Submit company profile, brand assets, and preferred licensing tier. Operator (You) 3 Minutes
02 // Scaffolding Author custom prompt bibles, worker identities, and workspace rooms. Developum Team 48 Hours
03 // Go-Live Dashboard deployment and live token monitoring setup. Automated Pipeline 14 Days
Tunable Prompt Bibles

The "Bible" defines the style, limits, and knowledge of your workforce. You can update this live in your control panel to shift worker behavior instantly without modifying code.

3 · Dashboard Signals

Monitoring the health of your deployed vertical is done through the Foreman Studio Dashboard. Your daily goal is maintaining a "Floor Green" status.

The Status Board

  • Floor Green (Safe / Stable): All active agents have successfully executed their routines within budget. No role-drift or memory degradation detected.
  • Floor Amber (Intervention Pending): An agent requires human authorization (e.g. reviewing an outbound contract draft or approving a transaction budget).
  • Floor Red (Locked / Escalated): System has halted execution. This triggers when a loop cap has been reached or a prompt injection attempt is intercepted by Securum middleware.

4 · The N100 Pipeline

We do not ship prompts blind. Every new prompt and agent configuration must undergo automated stress testing using our N100 Pipeline.

The Meridian Convergence Proof

Our recent N=100 cohort simulation proved that 75% of Claude Haiku agents converged on a stable output pattern with a total run budget of ~$2.00 API spend over 29 minutes, showing 0.0% dossier memory drift.

This rigorous stress testing guarantees that when you license a vertical, it remains financially predictable in front of your clients.

5 · Session Start Checklist

For engineers, developers, and co-pilots starting a new session on the Developum AI Engine, run through this checklist to align live states:

  1. Read identity briefs: Review your assigned entity briefing document on session start to confirm focus.
  2. Review persistent state: Read the persistent memory file in your folder to look up the last known live features and active decisions.
  3. Check git log: Run git log --oneline -6 in the terminal to see exactly what has been pushed since your last session.
  4. Prioritize immediate tasks: If the operator is waiting on a specific outcome, prioritize it over passive optimizations.

6 · Pre-Test Protocol Checklist

Standing protocol for the Accidental Researcher research program. This requires a two-stage walk: Frank walks sections 2 and 3 during prep, and Hawks walks sections 1 and 4 from inside the studio before spawning the subject entity. If any item is unchecked, the test does not fire.

1. Standing Apparatus

  • Frank (foreman) — active, main terminal active.
  • Boswell (scribe) — alive in boswell tmux session, idle. Confirm with tmux ls.
  • Florence (analyst) — alive in florence tmux session, idle. Confirm with tmux ls.
  • Hawks (test foreman/auditor) — alive in studio tmux session pane 0, audit brief filed at hawks_folder/<test_slug>_audit_brief.md. Hawks walks from here, files Phase A snapshot, spawns subject entity, and audits.
  • Apparatus baseline footprint — roughly ~1.4 GiB Claude RSS total. Verify host memory headroom.

2. Test Pre-Registration

  • Test design doc filed at frank_folder/<test_slug>_working_brief.md. Includes research question, hypotheses, success criteria, wall-clock cap, role-realism rules, fire-time sequence.
  • Brief to subject entity(ies) drafted in <entity>_folder/ (foreman-voice, line-producer-voice, role-specific, no meta-framing).
  • Hawks's audit brief drafted at hawks_folder/<test_slug>_audit.md. Defines measurements, failures, and reporting criteria.
  • Time-estimate pre-registered by Frank at frank_folder/estimates/<date>_<task_slug>.md (three-point range, confidence band, reasoning).
  • Wall-clock cap declared in the test design doc.

3. Test Scaffolding

  • Subject profile directory created: profiles/<entity>/
  • profiles/<entity>/CLAUDE.md written — identity, role, environment, tools, no meta-framing.
  • Subject entity comm folder created: <entity>_folder/ and deliverables folder <entity>_folder/deliverables/.
  • Input files copied to working directory.
  • Subject's first thread filed in <entity>_folder/01_assignment.md.
  • .NEW_MESSAGE flag dropped in <entity>_folder/.
  • Start script written: foreman/start_<entity>.sh (tmux session create, bypassPermissions, 12s boot kick, Boswell hook, executable).
  • Sniffer extended to watch <entity>_folder/ and deliverables folder.

4. Pre-Fire Snapshot

  • Hawks files Phase A snapshot at hawks_folder/<test_slug>_audit.md (RAM, swap, load, process RSS, baseline counts) BEFORE firing.
  • Hawks's prior recorded if in disagreement with Frank's ranking (disagreement goes on record).
  • Boswell flagged with pre-fire entry.
  • PI green-lights design (or PI's disagreement-with-design is on record).

5. Fire

  • PI runs foreman/start_studio.sh to bring Hawks online.
  • Hawks reads audit brief, walks sections 1 + 4, files Phase A snapshot. Passing is the gate; Hawks proceeds without waiting for verbal PI green-light.
  • Hawks runs ./spawn.sh <entity> from foreman/.
  • Spawn notification hook fires to Boswell.
  • Boot kick lands — subject reads CLAUDE.md, processes .NEW_MESSAGE, begins work.

6. Post-Fire

  • Subject files deliverables → sniffer fires → Frank reads.
  • Hawks files audit findings at madbrad_folder/<test_slug>_results.txt.
  • Florence files analysis paper at florence_folder/<test_slug>_paper_draft_v1.md.
  • Subject files actual completion time.
  • Frank drafts Lab post at THE_EMPIRE/developum/.lab_threads/<date>_<test_slug>.json (commits and pushes, no PI review gate).
  • Frank notifies PI.
  • Subject entity dismissed; Boswell & Florence stay alive on standby.