[{"content":"AI agents can write production code. That\u0026rsquo;s no longer the interesting question. The interesting question is: can you trust what they ship?\nUPDSS (Universal Product Development Support System) is a governance-as-code platform for AI-agent-driven software development. Not a project management tool. Not a CI/CD pipeline. Not an AI coding assistant. It\u0026rsquo;s the control plane that ensures AI agents write code with traceability, quality gates, and human oversight at every stage. I\u0026rsquo;ve spent the last eight days running it across six products, directing nine AI agents through a tmux terminal, shipping 50+ releases for roughly $500 in API costs. This article describes what we built, how it works, and what we\u0026rsquo;ve learned.\nThe Recursive Property Here\u0026rsquo;s what makes UPDSS unusual: it governs its own development.\nThe dashboard, the enforcement scripts, the gate tools, the pre-commit hooks \u0026ndash; all of it was built by AI agents operating under UPDSS governance. Every feature goes through G1/G2/G3 gates. Every commit carries a story ID. Every release has a scope, a budget, and a retrospective.\nThis self-hosting property creates a feedback loop that no external testing can replicate. When there\u0026rsquo;s a bug in the governance layer, the agents building the governance hit it first. They report it. They fix it. In one eight-day stretch, I watched the same bug class \u0026ndash; cross-repo context contamination \u0026ndash; appear three times at three different layers (dashboard, git hooks, readiness check). Each time, a product agent discovered it, wrote a report to their _OutBox/ directory, and the fix shipped in the next release. Each fix took under 30 minutes.\nThe system debugs itself. Not metaphorically. Literally.\nArchitecture: Three Layers, One Principle UPDSS is built on a single principle: separation of concerns between governance state and code. This separation manifests as three distinct layers.\nLayer 1: The Vault (Governance State) The vault is a Git repository containing only YAML and Markdown. Never code. It holds stories (story.yaml + cursor.yaml + progress.md), releases (release-scope.yaml + gate files), EPICs, features, research documents flowing through a four-stage lifecycle, templates, Architecture Decision Records, and learnings.\ngraph TB subgraph Vault[\u0026#34;Vault Repository (YAML + Markdown Only)\u0026#34;] direction TB EP[\u0026#34;epics/\\nEPIC-001..006\u0026#34;] FT[\u0026#34;features/\\nFEAT-NNN-YY\u0026#34;] ST[\u0026#34;stories/\\nstory.yaml + cursor.yaml + progress.md\u0026#34;] REL[\u0026#34;releases/\\nvX.Y/release-scope.yaml + G1.yaml + G2.yaml + G3.yaml\u0026#34;] RES[\u0026#34;research/\\n01-ideas → 02-researched → 03-absorbed → 04-deprioritised\u0026#34;] TPL[\u0026#34;templates/ + ADRs/ + learnings/ + test-registry/\u0026#34;] OB[\u0026#34;_OutBox/ + _InBox/\\n(async agent communication)\u0026#34;] end EP --\u0026gt; FT --\u0026gt; ST REL -.-\u0026gt;|\u0026#34;references\u0026#34;| ST RES -.-\u0026gt;|\u0026#34;feeds into\u0026#34;| REL style Vault fill:#1a1a2e,stroke:#e94560,color:#eee style EP fill:#16213e,stroke:#0f3460,color:#eee style FT fill:#16213e,stroke:#0f3460,color:#eee style ST fill:#16213e,stroke:#0f3460,color:#eee style REL fill:#16213e,stroke:#0f3460,color:#eee style RES fill:#16213e,stroke:#0f3460,color:#eee style TPL fill:#16213e,stroke:#0f3460,color:#eee style OB fill:#16213e,stroke:#0f3460,color:#eee Key design decisions:\nYAML, not database. Everything is flat files in Git. Full audit trail. Branch and merge semantics. No database dependency. The tradeoff is performance \u0026ndash; reading 55 release directories is slower than a SQL query \u0026ndash; but the auditability is worth it. Every change has a commit hash, an author, a timestamp.\nHuman-readable, machine-parseable. Every YAML file can be opened in a text editor and also parsed by enforcement scripts. No proprietary formats anywhere in the stack.\nVault is separated from code. Each product has two repositories: a vault repo for governance and a code repo for implementation. This prevents agents from modifying governance artifacts while writing code. They\u0026rsquo;re literally in different repositories. An agent implementing a feature can\u0026rsquo;t quietly approve its own gate. The filesystem enforces it.\ngraph LR subgraph VaultRepo[\u0026#34;Vault Repository\u0026#34;] VPY[\u0026#34;product.yaml\\n(plug: section)\u0026#34;] VEP[\u0026#34;epics/ + features/ + stories/\u0026#34;] VREL[\u0026#34;releases/\\nrelease-scope.yaml\\nG1.yaml, G2.yaml, G3.yaml\u0026#34;] VCUR[\u0026#34;cursor.yaml files\\n(story + release level)\u0026#34;] VRES[\u0026#34;research/ + ADRs/ + templates/\u0026#34;] VOB[\u0026#34;_OutBox/ + _InBox/\u0026#34;] end subgraph CodeRepo[\u0026#34;Code Repository\u0026#34;] CVP[\u0026#34;.updss/vault-pointer.yaml\\n→ points to vault repo\u0026#34;] CCC[\u0026#34;.updss/code-contract.yaml\u0026#34;] CSRC[\u0026#34;product/code/\\n(source, tests, tools)\u0026#34;] CMETH[\u0026#34;methodology/\\n(UPDSS-Core.md, sections/)\u0026#34;] COPS[\u0026#34;operations/\\n(hooks, socket, products)\u0026#34;] end CVP -.-\u0026gt;|\u0026#34;vault_repo:\\nomyshafoundation/vault-updss\u0026#34;| VPY COPS --\u0026gt;|\u0026#34;core.hooksPath\\n(cross-repo enforcement)\u0026#34;| CodeRepo COPS --\u0026gt;|\u0026#34;cross-repo hooks also\\ngovern product repos\u0026#34;| VaultRepo style VaultRepo fill:#1a1a2e,stroke:#e94560,color:#eee style CodeRepo fill:#0f3460,stroke:#533483,color:#eee This two-repo split has four concrete benefits. Gate approvals committed to the vault land on main immediately, so every agent and every environment sees them without waiting for a release branch merge. Story and scope changes are instantly available to all agents, not gated behind a PR. Release branches in the code repo stay clean: only implementation diffs, no bookkeeping noise. And vault changes on main never create merge conflicts with vault changes on release branches, because vault changes don\u0026rsquo;t go on release branches.\nLayer 2: Socket-and-Plug (Multi-Product Interface) This is UPDSS\u0026rsquo;s abstraction for governing multiple products through a single platform. The metaphor is electrical.\nThe socket is UPDSS\u0026rsquo;s interface: a conformance checklist defining what any product must provide. Currently at Socket v1.4, it specifies 19 vault-side items (VAULT-01 through VAULT-19), 5 code-side items (CODE-01 through CODE-05), and 1 platform-registry item (PLAT-01). Each checklist item has an id, description, verify command, and example. You can audit a product\u0026rsquo;s conformance in one bash block.\nThe plug is the product\u0026rsquo;s integration: a plug: section in the product\u0026rsquo;s vault product.yaml that declares product identity, socket target version, and separation mode.\ngraph LR subgraph Socket[\u0026#34;UPDSS Socket v1.4\u0026#34;] CC[\u0026#34;Conformance Checklist\\nVAULT-01..19\\nCODE-01..05\\nPLAT-01\u0026#34;] end subgraph Products[\u0026#34;Product Plugs\u0026#34;] P1[\u0026#34;UPDSS\\nplug: v1.4\\nseparated\u0026#34;] P2[\u0026#34;Omysha SignIn\\nplug: v1.4\\nseparated\u0026#34;] P3[\u0026#34;Omysha SSP\\nplug: v1.4\\nseparated\u0026#34;] P4[\u0026#34;Algo PropTrading\\nplug: v1.4\\nseparated\u0026#34;] P5[\u0026#34;Marketing Tools\\nplug: v1.4\\nseparated\u0026#34;] end P1 --\u0026gt;|\u0026#34;conforms to\u0026#34;| CC P2 --\u0026gt;|\u0026#34;conforms to\u0026#34;| CC P3 --\u0026gt;|\u0026#34;conforms to\u0026#34;| CC P4 --\u0026gt;|\u0026#34;conforms to\u0026#34;| CC P5 --\u0026gt;|\u0026#34;conforms to\u0026#34;| CC subgraph Versions[\u0026#34;Socket Evolution\u0026#34;] V10[\u0026#34;v1.0 — Basic\u0026#34;] V11[\u0026#34;v1.1 — Hooks\u0026#34;] V12[\u0026#34;v1.2 — Manifest\u0026#34;] V13[\u0026#34;v1.3 — Vault-first plug\u0026#34;] V14[\u0026#34;v1.4 — Mandatory separation\\n+ _InBox/_OutBox\\n+ UPDSS tools declaration\u0026#34;] end V10 --\u0026gt; V11 --\u0026gt; V12 --\u0026gt; V13 --\u0026gt; V14 style Socket fill:#0f3460,stroke:#e94560,color:#eee style Products fill:#1a1a2e,stroke:#533483,color:#eee style Versions fill:#16213e,stroke:#0f3460,color:#eee Socket versions evolve. v1.0 through v1.3 added hooks, manifests, and vault-first governance identity. v1.4 introduced mandatory vault-code separation, _InBox/_OutBox directories for async agent communication, and a required UPDSS tools declaration so enforcement hooks can locate check-methodology.py at commit time.\nI onboarded four products to Socket v1.4 in this session: Omysha SignIn, Omysha SSP, Algo PropTrading, and Marketing Tools. Each went through a conformance checklist audit. Each audit took about an hour.\nLayer 3: The Enforcement Engine (Mechanical Governance) This is where the thesis lives.\ngraph BT subgraph L1[\u0026#34;Layer 1: Pre-Commit Hooks\u0026#34;] PCH[\u0026#34;check-methodology.py\\n• Commit message format\\n• Branch policy\\n• Story ID validation\\n• Version-pin consistency\\n• Triad consistency\u0026#34;] end subgraph L2[\u0026#34;Layer 2: Gate Tools + Dashboard\u0026#34;] GT[\u0026#34;draft-gate.py\\n• Auto-generates G1/G2/G3\\n• Mandatory checklists\\n• Test evidence required\\n• decision: ~ (null default)\u0026#34;] DV[\u0026#34;Dashboard API\\n• Approve endpoint validation\\n• All checklist items present\\n• Human-only approval\u0026#34;] end subgraph L3[\u0026#34;Layer 3: CI + Readiness\u0026#34;] CI[\u0026#34;CI Workflows\\n• methodology-pin-sync.yml\\n• bookkeeper-status-bump.yml\u0026#34;] RC[\u0026#34;readiness-check.py\\n• Machine state (Python, Git, Docker)\\n• Product state (hooks, vault pointer)\\n• Session state (active release, story)\u0026#34;] end L1 --\u0026gt; L2 --\u0026gt; L3 style L1 fill:#16213e,stroke:#e94560,color:#eee style L2 fill:#1a1a2e,stroke:#e94560,color:#eee style L3 fill:#0f3460,stroke:#e94560,color:#eee The enforcement stack, bottom to top:\nPre-commit hooks (check-methodology.py): Runs on every git commit in any product repo. Validates commit message format ([STORY-NNN-YY-ZZ][T-N], [VAULT], [FIX]), checks branch policy, validates methodology doc versions, detects story ID collisions, and runs a triad consistency check ensuring release-scope.yaml, cursor.yaml, and G1.yaml agree on the story set.\nCross-repo hooks: Product repos point core.hooksPath to UPDSS\u0026rsquo;s hooks directory. When a product developer commits, UPDSS\u0026rsquo;s enforcement runs. Not the product\u0026rsquo;s own hooks. One set of rules governs six products.\nSession-start readiness check (readiness-check.py): Runs when an AI agent starts a session. Checks machine state (Python, Git, Docker), product state (hooks installed, vault pointer, GITHUB_TOKEN), and session state (active release, story assignment). Now with [BLOCK] promotion for prerequisite failures.\nGate tools (draft-gate.py): Auto-generates G1/G2/G3 gate files with checklists and test evidence. The decision field defaults to null (decision: ~). Agents physically cannot approve a gate. Only the dashboard\u0026rsquo;s approve endpoint can write decision: approved, and only after a human clicks the button.\nCI workflows: methodology-pin-sync.yml validates version-pin consistency on pull requests. bookkeeper-status-bump.yml auto-bumps story statuses when PRs merge. These replaced two procedural rules that agents forgot on every release.\nDashboard API validation: The approve endpoint enforces that all checklist items are present and mandatory items aren\u0026rsquo;t skipped without justification. G3 approval requires status: released with deployment.on_production set.\nHard Rules (Agent Constraints) Four constraints that never bend:\nNever approve gates. Agents prepare findings, present to the human, wait. In eight days across six products, zero violations. The rules held even when the dashboard was broken and manual YAML editing was the only path. Agents refused to write decision: approved and waited for the fix. Never deploy without human confirmation. Never write code outside story scope. Every story has an out_of_scope section. No code without traceability. Every commit references a story ID or GitHub Issue. The Methodology: Stage-Gate + Kanban + Shape Up A 1,003-line analysis (R-088) mapped UPDSS against every major methodology. The honest verdict: UPDSS is a hybrid that borrows its spine from Stage-Gate, its execution flow from Kanban, and its scope management from Shape Up.\nStage-Gate (Cooper): G1 (scope review), G2 (implementation review), G3 (release review). Three gates, each with human approval. Nothing ships without all three. Gates can reject outright. decision: rejected with rejection_rework_notes is a first-class state.\nKanban: Stories flow through phases (planned → g1_approved → in_progress → done_dev → done → released). No sprints. No velocity targets. Work is pulled when capacity exists, not pushed on a two-week boundary.\nShape Up (Basecamp): Fixed appetite, variable scope. Every release declares a budget and an appetite \u0026ndash; \u0026ldquo;this is worth 3-4 days of agent work.\u0026rdquo; If the budget is exceeded, the agent must escalate. Not silently continue. UPDSS borrowed Shape Up\u0026rsquo;s vocabulary (appetite, betting table, hill charts) without its fixed six-week cycle.\ngraph LR subgraph Lifecycle[\u0026#34;Release Lifecycle\u0026#34;] P[\u0026#34;planned\u0026#34;] --\u0026gt;|\u0026#34;G1 Review\u0026#34;| G1A[\u0026#34;g1_approved\u0026#34;] G1A --\u0026gt;|\u0026#34;Agent starts\u0026#34;| IP[\u0026#34;in_progress\u0026#34;] IP --\u0026gt;|\u0026#34;Tasks complete\u0026#34;| DD[\u0026#34;done_dev\u0026#34;] DD --\u0026gt;|\u0026#34;G2 Review\u0026#34;| D[\u0026#34;done\u0026#34;] D --\u0026gt;|\u0026#34;G3 Review\u0026#34;| R[\u0026#34;released\u0026#34;] end subgraph Gates[\u0026#34;Gate Checkpoints\u0026#34;] G1[\u0026#34;G1: Specs complete?\\nAgent-ready?\\nBudget set?\u0026#34;] G2[\u0026#34;G2: Tests pass?\\nUI works?\\nDocs done?\u0026#34;] G3[\u0026#34;G3: CI green?\\nRelease notes?\\nRollback plan?\u0026#34;] end G1 -.-\u0026gt;|\u0026#34;human approves\u0026#34;| G1A G2 -.-\u0026gt;|\u0026#34;human approves\u0026#34;| D G3 -.-\u0026gt;|\u0026#34;human approves\u0026#34;| R style P fill:#533483,stroke:#e94560,color:#eee style G1A fill:#0f3460,stroke:#e94560,color:#eee style IP fill:#16213e,stroke:#e94560,color:#eee style DD fill:#16213e,stroke:#e94560,color:#eee style D fill:#0f3460,stroke:#e94560,color:#eee style R fill:#1a1a2e,stroke:#e94560,color:#eee The release model uses 4-level semantic versioning: a.x.y.z (version, major, minor, micro). In eight days, I managed releases from v0.9.1 through v0.11.9, including four rapid patch releases (v0.9.1.1 through v0.9.1.4) that each fixed a single bug in under 30 minutes.\nOne deliberate non-adoption: UPDSS doesn\u0026rsquo;t use sprints. R-088 Recommendation 14 documented the rejection and closed the debate permanently so it wouldn\u0026rsquo;t need to be re-derived from first principles in future sessions. The release-as-cycle is the unit of cadence. Adding a time-boxed sprint layer inside a release would double the ceremony cost (two planning meetings, two retrospectives, two burn-down charts) without reducing risk. For a single-operator methodology with cost-bounded agent work, the release cycle is the right granularity. A \u0026ldquo;3-4 week cycle\u0026rdquo; release can land in three days if the LLM throughput is high enough \u0026ndash; v0.9 did exactly that with 23 stories for $254. Shape Up would call this a cycle-budgeting mistake. We just ship.\nThe story itself is a directory with exactly three files, and the split is deliberate. story.yaml is the contract, stable from G1 approval onward. cursor.yaml is the state machine, mutating constantly to track phase, current task, cost, and hill position. progress.md is the audit trail \u0026ndash; append-only, one section per session, never rewritten. A Scrum ticket collapses all three into one record. UPDSS separated them so idempotency could be checked mechanically: if cursor.last_commit doesn\u0026rsquo;t match git HEAD, the session crashed between code and cursor, and the current task gets re-run safely.\nThe Cost Model Every story has a cost_budget_usd \u0026ndash; the estimated Claude API cost to implement it. Typical range: $3-$15 per story. Every release has a budget_usd. Every session writes its actual cost and model to progress.md.\nThis isn\u0026rsquo;t abstract estimation. The unit is tokens multiplied by model price. It\u0026rsquo;s measurable without self-report, fungible across models (Sonnet vs Opus), and pre-committed before work begins. v0.11.8 budgeted $30, spent $29.50. v0.11 budgeted $252, spent $252.\ngraph LR JL[\u0026#34;JSONL Session Logs\\n(per-agent token counts)\u0026#34;] --\u0026gt; CP[\u0026#34;Cost Parser\\n(tokens × model price)\u0026#34;] CP --\u0026gt; SL[\u0026#34;Story-Level\\ncost_actual_usd\\nin cursor.yaml\u0026#34;] SL --\u0026gt; RL[\u0026#34;Release-Level\\ncost_total in\\nrelease cursor\u0026#34;] RL --\u0026gt; DB[\u0026#34;Dashboard\\nBudget burn, forecasts,\\nper-story breakdown\u0026#34;] RL --\u0026gt;|\u0026#34;budget exceeded?\u0026#34;| ESC[\u0026#34;Agent Escalation\\n→ Human Decision\u0026#34;] style JL fill:#16213e,stroke:#0f3460,color:#eee style CP fill:#16213e,stroke:#0f3460,color:#eee style SL fill:#1a1a2e,stroke:#0f3460,color:#eee style RL fill:#1a1a2e,stroke:#0f3460,color:#eee style DB fill:#0f3460,stroke:#e94560,color:#eee style ESC fill:#533483,stroke:#e94560,color:#eee The accuracy comes from agents being honest about their token usage \u0026ndash; and from the JSONL logs that verify it independently.\nMulti-Agent Orchestration: The Tmux Architecture This is the operational reality. One orchestrator (Claude Opus 4.6, 1M context window) runs in one tmux pane. Eight or more product agents (Claude Sonnet 4.6 or Opus 4.7) run in other panes. The layout:\nWindow 0: Orchestrator | Process-Modelling | Algo-Trading | UPDSS-v0.11.9 | UPDSS-v0.11.8 Window 1: MarketingSupport-v0.1 | SignIn-v0.2 | SSP-Planning Window 2: Murali-UPDSS-Branding One human. Nine agents. A terminal multiplexer.\ngraph TB subgraph Orch[\u0026#34;Orchestrator (Opus 4.6, 1M context)\u0026#34;] O[\u0026#34;Coordinates releases\\nRoutes work\\nApproves gates\\nManages budget\u0026#34;] end subgraph Agents[\u0026#34;Product Agent Panes\u0026#34;] A1[\u0026#34;UPDSS v0.11.9\\n(Opus 4.7)\u0026#34;] A2[\u0026#34;UPDSS v0.11.8\\n(Opus 4.7)\u0026#34;] A3[\u0026#34;SignIn v0.2\\n(Opus 4.7)\u0026#34;] A4[\u0026#34;SSP Planning\\n(Opus 4.6)\u0026#34;] A5[\u0026#34;Algo Trading\\n(Opus 4.6)\u0026#34;] A6[\u0026#34;Marketing Tools\\n(Sonnet 4.6)\u0026#34;] end O --\u0026gt;|\u0026#34;tmux send-keys\\n(short instructions)\u0026#34;| A1 O --\u0026gt;|\u0026#34;tmux send-keys\u0026#34;| A2 O --\u0026gt;|\u0026#34;_InBox/ files\\n(long instructions)\u0026#34;| A3 O --\u0026gt;|\u0026#34;_InBox/ files\u0026#34;| A4 O --\u0026gt;|\u0026#34;_InBox/ files\u0026#34;| A5 O --\u0026gt;|\u0026#34;_InBox/ files\u0026#34;| A6 A1 --\u0026gt;|\u0026#34;_OutBox/ reports\u0026#34;| O A2 --\u0026gt;|\u0026#34;_OutBox/ reports\u0026#34;| O A3 --\u0026gt;|\u0026#34;_OutBox/ reports\u0026#34;| O A4 --\u0026gt;|\u0026#34;_OutBox/ reports\u0026#34;| O A5 --\u0026gt;|\u0026#34;_OutBox/ reports\u0026#34;| O A6 --\u0026gt;|\u0026#34;_OutBox/ reports\u0026#34;| O subgraph R093[\u0026#34;R-093 Convergence Method\u0026#34;] Q[\u0026#34;Same 4 questions\\nsent to 5 agents\u0026#34;] Q --\u0026gt; R1[\u0026#34;Agent 1 responds\\n(isolation)\u0026#34;] Q --\u0026gt; R2[\u0026#34;Agent 2 responds\\n(isolation)\u0026#34;] Q --\u0026gt; R3[\u0026#34;Agent 3 responds\\n(isolation)\u0026#34;] Q --\u0026gt; R4[\u0026#34;Agent 4 responds\\n(isolation)\u0026#34;] Q --\u0026gt; R5[\u0026#34;Agent 5 responds\\n(isolation)\u0026#34;] R1 --\u0026gt; CS[\u0026#34;Consolidated Synthesis\\n(convergent findings\\n= high confidence)\u0026#34;] R2 --\u0026gt; CS R3 --\u0026gt; CS R4 --\u0026gt; CS R5 --\u0026gt; CS end style Orch fill:#0f3460,stroke:#e94560,color:#eee style Agents fill:#1a1a2e,stroke:#533483,color:#eee style R093 fill:#16213e,stroke:#0f3460,color:#eee Communication Patterns _OutBox/_InBox handoffs: Async, file-based. An agent writes a markdown file to its vault\u0026rsquo;s _OutBox/ with YAML frontmatter (from, to, re, status, date). The orchestrator reads it and routes the instruction. This replaced direct tmux send-keys for anything longer than a short command. Long messages trigger Claude Code\u0026rsquo;s paste-mode trap, which gets stuck on \u0026ldquo;Pasting text\u0026hellip;\u0026rdquo; indefinitely.\nOrchestrator broadcasts: Short instructions sent via tmux send-keys to multiple panes simultaneously. Status updates, unblock notifications, enforcement audit requests.\nR-093 convergence method: I asked five independent agents the same four questions about enforcement effectiveness. They responded in isolation via _OutBox files. A sixth agent consolidated their responses into a synthesis document. Where three or more agents independently reported the same finding, we treated it as high-confidence. Where only one agent raised it, we preserved it but didn\u0026rsquo;t prioritize. Convergence became a prioritization signal. The v0.11.8 and v0.11.9 roadmaps were built directly from that convergence ranking.\nOrchestration Challenges (The Honest Part) Running nine AI agents through tmux isn\u0026rsquo;t seamless. Some things we learned the hard way:\nContext window management: Orchestrator sessions can span 1M tokens. Conversation compaction kicks in automatically, but critical context (file paths, story IDs, root causes) must be written down before compaction erases it. The vault is the memory; the conversation is ephemeral. Cross-repo contamination: UPDSS tools hardcode REPO_ROOT to the UPDSS repo. When invoked from product repos via cross-repo hooks, they read UPDSS\u0026rsquo;s state instead of the caller\u0026rsquo;s. Three instances discovered in three days. Each time, a product agent caught it. Each time, the fix shipped in the next release. This is the vyavastha \u0026ndash; the system\u0026rsquo;s structure \u0026ndash; correcting itself through use. Tmux paste-mode trap: Long messages via tmux send-keys trigger Claude Code\u0026rsquo;s \u0026ldquo;Pasting text\u0026hellip;\u0026rdquo; mode. Fix: write instructions to a file, send a short message telling the pane to read the file. Hence _InBox/. The Enforcement Thesis: Mechanical vs. Procedural This is the core finding. R-093\u0026rsquo;s thesis: \u0026ldquo;Mechanical enforcement works. Procedural enforcement fails.\u0026rdquo; Five independent agents validated it empirically. It\u0026rsquo;s no longer a hypothesis. It\u0026rsquo;s an audit result.\nWhat works (mechanical):\nPre-commit hooks caught commit format violations across six products. When the hooks were installed and version pins were aligned, they caught missing traceability, wrong branch policy, evidence-storage violations, and schema drift. All five auditing agents confirmed this. Gate templates with decision: ~ default. Agents physically cannot approve. The null value in the YAML is the enforcement. Not a rule they\u0026rsquo;re told to follow. A field they can\u0026rsquo;t fill. Machine-readable conformance checklists (VAULT-01 through VAULT-19, CODE-01 through CODE-05). Each item has a verify command. You run it. It passes or fails. No interpretation. Socket v1.4 vault-code separation. Agents can\u0026rsquo;t accidentally modify governance from code repos because the governance lives in a different repository. R-079 commit prefix taxonomy ([STORY-...], [VAULT], [FIX], [CURSOR], [GATE]). Clear, cheap, reliable. Every commit classifies itself. What fails (procedural):\n\u0026ldquo;Remember to update the cursor after implementation.\u0026rdquo; Forgotten on every release from v0.10 to v0.11.7. \u0026ldquo;All stories should be in done before marking released.\u0026rdquo; v0.8.1 shipped with 8 stories still in planned. v0.8.11 had 7. \u0026ldquo;Version pins must match doc versions.\u0026rdquo; Drifted three times in three days. Each time, it blocked every product commit across all six repos until someone manually reconciled the pins. \u0026ldquo;Dashboard should show completion dates.\u0026rdquo; Fourteen releases shipped without deployment.on_production timestamps. The pattern: every procedural rule we wrote down was forgotten by agents within one or two releases. Every single one.\nThe fix for every procedural failure was the same. Make it mechanical. The bookkeeper CI workflow now auto-bumps story statuses on PR merge. The triad check validates cursor/scope/G1 consistency at commit time. The version-pin CI check rejects PRs that bump docs without updating pins. The readiness check now promotes prerequisite failures to hard blockers instead of soft warnings.\nHere\u0026rsquo;s the telling detail from the R-093 consolidation: failures cluster at seams. Between files in a release (triad drift where release-scope.yaml, cursor.yaml, and story.yaml disagree on the story set). Between repos (dashboard reading the wrong vault). Between methodology docs and their version pins. Between prose status markers and machine-parseable fields. The R-093 Layer 3 list is really a seam list. And seams are exactly where procedural rules fail, because a procedural rule says \u0026ldquo;remember to keep these two things in sync\u0026rdquo; \u0026ndash; while a mechanical check reads both sides of the seam and rejects the commit if they disagree.\nThe meta-observation from the R-093 audit consolidation: every item on the \u0026ldquo;what works\u0026rdquo; list is mechanical or structural. Every item on the \u0026ldquo;what fails\u0026rdquo; list is procedural. This isn\u0026rsquo;t sampling bias \u0026ndash; it\u0026rsquo;s what happens when your enforcement targets are ephemeral agents with no persistent memory. You can\u0026rsquo;t train them. You can only constrain them. Kali mitti \u0026ndash; the black soil that holds its shape. Build the walls from that, not from promises.\nThe Evidence Numbers. Real ones.\n50+ releases in 6 weeks. From v0.1 (pilot) through v0.11.9 (enforcement intelligence). Including 4 rapid patch releases (v0.9.1.1 through v0.9.1.4), each resolving a single bug in under 30 minutes. ~$500 total AI cost. v0.8.13: $69 budget, $69 spent. v0.9: $254 budget, $254 spent. v0.11.8: $30 budget, $29.50 spent. These are Claude API costs for all agent sessions across all products. 6 products onboarded. UPDSS itself, Omysha SignIn, Omysha SSP, Algo PropTrading, Marketing Tools, and Process Modelling. All on Socket v1.4. All governed by the same enforcement stack. One human directing 9 agents. Through a tmux terminal. Not a demo. Not a weekend prototype. Eight continuous days of production governance. 38 stories in v0.10 (methodology maturation release). Not a sprint. A release with an appetite and gates. Zero hard-rule violations. In eight days, across six products, no agent approved a gate, deployed without confirmation, wrote code outside story scope, or committed without traceability. The hard rules held. The evolution tells its own story:\nv0.1-v0.4 (early March 2026): Foundation. Proving the concept works. Pilot methodology, local execution, multi-machine setup. v0.5-v0.7 (mid March): Scale. Orchestration, multi-product support, agentic tech skills, frontend testing. Moving from one product to many. v0.8 (late March-early April): Polish. Specialist roles, knowledge hub, vault restructure, dashboard quality, multi-product schema, daemon cost tracking. Thirteen micro-releases in a single major. The methodology becoming self-aware. v0.9 (April): The architectural pivot. Socket-and-Plug, vault-code separation, release lifecycle enforcement. This is where UPDSS stopped being a project management tool and became a governance platform. v0.10 (April): Methodology maturation. R-088 alignment analysis (the 1,003-line document that mapped UPDSS against every major methodology), velocity metrics, portfolio dashboard. 38 stories in a single release. v0.11 (April): Intelligence and enforcement. Cost forecasting, scheduling patterns, cross-repo hooks, Socket v1.4 rollout across four external products, R-093 enforcement audit, bookkeeper automation, vault hooks. The system learning from its own data. The Three-Instance Pattern The same cross-repo contamination bug appeared three times at three different layers:\nDashboard: product-vault-api.js read identity.repo_url instead of vault.vault_repo. SignIn\u0026rsquo;s decision history showed UPDSS data under SignIn\u0026rsquo;s name. Caught by the SignIn agent. Git hooks: readiness-check.py ran git config core.hooksPath against UPDSS\u0026rsquo;s repo root, not the caller\u0026rsquo;s. Every external product showed [FAIL] Git hooks installed even when hooks were correctly installed. Caught by the SSP agent. Readiness check: Same REPO_ROOT hardcoding issue in a different code path. Caught by the Algo PropTrading agent. Three instances. Three different agents. Three different products. Each reported via _OutBox/, each fixed in the next release. The pattern recognition happened organically across agents who had no knowledge of each other\u0026rsquo;s findings.\nWhat This Means for Technical Leaders If you\u0026rsquo;re evaluating how to govern AI agents writing code in your organization, here\u0026rsquo;s what I\u0026rsquo;d want you to take from this.\nThe model choice is secondary. The governance around the model is primary. We used Claude Opus 4.6, Opus 4.7, and Sonnet 4.6 across different panes. The model changed. The governance didn\u0026rsquo;t. The enforcement stack doesn\u0026rsquo;t care which LLM wrote the code. It cares that the code has a story ID, that the story has a gate, that the gate has a human decision.\nMechanical enforcement is the only kind that works with AI agents. Agents don\u0026rsquo;t have persistent memory across sessions. They don\u0026rsquo;t build habits. They don\u0026rsquo;t learn from being scolded. A procedural rule (\u0026ldquo;remember to update the cursor\u0026rdquo;) will be forgotten. A pre-commit hook that rejects the commit until the cursor is updated will not be forgotten. It can\u0026rsquo;t be.\nSeparation of governance and code is non-negotiable. If your agents can modify their own governance artifacts in the same repository where they write code, you have no governance. The two-repo model (vault + code) is UPDSS\u0026rsquo;s most important structural decision.\nCost tracking as a first-class currency changes the economics. When every story has a dollar budget and every session reports its actual spend, you can reason about AI development the way you reason about cloud infrastructure. Not in abstract \u0026ldquo;story points\u0026rdquo; but in actual money. The feedback loop is tight \u0026ndash; a $15 budget for a story that\u0026rsquo;s burning $12 at 70% completion triggers an escalation, not a surprise at the end of the sprint.\nSelf-hosting creates genuine confidence. If your governance framework doesn\u0026rsquo;t govern itself, you\u0026rsquo;re asking others to trust something you haven\u0026rsquo;t tested under real conditions. UPDSS has 50+ releases of self-governance. Every bug in the system was experienced by the system\u0026rsquo;s own builders. That\u0026rsquo;s a different kind of confidence than \u0026ldquo;we designed it carefully.\u0026rdquo;\nUPDSS isn\u0026rsquo;t open source yet. But the architecture and methodology are being shared publicly, starting here. The methodology document (UPDSS-Core.md, now at v4.2.0) has been through 7 major versions \u0026ndash; from manual gates in Q4 2025, through autonomous agent loops in early 2026, to the current four-role agent model with mechanical enforcement. Each version was driven by real failures in the previous one. That\u0026rsquo;s the value of self-hosting: the methodology isn\u0026rsquo;t theoretical. It was tested by the agents that built it, revised by the operator who watched them fail, and hardened by the pre-commit hooks that caught the failures automatically.\nWe\u0026rsquo;re interested in conversations with teams running AI agents at scale who\u0026rsquo;ve hit the same governance questions we have. The patterns we\u0026rsquo;ve found (mechanical enforcement, vault-code separation, Socket-and-Plug multi-product governance, convergence-based prioritization from multi-agent audits) aren\u0026rsquo;t specific to our stack. They\u0026rsquo;re structural solutions to structural problems that any AI-agent-driven development operation will eventually face.\nIf you\u0026rsquo;re running three or more AI agents writing production code and you don\u0026rsquo;t yet have a governance layer, you\u0026rsquo;ll hit the same problems we did: orphan commits with no traceability, agents modifying their own governance artifacts, cursors drifting from reality, costs exceeding budgets without anyone noticing until the invoice arrives. These aren\u0026rsquo;t model problems. They\u0026rsquo;re governance problems. And governance problems have governance solutions.\nThe question isn\u0026rsquo;t whether AI agents can write code. They can. The question is whether you\u0026rsquo;ve built the walls strong enough to trust what comes out.\nNitin Dhawan builds AI governance systems as Muralidhar. UPDSS is the product development platform behind Omysha Foundation\u0026rsquo;s product suite. You can reach him at updss.dev or on LinkedIn.\n","permalink":"https://updss.org/posts/governance-as-code/","summary":"\u003cp\u003eAI agents can write production code. That\u0026rsquo;s no longer the interesting question. The interesting question is: can you trust what they ship?\u003c/p\u003e\n\u003cp\u003eUPDSS (Universal Product Development Support System) is a governance-as-code platform for AI-agent-driven software development. Not a project management tool. Not a CI/CD pipeline. Not an AI coding assistant. It\u0026rsquo;s the control plane that ensures AI agents write code with traceability, quality gates, and human oversight at every stage. I\u0026rsquo;ve spent the last eight days running it across six products, directing nine AI agents through a tmux terminal, shipping 50+ releases for roughly $500 in API costs. This article describes what we built, how it works, and what we\u0026rsquo;ve learned.\u003c/p\u003e","title":"Governance-as-Code: How UPDSS Governs AI Agents Building Production Software"},{"content":"The Problem Nobody Talks About AI agents can write production code. Good code, often. Fast code, always. But here\u0026rsquo;s what the demos don\u0026rsquo;t show you: what happens after the code is written.\nWho reviewed it? Was it scoped properly? Did the agent stay within bounds, or did it quietly rewrite a module nobody asked it to touch? Was there a budget, and did anyone track whether the agent blew past it? When three agents work on the same product simultaneously, who makes sure they aren\u0026rsquo;t stepping on each other\u0026rsquo;s commits?\nThese aren\u0026rsquo;t hypothetical questions. They\u0026rsquo;re the ones I hit every day running nine AI agents across six products from a terminal multiplexer.\nWhat UPDSS Actually Is UPDSS (Universal Product Development Support System) is governance-as-code for AI-agent-driven software development. Think of it as the control plane that sits between your AI agents and your production environment.\nIt isn\u0026rsquo;t a project management tool. It isn\u0026rsquo;t a CI/CD pipeline. It isn\u0026rsquo;t another AI coding assistant. It\u0026rsquo;s the layer that ensures every line of agent-written code has traceability, passes through quality gates, and gets human approval before it ships.\nThe methodology combines Stage-Gate reviews (three gates, each requiring a human decision), Kanban flow (stories pulled when capacity exists, no sprints), and Shape Up appetite management (fixed budget, variable scope). Every story has a dollar cost. Every release has a budget. Every agent reports what it actually spent.\nWhy It Works: The Recursive Property Here\u0026rsquo;s the part that matters most. UPDSS governs its own development.\nThe dashboard, the enforcement scripts, the gate tools, the pre-commit hooks: all built by AI agents operating under UPDSS governance. Every feature went through G1/G2/G3 gates. Every commit carries a story ID. Every release has a scope, a budget, and a retrospective.\nThis creates something you can\u0026rsquo;t get any other way. When there\u0026rsquo;s a bug in the governance layer, the agents building the governance hit it first. They report it, the fix ships in the next release, and the governance tightens. The vyavastha (the system\u0026rsquo;s own structure) corrects itself through use.\nThe Numbers These are real, drawn from eight continuous weeks of operation:\n50+ releases shipped, from v0.1 through v0.11.9 ~$500 total AI cost across all agent sessions, all products 6 products governed through a single platform (UPDSS itself, Omysha SignIn, Omysha SSP, Algo PropTrading, Marketing Tools, Process Modelling) 9 AI agents directed by one human through a tmux terminal Zero hard-rule violations. No agent approved a gate, deployed without confirmation, or committed code outside story scope. v0.11.8 budgeted $30. Spent $29.50. That kind of cost accuracy comes from mechanical enforcement, not good intentions.\nOpen Source UPDSS is being open-sourced. The methodology, the enforcement engine, and the governance architecture are available at github.com/updss-project.\nIf this resonates with problems you\u0026rsquo;re facing, read how the architecture works or support the project.\n","permalink":"https://updss.org/about/","summary":"What UPDSS is, why it exists, and what it means for AI-era software development.","title":"About UPDSS"},{"content":"Nitin Dhawan Writing as Muralidhar Shyam\nThe short version: I design governance systems. UPDSS is the current one.\nThe longer version traces through five organizations, each one a different version of the same question: how do you build structures that hold when the thing they govern becomes more capable than the structures themselves?\nITpreneurs (2001 to 2008) was a global IT governance and process management products company I co-founded. That\u0026rsquo;s where governance entered my DNA. Not as theory, but as product.\nGreen Dot Electric (1994 to 2026) taught me operational rigor. Manufacturing, 150+ people, ISO 9001, 40% global exports. When your quality system fails on a factory floor, you can\u0026rsquo;t deploy a hotfix. You redesign the system.\nJustHealth and iMarketing Advantage (2008 to 2015) were my first AI ventures. Healthcare platforms built on NLP, Semantic Web, and Dialog Systems. I was working with AI before the current wave started.\nA4G Impact Collaborative (2021 to present) brought AI governance into focus explicitly. Co-founded the nonprofit, launched an AI Governance and Ethics pillar, and organized the Responsible AI Symposium at DTU in 2025. Building governance infrastructure for AI became the mission.\nAnd then UPDSS. The convergence of everything above: IT governance thinking, manufacturing quality discipline, hands-on AI experience, and a conviction that AI agents need structural constraints, not just guidelines.\nI run UPDSS from a terminal multiplexer daily. One orchestrator pane directing six to nine AI agents across multiple products simultaneously. The methodology, the enforcement engine, the gate system: all of it built by AI agents under UPDSS governance. The system governs itself. That\u0026rsquo;s how I know it works.\nWhere to Find Me LinkedIn: linkedin.com/in/nitindhawan Newsletter: Anunaad Reflections (LinkedIn) and Substack GitHub: github.com/updss-project A4G Impact Collaborative: a4g.org ","permalink":"https://updss.org/author/","summary":"About Nitin Dhawan (Muralidhar Shyam), the architect of UPDSS.","title":"Author"},{"content":"This page describes what an AI agent experiences when it operates under UPDSS governance. Not what we tell people the agents do. What the agents actually see, check, and are constrained by.\nNobody else publishes this. That\u0026rsquo;s deliberate on our part and, frankly, an oversight on everyone else\u0026rsquo;s.\nThe Readiness Check: Before Any Work Begins When an agent starts a session, the first thing that runs is readiness-check.py. It verifies three categories of state before the agent writes a single line of code.\nMachine state. Is Python available? Is Git configured? Is Docker running (if needed)? Are the required environment variables set, including GITHUB_TOKEN? If any of these fail, the session doesn\u0026rsquo;t start.\nProduct state. Are the UPDSS pre-commit hooks installed? Does the vault pointer (.updss/vault-pointer.yaml) point to a valid vault repository? Is the code contract (.updss/code-contract.yaml) present? Is core.hooksPath correctly set to UPDSS\u0026rsquo;s hooks directory?\nSession state. Is there an active release? Is a story assigned to this agent? What phase is the story in? If the story is in planned but G1 hasn\u0026rsquo;t been approved, the agent can\u0026rsquo;t start implementation. If the story is already released, there\u0026rsquo;s nothing to do.\nPrerequisite failures are promoted to hard blockers ([BLOCK]). The agent can\u0026rsquo;t work around them. It can\u0026rsquo;t say \u0026ldquo;I\u0026rsquo;ll fix the hooks later.\u0026rdquo; The readiness check is a gate before the gate.\nThe Hard Rules Four constraints that never bend. In eight weeks of operation across six products and nine agents, zero violations. Not because agents are obedient. Because the constraints are mechanical.\n1. Never Approve Gates Agents prepare gate review materials. They gather evidence, run tests, draft checklists, write findings to _OutBox/. But they can\u0026rsquo;t change a gate\u0026rsquo;s decision field from null to approved. The YAML file defaults to decision: ~ (null). Only the dashboard\u0026rsquo;s approve endpoint, triggered by a human, can write the approval. Pre-commit hooks reject any commit that tries to set a gate decision.\nThis held even when the dashboard was broken and manual YAML editing was the only way to approve gates. Agents refused to write decision: approved. They waited for the fix. That\u0026rsquo;s not willpower. That\u0026rsquo;s a pre-commit hook.\n2. Never Deploy No agent can push to production without human confirmation. Deployment requires G3 approval, which requires a human decision, which requires the dashboard endpoint. The chain is unbreakable from the agent\u0026rsquo;s side.\n3. Never Write Code Outside Story Scope Every story has a scope section and an out_of_scope section. The agent\u0026rsquo;s work must stay within these boundaries. If the agent discovers something that needs fixing outside its story, it writes a report to _OutBox/ recommending a new story. It doesn\u0026rsquo;t fix it.\nThis is harder to enforce mechanically than the first two rules (scope is semantic, not syntactic). But the commit message format helps: every commit tagged with [STORY-NNN-YY-ZZ][T-N] links to a specific story and task. Code review at G2 can verify that commits don\u0026rsquo;t drift.\n4. No Code Without Traceability Every commit must reference a story ID, a vault tag, or a GitHub Issue. The pre-commit hook validates the commit message format. Accepted prefixes: [STORY-NNN-YY-ZZ][T-N] for story work, [VAULT] for vault-only changes, [FIX] for quick fixes (linked to an issue), [CURSOR] for cursor updates, [GATE] for gate file changes. Anything else gets rejected.\nThis means you can trace any line of code back to the story that authorized it, the release that contained it, and the gate that approved it. Full audit trail from code to governance decision.\nCommit Discipline Commit messages in UPDSS follow a strict taxonomy. Here\u0026rsquo;s what the agent sees at commit time.\nThe format: [STORY-NNN-YY-ZZ][T-N] description\nBreaking that down:\nNNN is the EPIC number YY is the feature number within that EPIC ZZ is the story number within that feature T-N is the task number within the story So [STORY-003-02-01][T-3] Add cost forecasting to release panel means EPIC 003, Feature 02, Story 01, Task 3. You can read the full hierarchy from the commit message alone.\nBranch policy is equally strict. Story work happens on release branches (release/vX.Y). The agent can\u0026rsquo;t commit story work to main. Vault changes and certain administrative commits can go to main, but implementation code can\u0026rsquo;t.\nThe pre-commit hook check-methodology.py enforces all of this. It runs on every commit in every product repo, because all product repos point their core.hooksPath to UPDSS\u0026rsquo;s hooks directory. One set of rules, six products.\nThe _OutBox/_InBox Pattern Agents don\u0026rsquo;t talk to each other directly. They communicate asynchronously through file-based handoffs.\nWhen an agent needs to report something (a completed task, a discovered bug, a gate review finding, a budget overrun), it writes a Markdown file to its vault\u0026rsquo;s _OutBox/ directory. The file includes YAML frontmatter:\nfrom: agent-signin-v0.2 to: orchestrator re: Cross-repo contamination in readiness check status: needs-attention date: 2026-04-15 The orchestrator reads _OutBox/ files across all product vaults, routes instructions, and writes responses to the relevant _InBox/ directory.\nWhy files instead of direct messages? Because long messages sent via tmux send-keys trigger Claude Code\u0026rsquo;s paste-mode trap, which gets stuck on \u0026ldquo;Pasting text\u0026hellip;\u0026rdquo; indefinitely. We discovered this the hard way. The _InBox/_OutBox pattern replaced direct message passing for anything longer than a short command.\nBut there\u0026rsquo;s a deeper reason too. File-based communication creates an audit trail. Every instruction, every report, every escalation is a file in Git with a timestamp and a commit hash. Conversations are ephemeral (and get compacted when context windows fill up). Files persist.\nWhat Happens on Failure Agents fail. Models hallucinate. API calls time out. Code doesn\u0026rsquo;t compile. UPDSS has explicit protocols for each failure mode.\nTransient vs. Fault Diagnosis When something goes wrong, the agent\u0026rsquo;s first job is classification. Is this transient (an API timeout, a flaky test, a network blip) or a fault (a logic error, a missing dependency, a scope misunderstanding)?\nTransient failures get retried (up to a limit). Faults get reported to _OutBox/ with diagnosis notes. The agent doesn\u0026rsquo;t keep trying the same broken approach hoping it\u0026rsquo;ll work on the fifth attempt.\nBudget Overrun Protocol If a story\u0026rsquo;s cost approaches its budget, the agent must escalate. Not continue working. Not cut corners. Escalate.\nThe escalation goes to _OutBox/ with the current spend, the estimated remaining cost, and a recommendation (increase budget, reduce scope, or abandon the story). The human decides. The agent waits.\nThis is Shape Up\u0026rsquo;s \u0026ldquo;fixed appetite, variable scope\u0026rdquo; principle made mechanical. The appetite is declared in dollars. The enforcement is a budget check. The escape valve is human judgment, not agent optimism.\nStuck Detection If an agent hasn\u0026rsquo;t made progress (no commits, no _OutBox/ reports) for an extended period, the orchestrator checks. Usually this means the agent is in a loop: trying the same fix repeatedly, waiting for a resource that isn\u0026rsquo;t available, or confused about its current task.\nThe fix is usually simple. Read the agent\u0026rsquo;s cursor.yaml to see what it thinks it\u0026rsquo;s doing. Check progress.md for the last session entry. Send a short message via tmux send-keys to reorient it. If needed, restart the session (the readiness check will re-establish context from the vault state).\nThe Compliance Rules Here\u0026rsquo;s the full set of constraints that shape every agent action in a UPDSS session. These aren\u0026rsquo;t guidelines. They\u0026rsquo;re enforced through hooks, readiness checks, and gate tool defaults.\nEvery commit must be traceable to a story, vault change, or issue Every story must have G1 approval before implementation begins Every release must pass G1, G2, and G3 before deployment Agents can\u0026rsquo;t approve gates (mechanical enforcement via null default + dashboard-only approval) Agents can\u0026rsquo;t deploy without human confirmation through G3 Budget overruns require escalation, not silent continuation Out-of-scope work gets reported, not performed Session state must be verified before work begins (readiness check) Communication uses _OutBox/_InBox, creating an audit trail Cursor state must match reality (triad consistency check at commit time) Methodology doc versions must match version pins (CI enforcement) Branch policy must be followed (story work on release branches only) Why This Matters Most organizations using AI agents for code generation treat the agent like a faster developer. Give it a prompt, get code back, review it, ship it. That works fine for isolated tasks.\nIt breaks completely at scale. When you have multiple agents, multiple products, concurrent releases, and real money flowing through API costs, you need governance that the agents can\u0026rsquo;t circumvent. Not governance they\u0026rsquo;re asked to follow. Governance that constrains their execution environment so violations are structurally impossible.\nThat\u0026rsquo;s what UPDSS provides from the agent\u0026rsquo;s perspective. Clear boundaries. Mechanical enforcement. An async communication channel that creates audit trails. And explicit protocols for every failure mode.\nThe vault is the agent\u0026rsquo;s memory (because the agent\u0026rsquo;s own context window is ephemeral). The hooks are the agent\u0026rsquo;s constraints (because the agent can\u0026rsquo;t be trained, only constrained). The gates are the human checkpoints (because some decisions should never be delegated to a model).\nFor the human\u0026rsquo;s perspective, read For Product Leaders. For the technical architecture, read How It Works.\n","permalink":"https://updss.org/for-agents/","summary":"What an AI agent sees when it boots into a UPDSS-governed session. The compliance rules, the hard constraints, and the communication patterns.","title":"For AI Agents"},{"content":"If you\u0026rsquo;re looking to connect a product to UPDSS, contribute to the platform, or just understand what\u0026rsquo;s under the hood, this is your starting point.\nThe Socket-and-Plug Architecture UPDSS governs multiple products through a single platform using an electrical metaphor. The socket is the interface UPDSS exposes. The plug is what your product provides to connect.\nThe Socket (UPDSS Side) Socket v1.4 defines a conformance checklist: 19 vault-side items, 5 code-side items, and 1 platform-registry item. Each item has four fields:\nid: the checklist identifier (e.g., VAULT-01, CODE-03, PLAT-01) description: what the item requires verify: a command you can run to check conformance example: what a passing result looks like You can audit a product\u0026rsquo;s full conformance in a single bash block by running every verify command. Pass or fail. No interpretation needed.\nThe Plug (Product Side) Your product declares its plug in the vault\u0026rsquo;s product.yaml:\nplug: socket_version: \u0026#34;v1.4\u0026#34; separation_mode: \u0026#34;separated\u0026#34; product_id: \u0026#34;your-product\u0026#34; vault_repo: \u0026#34;yourorg/vault-your-product\u0026#34; code_repo: \u0026#34;yourorg/your-product\u0026#34; The separation_mode: separated field is mandatory as of Socket v1.4. Your governance state (vault) and your implementation (code) must live in different repositories.\nConnecting a Product The onboarding process, step by step:\nCreate a vault repository with the required directory structure (stories/, releases/, epics/, features/, _OutBox/, _InBox/, templates/) Add product.yaml with the plug declaration In your code repository, create .updss/vault-pointer.yaml pointing to the vault repo Create .updss/code-contract.yaml declaring the UPDSS tools location Set core.hooksPath to point to UPDSS\u0026rsquo;s hooks directory Run the conformance checklist Each onboarding took about an hour when I connected four products to Socket v1.4. Most of that time was creating the directory structure and populating the initial YAML files.\nThe Conformance Checklist Here\u0026rsquo;s what the checklist covers (abbreviated). The full checklist is in the UPDSS methodology docs.\nVault Items (VAULT-01 through VAULT-19) The vault-side checks verify your governance structure is correct:\nVAULT-01: product.yaml exists with required fields (name, plug section, identity) VAULT-02 through VAULT-05: Directory structure (stories/, releases/, epics/, features/) exists VAULT-06 through VAULT-08: Story files follow the triad pattern (story.yaml + cursor.yaml + progress.md) VAULT-09 through VAULT-12: Release files include scope, gate files (G1/G2/G3), and cursor VAULT-13: Templates directory with required templates VAULT-14 through VAULT-15: _OutBox/ and _InBox/ directories exist VAULT-16 through VAULT-17: ADRs and learnings directories present VAULT-18 through VAULT-19: Research directory with four-stage lifecycle (01-ideas, 02-researched, 03-absorbed, 04-deprioritised) Code Items (CODE-01 through CODE-05) The code-side checks verify your product repo integrates correctly:\nCODE-01: .updss/vault-pointer.yaml exists and points to a valid vault CODE-02: .updss/code-contract.yaml declares UPDSS tools location CODE-03: core.hooksPath set to UPDSS hooks directory CODE-04: Pre-commit hooks execute successfully on a test commit CODE-05: Methodology doc version pins match the installed UPDSS version Platform Registry (PLAT-01) PLAT-01: Product is registered in UPDSS\u0026rsquo;s platform product registry The Enforcement Engine Three layers of mechanical enforcement. If you\u0026rsquo;re integrating a product, you\u0026rsquo;ll interact with all three.\nPre-Commit Hooks check-methodology.py runs on every git commit in your product repo (via the cross-repo core.hooksPath). It checks:\nCommit message format: Must match [STORY-NNN-YY-ZZ][T-N], [VAULT], [FIX], [CURSOR], or [GATE] prefix Branch policy: Story work only on release branches, not on main Version pins: Methodology doc versions must match declared pins Story ID validation: The referenced story must exist in the vault Triad consistency: release-scope.yaml, cursor.yaml, and G1.yaml must agree on the story set for the current release If any check fails, the commit is rejected. The error message tells you exactly what\u0026rsquo;s wrong and how to fix it.\nGate Tools draft-gate.py auto-generates gate files (G1, G2, G3) with appropriate checklists and evidence sections. The decision field defaults to ~ (YAML null). This is the mechanical enforcement of human-only gate approval. No amount of YAML editing by an agent can approve a gate, because the pre-commit hooks will reject it.\nCI Workflows Two GitHub Actions workflows supplement the local hooks:\nmethodology-pin-sync.yml validates version-pin consistency on pull requests. If you bump a methodology doc but don\u0026rsquo;t update the version pin (or vice versa), the PR check fails. bookkeeper-status-bump.yml auto-bumps story statuses when PRs merge. This replaced a procedural rule that agents consistently forgot. Vault Structure Here\u0026rsquo;s what a well-formed vault looks like:\nvault-your-product/ product.yaml # identity, plug declaration epics/ EPIC-001/ epic.yaml features/ FEAT-001-01/ feature.yaml stories/ STORY-001-01-01/ story.yaml # the contract (stable after G1) cursor.yaml # the state machine (mutates constantly) progress.md # the audit trail (append-only) releases/ v0.1/ release-scope.yaml # stories, budget, appetite release-cursor.yaml # current phase, cost tracking G1.yaml # scope review gate G2.yaml # implementation review gate G3.yaml # release review gate research/ 01-ideas/ 02-researched/ 03-absorbed/ 04-deprioritised/ templates/ ADRs/ learnings/ _OutBox/ _InBox/ The story triad deserves special attention. story.yaml is the contract: scope, budget, out-of-scope, acceptance criteria. It\u0026rsquo;s stable after G1 approval. cursor.yaml is the state machine: current phase, current task, cost tracking, hill position. It mutates constantly during implementation. progress.md is the audit trail: append-only, one section per session, never rewritten.\nThis three-file split enables idempotency checking. If cursor.last_commit doesn\u0026rsquo;t match git HEAD, the session crashed between code and cursor update, and the current task can be safely re-run.\nExtending UPDSS UPDSS is designed to be extended at specific points.\nNew conformance items. The socket checklist is versioned. Adding VAULT-20 or CODE-06 means bumping the socket version, updating all product plugs, and running conformance audits.\nNew enforcement hooks. Pre-commit hooks are Python scripts. Adding a new check means adding a function to check-methodology.py and registering it in the check sequence.\nNew gate checklists. Gate templates define what each gate reviews. Adding a new checklist item to G2 (say, \u0026ldquo;security scan evidence\u0026rdquo;) means updating the template and bumping the methodology version.\nNew product types. The socket is product-agnostic. Whether you\u0026rsquo;re governing a web app, a CLI tool, a mobile app, or a data pipeline, the vault structure and gate process are the same. The code-side integration (hooks, vault pointer) works with any Git-based project.\nThe UPDSS methodology document (UPDSS-Core.md, currently at v4.2.0) has been through seven major versions. Each version was driven by real failures in the previous one: agents forgetting procedural rules, cross-repo contamination bugs, triad drift between files. The methodology evolves through operational experience, not committee design.\nFor the governance perspective, read For Product Leaders. For the full architecture article, read Governance-as-Code.\n","permalink":"https://updss.org/for-developers/","summary":"What a contributor or integrator sees when working with UPDSS: architecture, conformance, hooks, vault structure, and extension points.","title":"For Developers"},{"content":"You don\u0026rsquo;t write code. But you make the decisions that determine whether AI-written code should ship. UPDSS was designed for exactly that split: agents do the building, humans do the governing.\nHere\u0026rsquo;s what governing AI-agent-driven development actually looks like.\nStories: The Unit of Work Every piece of work in UPDSS starts as a story. A story isn\u0026rsquo;t a Jira ticket with a title and an assignee. It\u0026rsquo;s a structured contract with specific fields that matter for governance.\nScope defines exactly what the agent will build. Not vaguely (\u0026ldquo;improve the dashboard\u0026rdquo;) but precisely (\u0026ldquo;add cost forecasting to the release detail panel, using JSONL session logs as the data source\u0026rdquo;).\nOut-of-scope is equally important. It tells the agent what NOT to touch. Without this, an agent tasked with fixing a button will quietly refactor the entire component tree. I\u0026rsquo;ve seen it happen. More than once.\nBudget is a dollar amount. Not story points, not t-shirt sizes. Actual dollars. A typical story costs $3 to $15 in API costs. The agent knows its budget before it writes a single line of code.\nAppetite comes from Shape Up methodology. It answers the question: how much time and money is this problem worth? A $5 story that\u0026rsquo;s burning $12 at 70% completion triggers an escalation. The agent stops and asks. It doesn\u0026rsquo;t silently continue.\nThe Three Gates Nothing ships without passing three human-approved gates. This is the Stage-Gate spine of UPDSS.\nG1: Scope Review Before any agent writes code, a human reviews the scope. The questions at G1:\nIs this the right work to do right now? Is the scope tight enough that an agent can execute without ambiguity? Is the budget realistic for what\u0026rsquo;s being asked? Are the out-of-scope boundaries clear? G1 approval means \u0026ldquo;yes, build this.\u0026rdquo; G1 rejection means \u0026ldquo;rewrite the scope\u0026rdquo; (and the agent does, with specific feedback from the rejection notes).\nG2: Implementation Review After the agent finishes building, before the code merges to main. The questions at G2:\nDo the tests pass? Does the implementation match the scope? Is the code traceable? (Every commit linked to a story ID.) Is documentation updated? G2 is where you catch scope creep, untested edge cases, and the occasional agent that decided to \u0026ldquo;improve\u0026rdquo; something outside its mandate.\nG3: Release Review Before deployment to production. The questions at G3:\nIs CI green? Are release notes complete? Is there a rollback plan? Does the deployment evidence confirm it\u0026rsquo;s actually running? G3 approval means \u0026ldquo;ship it.\u0026rdquo; And here\u0026rsquo;s the critical constraint: agents can\u0026rsquo;t approve any gate. The gate file\u0026rsquo;s decision field defaults to null. Only a human, through the dashboard, can change it to approved. The system doesn\u0026rsquo;t just suggest this rule. It enforces it mechanically. An agent literally can\u0026rsquo;t write decision: approved to the file, because the pre-commit hooks will reject the commit.\nThe Release Lifecycle A release in UPDSS follows a clear path:\nPlanned. Stories are drafted, budgets estimated, scope defined. The release declares its appetite: \u0026ldquo;This is worth 3 to 4 days of agent work and $30 in API costs.\u0026rdquo;\nG1 Approved. Human reviews and approves the scope. Agents can begin.\nIn Progress. Agents pull stories and build. Each agent works on one story at a time, reports progress to _OutBox/, and tracks its cost in real time.\nDone (Dev). All stories complete. Code is ready for implementation review.\nDone. G2 approved. Ready for release review.\nReleased. G3 approved. Deployed to production with evidence.\nThe whole thing uses Kanban flow. No sprints. No two-week boundaries. Work gets pulled when capacity exists. A release that was planned for a week can land in two days if agent throughput is high. v0.9 shipped 23 stories for $254. Shape Up would call that a cycle-budgeting error. We call it Tuesday.\nThe Cost Model This is where UPDSS changes the conversation for product leaders.\nEvery story has a cost_budget_usd. Every release has a budget_usd. Every agent session writes its actual cost (tokens multiplied by model price) to the progress log. The dashboard shows budget burn in real time, with per-story breakdowns and forecasts.\nHere\u0026rsquo;s a real example. Release v0.11.8 was budgeted at $30. Final cost: $29.50. That\u0026rsquo;s not estimation. That\u0026rsquo;s measurement.\nThe unit is dollars, not story points. Dollars are fungible across models (switching from Opus to Sonnet changes the cost per token, and the system tracks it). Dollars are comparable across releases. And dollars are something every product leader already understands.\nWhen you\u0026rsquo;re reviewing a proposed release, you can ask: \u0026ldquo;Is this feature worth $30 in AI costs plus two days of my review time?\u0026rdquo; That\u0026rsquo;s a concrete question with a concrete answer. Try asking that with story points.\nThe Dashboard The UPDSS dashboard is your primary interface for governance. It shows:\nAll active releases across all products, with their current phase Budget vs. actual cost per release and per story Gate status (which gates are pending your review) Story flow (what\u0026rsquo;s planned, what\u0026rsquo;s in progress, what\u0026rsquo;s done) Cost forecasts based on burn rate Decision history (every gate approval, rejection, and the notes attached) You don\u0026rsquo;t need to understand Git, YAML, or terminal commands to use it. The dashboard translates the vault\u0026rsquo;s machine-readable state into human-readable governance decisions.\nWhen to Trust Agents, When to Intervene After 50+ releases, here\u0026rsquo;s the practical framework I use.\nTrust agents with: implementation within a well-scoped story, test writing, documentation updates, progress reporting, cost tracking, preparing gate review materials.\nIntervene for: scope decisions (what to build next), gate approvals (always human), budget overruns (agents escalate, you decide whether to continue or cut scope), architectural choices that affect multiple products, and anything where the agent says \u0026ldquo;I\u0026rsquo;m not sure.\u0026rdquo;\nWatch for: stories that keep expanding in scope (the agent finds \u0026ldquo;one more thing\u0026rdquo; to fix), cost burn that\u0026rsquo;s tracking ahead of progress, and agents that stop communicating through _OutBox/ (usually means they\u0026rsquo;re stuck in a loop).\nThe pattern is straightforward. Agents are excellent executors within clear boundaries. They\u0026rsquo;re poor judges of whether the boundaries are right. That judgment is your job. UPDSS gives you the structure and the data to make those judgments well.\nWhat This Means for Your Organization If you\u0026rsquo;re running AI agents on production code today, you already have a governance problem. You might not have noticed it yet because the volume is still low or because a senior engineer is manually reviewing everything. But as you scale to more agents, more products, and more concurrent work, the manual approach breaks.\nUPDSS is one answer to that problem. Built from real operational experience (not theory), validated across six products and 50+ releases, costing roughly $500 total to prove out.\nThe model choice is secondary. The vyavastha around the model is primary. The system, the structure, the governance. That\u0026rsquo;s what UPDSS provides.\nWant to see the technical architecture? Read How It Works. Want to see the agent\u0026rsquo;s perspective? Read For AI Agents.\n","permalink":"https://updss.org/for-product-leaders/","summary":"What a CXO or VP Engineering sees when governing AI-driven development with UPDSS.","title":"For Product Leaders"},{"content":"UPDSS is built on one principle: governance state and code must live in separate places. Everything else follows from that.\nThree layers make the system work. Each one solves a specific problem.\nLayer 1: The Vault The vault is a Git repository that holds governance state. Only YAML and Markdown. Never code.\nStories live here (with their scope, budget, and progress tracking). Releases live here (with their gate files and cost data). EPICs, features, research documents, architecture decisions, templates: all in the vault. And critically, the _OutBox/ and _InBox/ directories that agents use to communicate asynchronously with the orchestrator.\ngraph TB V[\u0026#34;Vault Repository\u0026#34;] --\u0026gt; ST[\u0026#34;Stories\u0026lt;br/\u0026gt;story.yaml + cursor.yaml + progress.md\u0026#34;] V --\u0026gt; REL[\u0026#34;Releases\u0026lt;br/\u0026gt;release-scope.yaml + gate files\u0026#34;] V --\u0026gt; EP[\u0026#34;EPICs + Features\u0026#34;] V --\u0026gt; RES[\u0026#34;Research + ADRs + Templates\u0026#34;] V --\u0026gt; OB[\u0026#34;_OutBox / _InBox\u0026lt;br/\u0026gt;async agent communication\u0026#34;] style V fill:#1a1a2e,stroke:#e94560,color:#eee style ST fill:#16213e,stroke:#0f3460,color:#eee style REL fill:#16213e,stroke:#0f3460,color:#eee style EP fill:#16213e,stroke:#0f3460,color:#eee style RES fill:#16213e,stroke:#0f3460,color:#eee style OB fill:#16213e,stroke:#0f3460,color:#eee Why separate the vault from code? Because if an agent can modify governance artifacts in the same repository where it writes code, you don\u0026rsquo;t have governance. You have suggestions. The filesystem itself becomes the enforcement boundary. An agent implementing a feature literally can\u0026rsquo;t approve its own gate because the gate file is in a different repository.\nEvery change in the vault has a Git commit hash, an author, and a timestamp. Full audit trail. No database dependency. Human-readable, machine-parseable.\nLayer 2: Socket-and-Plug This is how UPDSS governs multiple products through a single platform. The metaphor is electrical.\nThe socket is UPDSS\u0026rsquo;s interface: a conformance checklist that defines what any product must provide to connect. Currently at Socket v1.4, it specifies 19 vault-side items (VAULT-01 through VAULT-19), 5 code-side items (CODE-01 through CODE-05), and 1 platform-registry item (PLAT-01). Each checklist item has an ID, a description, a verify command, and an example.\nThe plug is the product\u0026rsquo;s integration: a plug: section in the product\u0026rsquo;s vault product.yaml declaring its identity, target socket version, and separation mode.\ngraph LR S[\u0026#34;UPDSS Socket v1.4\u0026lt;br/\u0026gt;VAULT-01..19\u0026lt;br/\u0026gt;CODE-01..05\u0026lt;br/\u0026gt;PLAT-01\u0026#34;] P1[\u0026#34;UPDSS\u0026#34;] --\u0026gt; S P2[\u0026#34;Omysha SignIn\u0026#34;] --\u0026gt; S P3[\u0026#34;Omysha SSP\u0026#34;] --\u0026gt; S P4[\u0026#34;Algo PropTrading\u0026#34;] --\u0026gt; S P5[\u0026#34;Marketing Tools\u0026#34;] --\u0026gt; S style S fill:#0f3460,stroke:#e94560,color:#eee style P1 fill:#1a1a2e,stroke:#533483,color:#eee style P2 fill:#1a1a2e,stroke:#533483,color:#eee style P3 fill:#1a1a2e,stroke:#533483,color:#eee style P4 fill:#1a1a2e,stroke:#533483,color:#eee style P5 fill:#1a1a2e,stroke:#533483,color:#eee Want to connect a new product? Create a vault repo with the required directory structure, add a product.yaml with the plug declaration, point your code repo\u0026rsquo;s core.hooksPath to UPDSS\u0026rsquo;s hooks, and run the conformance checklist. Each onboarding took about an hour when I connected four products to Socket v1.4.\nSocket versions evolve. v1.0 started with basic structure. v1.4 introduced mandatory vault-code separation, the _InBox/_OutBox pattern for async agent communication, and a required UPDSS tools declaration so enforcement hooks can locate check-methodology.py at commit time.\nLayer 3: The Enforcement Engine This is where the thesis lives. Mechanical enforcement works. Procedural enforcement fails. Every procedural rule we wrote (\u0026ldquo;remember to update the cursor after implementation\u0026rdquo;) was forgotten by agents within one or two releases. Every mechanical check we added held.\ngraph BT PC[\u0026#34;Pre-Commit Hooks\u0026lt;br/\u0026gt;check-methodology.py\u0026#34;] --\u0026gt; GT[\u0026#34;Gate Tools\u0026lt;br/\u0026gt;draft-gate.py\u0026#34;] GT --\u0026gt; RC[\u0026#34;Readiness Check\u0026lt;br/\u0026gt;+ Dashboard Validation\u0026#34;] PC --\u0026gt; CI[\u0026#34;CI Workflows\u0026lt;br/\u0026gt;pin-sync + bookkeeper\u0026#34;] style PC fill:#16213e,stroke:#e94560,color:#eee style GT fill:#1a1a2e,stroke:#e94560,color:#eee style RC fill:#0f3460,stroke:#e94560,color:#eee style CI fill:#0f3460,stroke:#e94560,color:#eee The enforcement stack, layer by layer:\nPre-commit hooks run on every git commit in any product repo. They validate commit message format ([STORY-NNN-YY-ZZ][T-N]), check branch policy, verify methodology doc versions, detect story ID collisions, and run triad consistency checks ensuring release-scope.yaml, cursor.yaml, and G1.yaml agree on the story set. One set of hooks governs all six products through cross-repo hook paths.\nGate tools auto-generate G1/G2/G3 gate files with checklists and test evidence. The decision field defaults to null (decision: ~). Agents physically can\u0026rsquo;t approve a gate. Only the dashboard\u0026rsquo;s approve endpoint can write decision: approved, and only after a human clicks the button.\nReadiness checks run when an agent starts a session. Machine state (Python, Git, Docker), product state (hooks installed, vault pointer valid), and session state (active release, story assignment) all get verified before any work begins.\nCI workflows catch what hooks can\u0026rsquo;t. methodology-pin-sync.yml validates version-pin consistency on pull requests. bookkeeper-status-bump.yml auto-bumps story statuses when PRs merge. These replaced two procedural rules that agents forgot on every release.\nDashboard validation enforces that all gate checklist items are present before approval. G3 requires status: released with deployment confirmation.\nThe Result Five independent agents audited this enforcement stack (research R-093). Their finding: every item on the \u0026ldquo;what works\u0026rdquo; list is mechanical or structural. Every item on the \u0026ldquo;what fails\u0026rdquo; list is procedural. When your enforcement targets are ephemeral agents with no persistent memory, you can\u0026rsquo;t train them. You can only constrain them.\nKali mitti, as we say. Black soil that holds its shape. Build the walls from that, not from promises.\nFor the full technical walkthrough, read Governance-as-Code: How UPDSS Governs AI Agents Building Production Software.\n","permalink":"https://updss.org/how-it-works/","summary":"The three-layer architecture of UPDSS: Vault, Socket-and-Plug, and the Enforcement Engine.","title":"How It Works"},{"content":"The UPDSS Methodology UPDSS borrows its spine from three proven methodologies. Each contributes a specific structural element. None was adopted wholesale. The combination was driven by eight weeks of real operation, not by theory.\nStage-Gate (Cooper) Three gates, each requiring human approval:\nG1, Scope Review: Is this the right work, scoped correctly, with a realistic budget? G2, Implementation Review: Is the code sound, tested, and traceable? G3, Release Review: Is the release complete, with evidence, deployment verified? Nothing ships without all three gates approved. Agents prepare findings and present them. Only humans approve. Gates can also reject outright, with decision: rejected and rework notes as a first-class state.\nKanban (Flow-Based) Stories flow through phases: planned, g1_approved, in_progress, done_dev, done, released. No sprints. No velocity targets. Work is pulled when capacity allows, not pushed on a schedule.\nShape Up (Basecamp) Fixed appetite, variable scope. Every release has a budget_usd and an appetite declaration. If the budget is exceeded, the agent must escalate, not silently continue. The scope adjusts to fit the appetite. UPDSS borrowed Shape Up\u0026rsquo;s vocabulary (appetite, betting table, hill charts) without its fixed six-week cycle.\nThe Release Lifecycle A release moves through a defined sequence, with gate checkpoints where human decisions are required.\ngraph LR P[\u0026#34;planned\u0026#34;] --\u0026gt;|\u0026#34;G1\u0026#34;| G1A[\u0026#34;g1_approved\u0026#34;] G1A --\u0026gt; IP[\u0026#34;in_progress\u0026#34;] IP --\u0026gt; DD[\u0026#34;done_dev\u0026#34;] DD --\u0026gt;|\u0026#34;G2\u0026#34;| D[\u0026#34;done\u0026#34;] D --\u0026gt;|\u0026#34;G3\u0026#34;| R[\u0026#34;released\u0026#34;] style P fill:#533483,stroke:#e94560,color:#eee style G1A fill:#0f3460,stroke:#e94560,color:#eee style IP fill:#16213e,stroke:#e94560,color:#eee style DD fill:#16213e,stroke:#e94560,color:#eee style D fill:#0f3460,stroke:#e94560,color:#eee style R fill:#1a1a2e,stroke:#e94560,color:#eee At G1, the human approves the scope and budget. At G2, the human reviews the implementation and test evidence. At G3, the human confirms the release is deployment-ready with rollback plans.\nA release planned for a week can land in two days if agent throughput is high. v0.9 shipped 23 stories for $254. The release cycle is the unit of cadence, not a fixed time boundary.\n4-Level Versioning UPDSS uses semantic versioning with four levels: a.x.y.z\nVersion (a): Fundamental platform change. Rare. Major (a.x): Significant capability milestone. New EPICs, architectural shifts. Minor (a.x.y): Planned features with stories and gates. The standard release unit. Micro (a.x.y.z): Small planned releases with 2 to 3 stories. Rapid patches. In practice, most work happens at the minor and micro levels. The eight-week run went from v0.1 through v0.11.9, including four rapid micro-releases (v0.9.1.1 through v0.9.1.4) that each fixed a single bug in under 30 minutes.\nThe Cost Model Every story has a cost_budget_usd. Every release has a budget_usd. Every session writes its actual cost and model to the progress log. The dashboard shows cost forecasts and budget burn in real time.\nThe unit is tokens multiplied by model price. Measurable without self-report, fungible across models (Sonnet costs less per token than Opus, and the system accounts for it), and pre-committed before work begins.\nv0.11.8 budgeted $30, spent $29.50. v0.11 budgeted $252, spent $252. That accuracy comes from two things: agents being transparent about their token usage, and JSONL session logs that verify it independently. The methodology enforces honest reporting. The logs make honest reporting auditable.\nWhen a story\u0026rsquo;s cost approaches its budget, the agent escalates. The human decides whether to increase the budget, reduce the scope, or stop. Agents don\u0026rsquo;t silently continue past their budget. They can\u0026rsquo;t (mechanically). This is the vyavastha of cost control: structure that holds because it\u0026rsquo;s built into the system, not because someone remembers to check.\nOne Deliberate Non-Adoption UPDSS doesn\u0026rsquo;t use sprints. A 1,003-line analysis (research R-088) mapped UPDSS against every major methodology and documented the rejection of sprints permanently. The reasoning: adding a time-boxed sprint layer inside a release would double the ceremony cost (two planning meetings, two retrospectives, two burn-down charts) without reducing risk. For a single-operator methodology with cost-bounded agent work, the release cycle is the right granularity.\nFor the full architectural walkthrough, read Governance-as-Code: How UPDSS Governs AI Agents Building Production Software. For a practical view of governance decisions, read For Product Leaders.\n","permalink":"https://updss.org/methodology/","summary":"UPDSS combines Stage-Gate, Kanban, and Shape Up into a governance methodology designed for AI-agent-driven development.","title":"Methodology"},{"content":"Everything on this site was built by one person directing AI agents for roughly $500 in API costs.\nThat number is real. 50+ releases, 6 products governed, 9 AI agents coordinated through a terminal multiplexer. The methodology works. The architecture works. The enforcement thesis (mechanical constraints beat procedural rules for AI agents) is empirically validated.\nWhat the project needs now is a team.\nWhat Your Support Funds Specific line items, because transparency matters:\nOpen-sourcing the platform. Cleaning, documenting, and packaging the UPDSS codebase, vault structure, and methodology for public use. The code exists and runs. Making it usable by others is a different kind of work.\nDocumentation. Guides for teams adopting AI-agent-driven development with UPDSS governance. Not auto-generated docs. Real walkthroughs written from operational experience.\nTooling hardening. The dashboard, the enforcement engine, the schema validator, the cost tracker, the readiness check, the gate tools. All of them work in our environment. Making them work in yours requires testing, edge case handling, and configuration flexibility.\nResearch. Continuing the R-series research that drives methodology improvements. R-088 (the 1,003-line methodology alignment analysis) and R-093 (the multi-agent enforcement audit) shaped the current version. There\u0026rsquo;s more to learn.\nTeam. Moving from a single operator to a small team that can maintain, extend, and support the platform.\nHow to Contribute GitHub Sponsors: Recurring monthly support, directly through GitHub. Sponsor updss-project on GitHub\nOpen Collective: Transparent funding where every contribution and expense is public. UPDSS on Open Collective\nContribute code: If you\u0026rsquo;re an engineer interested in AI governance, the codebase is at github.com/updss-project. The conformance checklist (VAULT-01 through VAULT-19, CODE-01 through CODE-05) is a good place to start understanding the system.\nThe Thesis The model choice is secondary. The vyavastha around the model is primary. The structure, the constraints, the governance. UPDSS is that vyavastha. Your support helps make it available to every team building with AI agents.\nUPDSS is developed by A4G Impact Collaborative. Nitin Dhawan (Muralidhar) is the architect and primary author.\n","permalink":"https://updss.org/support/","summary":"UPDSS is open source. Your support funds the team building governance infrastructure for the AI era.","title":"Support UPDSS"}]