# Engineering Capacity OS Formula Registry

Version: 1.1
Formula entries: 25

Map published TeamStation Engineering Doctrine formulas and algorithmic concepts to Engineering Capacity OS research questions, private MCP evidence, answer cards, and workflow reports.

## Privacy Boundary

The public registry defines formulas, evidence requirements, and interpretation rules. Customer source code, secrets, raw logs, customer records, payroll data, legal records, and employee-level performance records stay inside the organization.

## How To Use

- Select the operating problem and matching research question.
- Find the related formula or algorithmic concept in this registry.
- Retrieve only aggregate or redacted evidence from approved internal systems.
- Apply the interpretation rules to create answer cards with observed state, confidence, missing evidence, risk flags, and next safe action.
- Do not treat a formula as a private scoring engine unless the required evidence is present and source-cited.

## Formula Registry

### Engineering Performance Function

- ID: engineering_performance_function
- Formula: `P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}`
- Plain language: 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 categories: work tracker, source control, pull request system, CI/CD system, incident system, architecture catalog, telemetry platform, policy system
- Answer card fields: observed_state, evidence_summary, confidence, missing_evidence, risk_flags, next_safe_action
- Report sections: Executive Summary, System Function Map, Risk Boundary, Next Safe Action
- Public source routes: none

### Sequential Probability Network

- ID: sequential_probability_network
- Formula: `P = product(p_i) for i=1..n`
- Plain language: 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 categories: work tracker, pull request system, architecture catalog, service registry, CI/CD system
- Answer card fields: chain_map, constraint_node, dependency_wait, confidence, missing_evidence
- Report sections: Capacity Constraint Map, Topology Readiness, Execution Failure Modes
- Public source routes: none

### Strict Complementarity

- ID: strict_complementarity
- Formula: `p_{k+2} - p_{k+1} > p_{k+1} - p_k`
- Plain language: 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 categories: pull request system, architecture decision records, work tracker, engineering review records
- Answer card fields: pivotal_node, upstream_quality_signal, downstream_blockage, risk_flags
- Report sections: Capacity Constraint Map, Knowledge and Ownership Risk
- Public source routes: none

### Shirking Margin

- ID: shirking_margin_zeta
- Formula: `zeta_i^x = P(project succeeds | e_i=0, policy x)`
- Plain language: 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 categories: pull request system, test system, incident system, work tracker, agent audit logs
- Answer card fields: rescue_pattern, quality_escape, owner_boundary, confidence
- Report sections: Agentic Workflow Control Report, Governance and Risk Boundary
- Public source routes: none

### Incentive Compatibility Constraint

- ID: incentive_compatibility_constraint
- Formula: `p_n * w_i - c >= zeta_i^x * w_i`
- Plain language: 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 categories: work tracker, calendar metadata if approved and aggregated, pull request system, decision records
- Answer card fields: effort_friction, blocked_time, ownership_gap, next_safe_action
- Report sections: Capacity Constraint Map, Topology Readiness
- Public source routes: none

### Wage Equation

- ID: wage_equation
- Formula: `w_i^x = c / (p_n - zeta_i^x)`
- Plain language: 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 categories: work tracker, pull request system, incident system, finance or planning summaries if approved
- Answer card fields: cost_driver, delay_driver, rework_driver, evidence_gap
- Report sections: Cost, Value, and Risk Economics, Topology Readiness
- Public source routes: none

### Replacement Kinetics Derivative

- ID: replacement_kinetics_derivative
- Formula: `partial C / partial x_i = Direct Savings - Incentive Distortion`
- Plain language: 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 categories: agent audit logs, pull request system, CI/CD system, policy system, incident system
- Answer card fields: workflow_position, automation_class, blast_radius, rollback_path
- Report sections: Agentic Workflow Control Report, Governed Adaptive Control Loop Report
- Public source routes: none

### Kingman Wait Time Approximation

- ID: kingman_wait_time
- Formula: `E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau`
- Plain language: 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 categories: work tracker, pull request system, CI/CD system, incident system
- Answer card fields: queue_age, wip_level, cycle_time_variance, capacity_risk
- Report sections: Capacity Constraint Map, Telemetry Trust Report
- Public source routes: none

### Little's Law

- ID: little_law
- Formula: `L = lambda * W`
- Plain language: 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 categories: work tracker, pull request system
- Answer card fields: wip_level, throughput, lead_time, queue_risk
- Report sections: Capacity Constraint Map, Execution Control Report
- Public source routes: none

### Rule of Two WIP Constraint

- ID: wip_rule_of_two
- Formula: `WIP_person <= 2`
- Plain language: 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 categories: work tracker, pull request system
- Answer card fields: active_wip, fragmentation_risk, blocked_work, next_safe_action
- Report sections: Capacity Constraint Map, Execution Control Report
- Public source routes: none

### Cost of Delay

- ID: cost_of_delay
- Formula: `CoD = dV_lost / dt = -dV_remaining / dt`
- Plain language: 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 categories: product roadmap, work tracker, release management, finance or planning summaries if approved
- Answer card fields: value_at_risk, time_sensitivity, blocked_dependency, confidence
- Report sections: Cost, Value, and Risk Economics, Executive Summary
- Public source routes: none

### Dependency Density

- ID: dependency_density
- Formula: `E_max = N(N-1)/2; D = E/E_max`
- Plain language: 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 categories: service registry, architecture catalog, source control, incident system, work tracker
- Answer card fields: dependency_map, owner_map, integration_risk, missing_evidence
- Report sections: Topology Readiness, Failure Mode Register
- Public source routes: none

### Synchronization Penalty

- ID: synchronization_penalty
- Formula: `S_p = sum(T_wait + T_context_switch)`
- Plain language: 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 categories: work tracker, pull request system, calendar metadata if approved and aggregated, engineering chat summaries if approved and redacted
- Answer card fields: wait_time, context_switching, topology_constraint, confidence
- Report sections: Topology Readiness, Capacity Constraint Map
- Public source routes: none

### Availability and MTTR

- ID: availability_mttr
- Formula: `A = MTBF / (MTBF + MTTR)`
- Plain language: 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 categories: CI/CD system, incident system, observability platform, change management
- Answer card fields: mttr, rollback_time, change_failure_rate, governance_gap
- Report sections: Execution Control Report, Governance and Failure Mode Register
- Public source routes: none

### MTTR Limit Behavior

- ID: mttr_limit_behavior
- Formula: `lim_{MTTR -> 0} MTBF / (MTBF + MTTR) = 1`
- Plain language: 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 categories: CI/CD system, feature flag system, incident system, policy system
- Answer card fields: mitigation_time, approval_latency, rollback_authority, auditability
- Report sections: Execution Control Report, Governance and Risk Boundary
- Public source routes: none

### Mutation Score

- ID: mutation_score
- Formula: `MS = K / (T - E)`
- Plain language: 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 categories: test system, CI/CD system, pull request system, incident system
- Answer card fields: test_strength, defect_signal, ai_validation_boundary, confidence
- Report sections: Telemetry Trust Report, Agentic Workflow Control Report
- Public source routes: none

### Cognitive Fidelity

- ID: cognitive_fidelity
- Formula: `Quality ~ isomorphism(M_e, S_sys)`
- Plain language: 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 categories: architecture catalog, documentation system, pull request system, incident system, agent audit logs
- Answer card fields: knowledge_gap, mental_model_drift, review_signal, durable_memory_action
- Report sections: Knowledge and Ownership Risk, Agentic Workflow Control Report
- Public source routes: none

### L2 Adjusted Communication Score

- ID: l2_adjusted_score
- Formula: `s_adj = s_raw - beta * (f_error - E[f | P])`
- Plain language: 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 categories: approved evaluation records, calibration records, governance policy
- Answer card fields: evaluation_boundary, calibration_evidence, bias_control, confidence
- Report sections: Governance and Risk Boundary, Capacity Topology Readiness
- Public source routes: none

### Frechet Semantic Distance

- ID: 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))`
- Plain language: 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 categories: approved evaluation records, knowledge base, governance policy
- Answer card fields: semantic_match_boundary, calibration_status, source_class, missing_evidence
- Report sections: Knowledge and Ownership Risk, Governance and Risk Boundary
- Public source routes: none

### Optimal Transport With Code Switch Awareness

- ID: optimal_transport_code_switch
- Formula: `s_q^OT = psi(W_2(P_q,Q_q; C o (1 - lambda M)))`
- Plain language: 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 categories: approved evaluation records, calibration records, governance policy
- Answer card fields: language_boundary, semantic_evidence, bias_review, confidence
- Report sections: Governance and Risk Boundary
- Public source routes: none

### Composite L2 Integrity Score

- ID: integrity_l2
- Formula: `Integrity_L2 = w1*ICC_band + w2*avg(s_OT) + w3*avg(c_q) + w4*R2_Phase2_to_Phase3 + w5*GC - w6*Delta_trans`
- Plain language: 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 categories: approved evaluation records, governance policy, audit records
- Answer card fields: calibration_status, audit_status, private_data_boundary, missing_evidence
- Report sections: Governance and Risk Boundary
- Public source routes: none

### Counterfactual ESL Stability

- ID: counterfactual_esl_stability
- Formula: `|c_q - c_q_prime| <= tau_trans`
- Plain language: 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 categories: approved evaluation records, audit records, governance policy
- Answer card fields: score_stability, bias_risk, audit_record, next_safe_action
- Report sections: Governance and Risk Boundary
- Public source routes: none

### Adversarial Indistinguishability

- ID: adversarial_indistinguishability
- Formula: `AUC_protected_prediction compared with the 0.5 random-classification baseline`
- Plain language: 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 categories: approved evaluation records, model governance records, audit records
- Answer card fields: auc_summary, leakage_risk, audit_status, confidence
- Report sections: Governance and Risk Boundary
- Public source routes: none

### Agentic Intervention Load

- ID: agentic_intervention_load
- Formula: `Intervention Load Hours = Agent Execution Volume * Error Rate * Mean Human Repair Time + Context Switching Hours`
- Plain language: 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 categories: agent audit logs, pull request system, work tracker, CI/CD system, incident system
- Answer card fields: agent_volume, agent_error_rate, human_review_load, throttle_recommendation
- Report sections: Agentic Workflow Control Report, Governed Adaptive Control Loop Report
- Public source routes: none

### Engineering Throughput Equation

- ID: engineering_throughput_equation
- Formula: `Throughput = f(Topology, Cognitive Load, Coordination Cost, AI Assistance)`
- Plain language: 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 categories: work tracker, pull request system, agent audit logs, telemetry platform
- Answer card fields: throughput_signal, topology_signal, cognitive_load_signal, agent_assistance_signal
- Report sections: Capacity Topology Readiness, Agentic Workflow Control Report
- Public source routes: none