Research / Engineering Capacity OS
Engineering Capacity Operating System Research
A location-agnostic research model for structuring, governing, measuring, and improving distributed engineering capacity across teams, partners, platforms, and AI agents.
Modern engineering capacity is distributed across people, teams, vendors, geographies, platforms, and AI agents. Engineering Capacity OS is a research model for deciding how that capacity should be structured, governed, measured, and improved without exposing private engineering data.
What This Page Does
This is the front door for the Engineering Capacity Operating System research model. It explains the thesis, the system function, the operating layers, the evidence boundary, and the output a leader should expect.
It is not a staffing page, vendor recommendation, location thesis, or sales funnel. It is a decision intelligence model for engineering organizations.
System Model
System function: P(t)=f(C,T,K,D,O,A,L,G)
Outputs: speed, quality, cost, risk, value.
Engineering performance is a function of usable capacity, capacity topology, explicit knowledge, execution determinism, trusted telemetry, agentic action, adaptive learning, and governance. The output is not only speed. It includes quality, cost, risk, and business value.
- C
- Capacity intelligence
- T
- Distributed capacity topology
- K
- Knowledge and architecture memory
- D
- Execution determinism
- O
- Observability and telemetry
- A
- Agentic action
- L
- Learning and adaptive control loops
- G
- Governance
Operating Layers
1. Capacity Intelligence C
How much usable engineering capacity exists after load, constraints, and fit are accounted for?
2. Distributed Capacity Topology T
Which capacity topology best fits the work, risk, knowledge, governance, and performance requirements of the engineering system?
3. Knowledge and Architecture Memory K
Does the engineering system have enough explicit knowledge for distributed contributors and AI agents to make safe, high-quality decisions?
4. Execution Harness / SDLC Control Plane D
How consistently does the SDLC produce reproducible outcomes across teams, services, locations, partners, and agentic workflows?
5. Decision-Grade Engineering Telemetry O
Which engineering signals are trusted enough to govern the system?
6. Governed Agentic SDLC A
Which engineering workflows can agents safely execute today, and under what human, technical, and governance constraints?
7. Governed Adaptive Control Loops L
Can the engineering system improve its own execution behavior based on evidence without creating uncontrolled automation risk?
Cross Cutting Constraints
- Governance, Security, Audit, and Rollback: Authority, approval, access control, policy, auditability, rollback, human override, partner access boundaries, agent tool permissions, security constraints, IP protection, decision records, exception handling, and stop conditions.
- Failure Mode Register: Hidden queues, review bottlenecks, architecture decision latency, pipeline drift, documentation drift, context loss, agent-generated rework, incentive mismatch, time-zone delay, security access overreach, recursive automation loops, conflicting optimization goals, telemetry blind spots, governance lag, and local optimization harming global performance.
- Cost, Value, and Risk Economics: Evaluation of tradeoffs across cost, quality, risk, speed, and business value instead of treating speed as the only performance dimension.
Output Promise
Input: select one operating problem. Evidence: use aggregate MCP evidence or a redacted evidence pack. Analysis: map evidence to capacity, topology, knowledge, execution, telemetry, agentic workflows, adaptive loops, and governance. Output: answer cards, bottleneck findings, missing telemetry, risk flags, confidence labels, and one next safe action.
Publication Layer
The working paper is now part of the Engineering Doctrine route system. The hub explains the operating model, the question engine runs diagnostics, and the paper gives the research argument a citable publication surface.
Seven Starting Questions
The full question engine contains 60 questions. This page only exposes the starting set for human orientation.
capacity_intelligence
How much usable engineering capacity exists after cognitive load, review load, interruptions, and role fit are accounted for?
Headcount does not represent usable capacity when the system loses time to queues, incidents, meetings, or poor work fit.
Validation signal: Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window.
distributed_capacity_topology
Which engineering workstreams are safest to distribute beyond the current core team?
Not all work has the same knowledge, security, coordination, or ownership requirements.
Validation signal: Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability.
knowledge_architecture_memory
Which parts of the engineering system depend on tribal knowledge?
Tribal knowledge limits distributed execution and safe AI assistance.
Validation signal: Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals.
execution_harness
How standardized are CI/CD pipelines across teams, services, and contributor types?
Distributed and AI-assisted capacity requires reproducible execution, not local delivery customs.
Validation signal: Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency.
decision_grade_telemetry
Which engineering signals are trusted enough to govern capacity topology decisions?
Topology decisions require evidence that explains delivery behavior, not dashboard activity.
Validation signal: Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history.
governed_agentic_sdlc
Which agentic workflows reduce onboarding time for distributed contributors?
AI can improve capacity only if it reduces context acquisition cost without increasing rework.
Validation signal: Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency.
governed_adaptive_control_loops
Can the engineering system recommend workflow changes from telemetry without automatically applying them?
Adaptive control should begin with governed recommendations before self-modifying execution.
Validation signal: Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement.
How To Use These Artifacts
These files let a CTO, CIO, VP Engineering, or internal AI system use the research without moving private engineering data outside the organization. The public artifacts define the model, the question engine, the answer-card format, and the report contract. Private evidence stays inside the leader-owned system.
Benefit
A leader can turn an unclear engineering capacity problem into a structured diagnostic packet: bottleneck, evidence, missing telemetry, confidence level, risk boundary, and next safe action.
- Read the model: use Research Markdown or Research JSON to understand the Engineering Capacity Operating System.
- Run the questions internally: use Questions JSON or Questions Markdown inside an internal MCP, data workspace, or redacted evidence packet.
- Produce evidence-bound outputs: use Answer Card Schema and Workflow Report System to generate diagnostic reports with confidence, gaps, and next safe action.
Sample Internal MCP Instruction
Use the Engineering Capacity OS question bank. Focus on execution_harness and decision_grade_telemetry. Retrieve only aggregate delivery, review, incident, and deployment signals. Do not expose source code, secrets, customer records, or employee-level performance data. Return answer cards with: observed evidence, missing evidence, confidence, risk, and next safe action.
If There Is No MCP Server
Export a redacted evidence pack: counts, distributions, time windows, queue age, cycle time, deployment frequency, incident summaries, review aging, and sanitized examples. Then run the same question packet inside an approved internal LLM workspace.
Artifact Roles
- Research JSON: Machine schema for the public model, operating layers, governance rules, and retrieval metadata.
- Research JSON v3: Current full research object used by the page, API corpus, and static export.
- Research Markdown: LLM-readable research brief for review, embedding, citation, and internal analysis.
- Questions JSON: Structured diagnostic question bank with doctrine answers, validation signals, and answer-card rules.
- Questions Markdown: Copy-safe question packet for CTOs to run inside their own MCP or approved LLM workspace.
- Formula Registry JSON: Crosswalk from doctrine formulas to question IDs, evidence signals, MCP source classes, answer-card fields, and reports.
- Formula Registry Markdown: LLM-readable formula crosswalk for internal MCP diagnostics and redacted evidence review.
- US CTO/CIO Learning Cards JSON: Machine-readable cards that map every question to formulas, safe MCP evidence requests, answer-card outputs, and report usage.
- US CTO/CIO Learning Cards Markdown: LLM-ready learning-card packet for CTO and CIO internal diagnostics without moving private engineering evidence.
- Answer Card Schema: Contract for turning private evidence into auditable answers without exposing private records.
- Answer Card Markdown: Human-readable answer-card rules for internal analysts, AI agents, and engineering leaders.
- Workflow Report JSON: Report schema for converting answer cards into CTO, CIO, VP Engineering, and governance outputs.
- Workflow Report Markdown: Report-writing guide for internal diagnostic packets and leadership review documents.
- Working Paper Page: Human publication route for Engineering Capacity as an Operating System.
- Working Paper PDF: Draft PDF for human review before arXiv or journal submission.
- Working Paper Markdown: Source manuscript for internal review, MCP ingestion, and citation checks.
- Science Corpus JSON: Source register for TeamStation science papers and Engineering Doctrine pages.
- AI Diagnostic Protocol: Operating procedure for an approved AI agent using private MCP evidence or redacted exports.
- OpenAPI JSON: Route contract so tools, crawlers, and internal systems can discover the research API surface.
- Cloudflare AI Corpus: Static retrieval corpus for AI crawlers, MCP discovery, and Cloudflare-hosted indexing.
Formula To Question Map
The doctrine formulas are mapped to research question IDs, internal evidence classes, answer-card fields, and workflow report sections. This lets a CTO or CIO run the same model inside an organization-controlled MCP server or redacted evidence pack without exposing private engineering records.
Formula Registry JSON and Formula Registry Markdown are the canonical machine-readable exports.
Engineering Performance Function
Formula: P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}
Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.
Diagnostic use: Use this as the top-level dependency map for every Engineering Capacity OS report.
Related questions: capacity-001, topology-003, knowledge-001, execution-001, telemetry-001, agent-001, adaptive-001, gov-006
Required signals: committed work, completed work, review queue age, cycle time, deployment success, incident interruption load, ownership map, approval path, rollback evidence
MCP source classes: work tracker, source control, pull request system, CI/CD system, incident system, architecture catalog, telemetry platform, policy system
Report sections: Executive Summary, System Function Map, Risk Boundary, Next Safe Action
Sequential Probability Network
Formula: P = product(p_i) for i=1..n
In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.
Diagnostic use: Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.
Related questions: capacity-002, capacity-005, topology-001, topology-006, knowledge-003, execution-010
Required signals: workstream sequence, handoff count, blocked work, dependency wait, review queue age, rework by upstream source, deployment dependency map
MCP source classes: work tracker, pull request system, architecture catalog, service registry, CI/CD system
Report sections: Capacity Constraint Map, Topology Readiness, Execution Failure Modes
Strict Complementarity
Formula: p_{k+2} - p_{k+1} > p_{k+1} - p_k
Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.
Diagnostic use: Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.
Related questions: capacity-004, capacity-007, topology-002, topology-005, knowledge-004, knowledge-008
Required signals: senior review dependency, architecture decision age, rework by reviewer, handoff failure, critical knowledge ownership
MCP source classes: pull request system, architecture decision records, work tracker, engineering review records
Report sections: Capacity Constraint Map, Knowledge and Ownership Risk
Shirking Margin
Formula: zeta_i^x = P(project succeeds | e_i=0, policy x)
Zeta measures how safe a contributor feels when they do not apply full effort. If the system hides weak effort behind downstream rescue, incentive quality degrades.
Diagnostic use: Use this to test whether AI, QA, senior rescue, or vendor buffering is hiding low-quality upstream work.
Related questions: capacity-006, agent-004, agent-005, agent-006, gov-001, gov-006
Required signals: review correction rate, reopened work, QA rescue count, senior rescue count, agent-generated rework, approval override history
MCP source classes: pull request system, test system, incident system, work tracker, agent audit logs
Report sections: Agentic Workflow Control Report, Governance and Risk Boundary
Incentive Compatibility Constraint
Formula: p_n * w_i - c >= zeta_i^x * w_i
A contributor exerts effort when the expected value of working is greater than the expected value of shirking.
Diagnostic use: Use this as a qualitative operating model for effort, friction, unclear ownership, time-zone delay, and downstream safety nets.
Related questions: capacity-003, topology-004, topology-009, gov-001, gov-006
Required signals: decision latency, blocked time, handoff delay, context switching, work ownership, review accountability
MCP source classes: work tracker, calendar metadata if approved and aggregated, pull request system, decision records
Report sections: Capacity Constraint Map, Topology Readiness
Wage Equation
Formula: w_i^x = c / (p_n - zeta_i^x)
As the incentive margin shrinks, the cost required to sustain high effort rises.
Diagnostic use: Use this to explain why cheap capacity can become expensive when coordination friction, review drag, and rescue work rise.
Related questions: capacity-008, topology-003, telemetry-002, telemetry-006
Required signals: cycle time, review drag, rework rate, defect escape, incident load, coordination delay, topology cost
MCP source classes: work tracker, pull request system, incident system, finance or planning summaries if approved
Report sections: Cost, Value, and Risk Economics, Topology Readiness
Replacement Kinetics Derivative
Formula: partial C / partial x_i = Direct Savings - Incentive Distortion
Replacing or automating a position creates direct savings only if it does not distort incentives and coordination around the rest of the chain.
Diagnostic use: Use this to decide whether AI should automate a workflow, augment it, or stay outside the approval path.
Related questions: agent-001, agent-002, agent-006, adaptive-002, gov-002, gov-006
Required signals: workflow step position, blast radius, human approval path, agent error rate, review correction rate, rollback evidence
MCP source classes: agent audit logs, pull request system, CI/CD system, policy system, incident system
Report sections: Agentic Workflow Control Report, Governed Adaptive Control Loop Report
Kingman Wait Time Approximation
Formula: E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau
As utilization approaches 100 percent, wait time explodes. Variance makes the queue worse.
Diagnostic use: Use this to test whether a team is actually capacity constrained or queue constrained.
Related questions: capacity-001, capacity-003, capacity-005, execution-010, telemetry-004, telemetry-006
Required signals: utilization proxy, active WIP, queue age, cycle time, arrival variability, service-time variability, blocked work
MCP source classes: work tracker, pull request system, CI/CD system, incident system
Report sections: Capacity Constraint Map, Telemetry Trust Report
Little's Law
Formula: L = lambda * W
Average work in progress equals throughput multiplied by time in system.
Diagnostic use: Use this to show why more active work can increase lead time even when people look busy.
Related questions: capacity-003, execution-008, telemetry-002, telemetry-004
Required signals: active WIP, throughput, lead time, cycle time, work item aging
MCP source classes: work tracker, pull request system
Report sections: Capacity Constraint Map, Execution Control Report
Rule of Two WIP Constraint
Formula: WIP_person <= 2
A contributor should not carry unlimited active work. Too much WIP hides blocked flow and destroys feedback.
Diagnostic use: Use this to identify false capacity created by multitasking and fragmented ownership.
Related questions: capacity-003, capacity-005, execution-003, execution-007
Required signals: active items per contributor, work state aging, blocked items, handoff count, review waiting time
MCP source classes: work tracker, pull request system
Report sections: Capacity Constraint Map, Execution Control Report
Cost of Delay
Formula: CoD = dV_lost / dt = -dV_remaining / dt
Cost of delay is the rate at which waiting destroys remaining value or accumulates lost value. The sign convention must be stated before comparing work.
Diagnostic use: Use this to prioritize work by time-sensitive value rather than loudness, politics, or activity volume.
Related questions: capacity-008, topology-003, telemetry-002, telemetry-008
Required signals: business milestone, work age, expected value, cycle time, blocked dependency, release date movement
MCP source classes: product roadmap, work tracker, release management, finance or planning summaries if approved
Report sections: Cost, Value, and Risk Economics, Executive Summary
Dependency Density
Formula: E_max = N(N-1)/2; D = E/E_max
A system with N nodes can contain at most N(N-1)/2 undirected pairwise dependencies. Actual dependency density is the observed edge count divided by that bound.
Diagnostic use: Use this to test whether team, service, or vendor topology is creating integration cost faster than delivery value.
Related questions: topology-003, topology-006, knowledge-003, knowledge-006, gov-006
Required signals: service count, team count, interface count, cross-service changes, owner map, dependency incidents
MCP source classes: service registry, architecture catalog, source control, incident system, work tracker
Report sections: Topology Readiness, Failure Mode Register
Synchronization Penalty
Formula: S_p = sum(T_wait + T_context_switch)
Distributed work pays a penalty whenever waiting time and context switching replace direct feedback.
Diagnostic use: Use this to measure whether time-zone overlap, unclear ownership, or missing self-serve context is slowing the SDLC.
Related questions: topology-004, topology-009, capacity-003, telemetry-003, telemetry-004
Required signals: wait time, handoff delay, blocked comments, review latency, time-zone overlap, context switch count
MCP source classes: work tracker, pull request system, calendar metadata if approved and aggregated, engineering chat summaries if approved and redacted
Report sections: Topology Readiness, Capacity Constraint Map
Availability and MTTR
Formula: A = MTBF / (MTBF + MTTR)
Availability improves when recovery time drops. Modern software systems should optimize fast recovery, not frozen change.
Diagnostic use: Use this to test whether engineering governance improves recovery or only slows delivery.
Related questions: execution-004, execution-005, telemetry-005, gov-002, gov-006
Required signals: deployment frequency, change failure rate, MTTR, rollback duration, incident detection time, incident diagnosis time
MCP source classes: CI/CD system, incident system, observability platform, change management
Report sections: Execution Control Report, Governance and Failure Mode Register
MTTR Limit Behavior
Formula: lim_{MTTR -> 0} MTBF / (MTBF + MTTR) = 1
As recovery time approaches zero, availability approaches one even when failures still happen.
Diagnostic use: Use this to evaluate rollback, feature flags, observability, and authority delegation.
Related questions: execution-003, execution-004, telemetry-003, telemetry-005, gov-002
Required signals: rollback path, feature flag coverage, incident time to mitigation, approval latency, audit record
MCP source classes: CI/CD system, feature flag system, incident system, policy system
Report sections: Execution Control Report, Governance and Risk Boundary
Mutation Score
Formula: MS = K / (T - E)
Test quality is measured by whether tests kill injected faults, not whether lines were merely executed.
Diagnostic use: Use this to test whether quality telemetry is meaningful enough to trust AI-generated or distributed engineering output.
Related questions: telemetry-005, agent-002, agent-004, execution-009
Required signals: test coverage, mutation score if available, failed tests, escaped defects, review correction rate, reverts
MCP source classes: test system, CI/CD system, pull request system, incident system
Report sections: Telemetry Trust Report, Agentic Workflow Control Report
Cognitive Fidelity
Formula: Quality ~ isomorphism(M_e, S_sys)
Quality depends on how closely an engineer's mental model matches the actual system state.
Diagnostic use: Use this to evaluate whether ownership, documentation, and review systems keep human and agent contributors aligned with reality.
Related questions: knowledge-001, knowledge-004, knowledge-006, agent-002, agent-006, telemetry-005
Required signals: architecture decision records, documentation usage, review comments, rework caused by misunderstanding, incident root cause, agent correction rate
MCP source classes: architecture catalog, documentation system, pull request system, incident system, agent audit logs
Report sections: Knowledge and Ownership Risk, Agentic Workflow Control Report
L2 Adjusted Communication Score
Formula: s_adj = s_raw - beta * (f_error - E[f | P])
Language form errors should not be allowed to erase correct technical reasoning.
Diagnostic use: Use this as a public doctrine mapping for fair evaluation of distributed contributors, not as a public scoring engine.
Related questions: capacity-007, topology-008, knowledge-008, gov-004
Required signals: evaluation rubric, technical reasoning evidence, communication context, review calibration, bias control record
MCP source classes: approved evaluation records, calibration records, governance policy
Report sections: Governance and Risk Boundary, Capacity Topology Readiness
Frechet Semantic Distance
Formula: FSD(y_q,b_q)=||mu_y-mu_b||_2^2 + Tr(Sigma_y + Sigma_b - 2(Sigma_y^(1/2) Sigma_b Sigma_y^(1/2))^(1/2))
Semantic similarity should be measured by meaning, not surface phrasing.
Diagnostic use: Use this as a public doctrine reference for semantic matching and technical reasoning fidelity.
Related questions: knowledge-005, knowledge-008, capacity-007, gov-004
Required signals: approved rubric, ideal answer blueprint, semantic content evidence, calibration record
MCP source classes: approved evaluation records, knowledge base, governance policy
Report sections: Knowledge and Ownership Risk, Governance and Risk Boundary
Optimal Transport With Code Switch Awareness
Formula: s_q^OT = psi(W_2(P_q,Q_q; C o (1 - lambda M)))
Code switching should not be treated as technical weakness when meaning is preserved.
Diagnostic use: Use this as public governance language for fair interpretation of multilingual technical reasoning.
Related questions: capacity-007, knowledge-008, gov-004
Required signals: language context, semantic content, evaluation calibration, bias review
MCP source classes: approved evaluation records, calibration records, governance policy
Report sections: Governance and Risk Boundary
Composite L2 Integrity Score
Formula: Integrity_L2 = w1*ICC_band + w2*avg(s_OT) + w3*avg(c_q) + w4*R2_Phase2_to_Phase3 + w5*GC - w6*Delta_trans
Integrity combines consistency, semantic fidelity, conceptual content, phase coherence, grounding, and translation drift.
Diagnostic use: Use this only as public schema context for evaluation governance. Do not expose proprietary weights or private evidence.
Related questions: capacity-007, knowledge-008, gov-004, gov-005
Required signals: approved rubric, calibration evidence, grounding check, translation drift check, audit record
MCP source classes: approved evaluation records, governance policy, audit records
Report sections: Governance and Risk Boundary
Counterfactual ESL Stability
Formula: |c_q - c_q_prime| <= tau_trans
A score should remain stable when the same technical meaning is expressed in standardized English.
Diagnostic use: Use this as an audit question for evaluation systems and AI-assisted talent decisions.
Related questions: capacity-007, gov-004, gov-005
Required signals: counterfactual test result, score drift, translation policy, audit record
MCP source classes: approved evaluation records, audit records, governance policy
Report sections: Governance and Risk Boundary
Adversarial Indistinguishability
Formula: AUC_protected_prediction compared with the 0.5 random-classification baseline
An adversary that performs near the random-classification baseline has not demonstrated useful prediction of the protected attribute. That result is one diagnostic, not proof of fairness or zero leakage.
Diagnostic use: Use this to audit whether evaluation telemetry is fair enough for capacity topology decisions.
Related questions: capacity-007, gov-004, gov-005
Required signals: adversarial test result, AUC summary, feature policy, model audit record
MCP source classes: approved evaluation records, model governance records, audit records
Report sections: Governance and Risk Boundary
Agentic Intervention Load
Formula: Intervention Load Hours = Agent Execution Volume * Error Rate * Mean Human Repair Time + Context Switching Hours
Agent speed is not free. Convert agent errors and context switching into the same human-time unit before comparing agent execution volume with orchestration capacity.
Diagnostic use: Use this to decide whether an agentic workflow is increasing throughput or overloading human orchestrators.
Related questions: agent-001, agent-004, agent-005, agent-006, adaptive-003, telemetry-007
Required signals: agent execution volume, agent error rate, human review load, correction rate, context switching, cycle-time impact, rollback triggers
MCP source classes: agent audit logs, pull request system, work tracker, CI/CD system, incident system
Report sections: Agentic Workflow Control Report, Governed Adaptive Control Loop Report
Engineering Throughput Equation
Formula: Throughput = f(Topology, Cognitive Load, Coordination Cost, AI Assistance)
Throughput is shaped by team topology, cognitive load, coordination cost, and bounded AI assistance, not headcount alone.
Diagnostic use: Use this as the bridge between doctrine math and the Engineering Capacity OS capacity topology questions.
Related questions: capacity-001, capacity-003, topology-003, agent-001, telemetry-006
Required signals: team topology, active WIP, context switching, coordination delay, agent usage, cycle time, quality signal
MCP source classes: work tracker, pull request system, agent audit logs, telemetry platform
Report sections: Capacity Topology Readiness, Agentic Workflow Control Report
TeamStation AI Entity Links
This research page is the scientific proof layer for engineering capacity decisions. The main TeamStation AI hub owns the buyer routes. This page defines the operating model, evidence boundary, answer cards, and workflow report contracts for CTO and CIO evaluation.