Research / Engineering Capacity OS

Engineering Capacity OS Question Engine

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.

Scientific Purpose

This is the complete Engineering Capacity OS question engine. It carries the full taxonomy, evidence boundary, answer card fields, and workflow report mapping for CTO, CIO, and VP Engineering diagnostics.

The hub page is available at /research/engineering-operating-system/. This route is intentionally denser for crawlers, LLMs, and engineering leaders who want the full ontology.

System Model

System function: Engineering Performance(t) = f(C, T, K, D, O, A, L, G) -> {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.

Capacity Intelligence: How much usable engineering capacity exists after load, constraints, and fit are accounted for?
Distributed Capacity Topology: Which capacity topology best fits the work, risk, knowledge, governance, and performance requirements of the engineering system?
Knowledge and Architecture Memory: Does the engineering system have enough explicit knowledge for distributed contributors and AI agents to make safe, high-quality decisions?
Execution Harness / SDLC Control Plane: How consistently does the SDLC produce reproducible outcomes across teams, services, locations, partners, and agentic workflows?
Decision-Grade Engineering Telemetry: Which engineering signals are trusted enough to govern the system?
Governed Agentic SDLC: Which engineering workflows can agents safely execute today, and under what human, technical, and governance constraints?
Governed Adaptive Control Loops: 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.

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

Research Domains

Domain ID	Domain	Questions	Scoring Signals
`capacity_intelligence`	capacity intelligence	8	Capacity Reality, Telemetry Trust
`distributed_capacity_topology`	distributed capacity topology	10	Topology Fit, Knowledge Transfer Readiness, Governance Completeness
`knowledge_architecture_memory`	knowledge architecture memory	8	Knowledge Transfer Readiness, Topology Fit
`execution_harness`	execution harness	10	Execution Determinism, Governance Completeness
`decision_grade_telemetry`	decision grade telemetry	8	Telemetry Trust, Governance Completeness
`governed_agentic_sdlc`	governed agentic sdlc	6	Agent Delegation Safety, Knowledge Transfer Readiness
`governed_adaptive_control_loops`	governed adaptive control loops	4	Agent Delegation Safety, Governance Completeness, Upside Potential
`governance_security_failure_modes`	governance security failure modes	6	Governance Completeness, Topology Fit

CTO Question And Answer Card Inventory

Each question is atomic, evidence-bound, and designed to run inside an organization-controlled MCP server or a redacted evidence pack. The public artifact supplies the question, doctrine answer, evidence requirement, privacy boundary, and report section. The customer answer stays inside the customer boundary.

capacity intelligence

capacity-001. How much usable engineering capacity exists after cognitive load, review load, interruptions, and role fit are accounted for?

Why it matters: Headcount does not represent usable capacity when the system loses time to queues, incidents, meetings, or poor work fit.

Doctrine answer: Usable capacity is committed delivery capacity minus time lost to active WIP, review queues, incidents, interruptions, meetings, and role mismatch over the same measurement window; headcount alone is not capacity.

Validation signal: Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window.

Minimum evidence: active WIP, completed work, review queue age, incident interruptions

Report section: Engineering Capacity OS Diagnostic

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

capacity-002. Which roles or decision points create the current capacity constraint?

Why it matters: Adding contributors does not help if the bottleneck is architecture review, product decision latency, release approval, or a specialized reviewer.

Doctrine answer: The current capacity constraint is the role or decision gate whose queue time and demand exceed its available review or approval capacity, regardless of how many contributors exist upstream.

Validation signal: Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency.

Minimum evidence: queue by role, approval latency, reviewer availability, decision age

Report section: Capacity Constraint Map

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

capacity-003. What percentage of capacity is lost to context switching and fragmented ownership?

Why it matters: Fragmented work creates apparent activity while reducing throughput, quality, and learning.

Doctrine answer: Context-switching loss is the share of available engineering time consumed by work transitions, interrupted tasks, handoffs, and fragmented ownership rather than completed flow.

Validation signal: Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance.

Minimum evidence: active work per contributor, handoff count, interruption count, cycle-time variance

Report section: Engineering Capacity OS Diagnostic

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

capacity-004. Which work types consume scarce senior review or architecture capacity?

Why it matters: Capacity expansion can overload senior reviewers and turn more contributors into slower delivery.

Doctrine answer: Work types with high architectural ambiguity, cross-service impact, security exposure, or weak test boundaries consume the most scarce senior review capacity and should be ranked by measured review demand.

Validation signal: Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency.

Minimum evidence: review dependency, review queue age, rework rate, senior reviewer load

Report section: Capacity Topology Readiness Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

capacity-005. Is the engineering system ready to absorb additional contributors without increasing queue time?

Why it matters: New capacity can create negative throughput if onboarding, review, knowledge, and release systems are not ready.

Doctrine answer: The system is ready for more contributors only when onboarding, knowledge access, review capacity, test reliability, and release controls can absorb the marginal work without increasing queue age or rework.

Validation signal: Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling.

Minimum evidence: onboarding duration, review queue age, PR correction rate, deployment success

Report section: Capacity Topology Readiness Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

capacity-006. What capacity is blocked by missing decisions rather than missing people?

Why it matters: Many capacity problems are decision-system problems: unclear priority, product ambiguity, architecture approval, or governance delay.

Doctrine answer: Decision-blocked capacity is the delivery time lost to unresolved priority, product, architecture, policy, or approval decisions; it must be separated from shortages in contributor availability.

Validation signal: Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency.

Minimum evidence: blocked reason, decision wait time, approval age, priority changes

Report section: Engineering Capacity OS Diagnostic

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

capacity-007. Which skills are scarce enough to determine capacity topology decisions?

Why it matters: Topology decisions should follow scarce skills, knowledge concentration, review authority, and risk boundaries rather than location preference.

Doctrine answer: A skill is topology-determining when demand for that skill, knowledge, or approval authority repeatedly exceeds validated supply and creates a measurable queue or risk boundary.

Validation signal: Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness.

Minimum evidence: skill demand, skill supply, review dependency, ownership concentration

Report section: Capacity Topology Readiness Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

capacity-008. Which capacity constraints should be repaired before any sourcing, hiring, or automation decision is made?

Why it matters: A poor system can absorb hiring, partners, or AI agents and still produce worse delivery behavior.

Doctrine answer: Repair the constraints with the greatest demonstrated queue, quality, and risk impact before adding people, partners, or agents, especially review bottlenecks, decision latency, missing knowledge, and unreliable execution controls.

Validation signal: Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls.

Minimum evidence: queue impact, quality impact, risk impact, control gaps

Report section: Engineering Capacity OS Diagnostic

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

distributed capacity topology

topology-001. Which engineering workstreams are safest to distribute beyond the current core team?

Why it matters: Not all work has the same knowledge, security, coordination, or ownership requirements.

Doctrine answer: The safest workstreams to distribute are low-coupling, explicitly documented, testable, observable, access-bounded, reversible, and supported by sufficient internal review and escalation capacity.

Validation signal: Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability.

Minimum evidence: workstream complexity, dependency count, review requirements, knowledge availability

Report section: Capacity Topology Readiness Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

topology-002. Which workstreams should remain internally owned?

Why it matters: Some work requires direct architectural, product, security, or customer-context control.

Doctrine answer: Work should remain internally owned when it controls strategic architecture, sensitive data, security authority, customer context, regulated decisions, critical IP, or irreversible production impact.

Validation signal: Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact.

Minimum evidence: IP sensitivity, production impact, data sensitivity, architecture authority

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

topology-003. Which capacity topology best matches each workstream?

Why it matters: Internal hiring, external partners, nearshore, offshore, platform investment, and AI agents solve different constraints.

Doctrine answer: The correct topology is selected per workstream by matching skill scarcity, ownership depth, coordination latency, security boundary, review capacity, execution determinism, and telemetry coverage to the available operating model.

Validation signal: Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence.

Minimum evidence: skill fit, ownership requirements, timezone needs, governance constraints

Report section: Capacity Topology Readiness Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

topology-004. Where does time-zone overlap materially affect cycle time?

Why it matters: Distributed capacity fails when decision latency exceeds the work's coordination tolerance.

Doctrine answer: Time-zone overlap materially affects cycle time when work requires same-window architecture decisions, rapid review, coordinated releases, customer response, or incident control; asynchronous work with explicit interfaces is less sensitive.

Validation signal: Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes.

Minimum evidence: blocked time, handoff delay, review latency, incident response requirements

Report section: Capacity Topology Readiness Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

topology-005. What review capacity must exist before adding distributed contributors?

Why it matters: Additional contributors can increase bottlenecks if review and architecture authority do not scale.

Doctrine answer: Distributed contributors should be added only after reviewer availability and architecture authority can meet a defined review service level without increasing correction rate, approval latency, or queue age.

Validation signal: Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes.

Minimum evidence: PR volume, review queue age, reviewer availability, correction rate

Report section: Capacity Topology Readiness Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

topology-006. Which systems or services are ready for external or distributed ownership?

Why it matters: Ownership requires knowledge, test coverage, runbooks, telemetry, and clear escalation paths.

Doctrine answer: A service is ready for distributed ownership when ownership is explicit and current documentation, tests, deployment controls, telemetry, runbooks, escalation paths, and rollback procedures make operation reproducible.

Validation signal: Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity.

Minimum evidence: documentation quality, test reliability, deployment reproducibility, ownership clarity

Report section: Knowledge and Architecture Memory Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

topology-007. What access should each contributor type have?

Why it matters: Capacity topology creates security and IP exposure if access is not role- and risk-based.

Doctrine answer: Each contributor type should receive the least repository, environment, data, secret, deployment, and production access required for its approved work, with time bounds, auditability, and revocation.

Validation signal: Map contributor types to repository, environment, data, secrets, deployment, and production permissions.

Minimum evidence: access class, repository scope, environment permission, production authority

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

topology-008. What is the ramp curve from onboarding to independent contribution?

Why it matters: Capacity is not real until contributors can produce safely without excessive supervision.

Doctrine answer: The ramp curve is the measured progression from access and context acquisition to first accepted change, independent task completion, production-safe contribution, and ownership with declining correction and escalation rates.

Validation signal: Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency.

Minimum evidence: time to first accepted PR, independent task completion, correction rate, escalation frequency

Report section: Knowledge and Architecture Memory Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

topology-009. Which communication rituals reduce decision latency?

Why it matters: Distributed systems need explicit coordination mechanisms.

Doctrine answer: Useful communication rituals reduce decision latency by making ownership, decision records, handoffs, escalation windows, and unresolved blockers explicit without adding more meeting load than the delay they remove.

Validation signal: Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes.

Minimum evidence: blocked states, decision wait time, handoff delay, meeting load

Report section: Capacity Topology Readiness Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

topology-010. What is the exit path if a capacity topology underperforms?

Why it matters: Governance requires reversibility, not only rollout plans.

Doctrine answer: A governed exit path preserves service continuity through documented ownership transfer, knowledge capture, access revocation, IP confirmation, work reassignment, and rollback or replacement triggers defined before rollout.

Validation signal: Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans.

Minimum evidence: exit plan, access removal, ownership transfer, service continuity

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

knowledge architecture memory

knowledge-001. Which parts of the engineering system depend on tribal knowledge?

Why it matters: Tribal knowledge limits distributed execution and safe AI assistance.

Doctrine answer: Tribal-knowledge dependencies are system areas where delivery, review, deployment, or incident response repeatedly requires specific individuals because the necessary decisions, constraints, or procedures are not durable artifacts.

Validation signal: Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals.

Minimum evidence: repeated escalation, undocumented decision, onboarding blocker, individual dependency

Report section: Knowledge and Architecture Memory Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

knowledge-002. How current are architecture decision records?

Why it matters: Distributed contributors and agents need explicit architectural intent.

Doctrine answer: Architecture decision records are current only when they still match deployed services, dependencies, constraints, ownership, and recent implementation and incident evidence; document age alone does not establish validity.

Validation signal: Compare architecture records against current services, dependencies, incidents, and recent implementation choices.

Minimum evidence: ADR freshness, service dependency match, recent decision coverage, incident linkage

Report section: Knowledge and Architecture Memory Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

knowledge-003. Which services have clear ownership maps?

Why it matters: Ownership ambiguity creates delays, rework, and incident risk.

Doctrine answer: A clear service ownership map names the accountable owner, review authority, operational responder, escalation path, and support expectation for every production service and critical dependency.

Validation signal: Verify each service has named owners, escalation paths, review authorities, and support expectations.

Minimum evidence: named owner, escalation path, review authority, support expectation

Report section: Knowledge and Architecture Memory Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

knowledge-004. What knowledge must a contributor have before production-impacting work?

Why it matters: Unsafe delegation often starts with insufficient context.

Doctrine answer: Before production-impacting work, a contributor needs verified knowledge of service behavior, architecture constraints, data sensitivity, tests, deployment and rollback procedures, incident history, and approval boundaries.

Validation signal: Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries.

Minimum evidence: required knowledge checklist, deployment process, incident history, approval boundary

Report section: Knowledge and Architecture Memory Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

knowledge-005. Which knowledge sources are safe for AI retrieval?

Why it matters: Agentic workflows need context without exposing secrets, customer data, or sensitive records.

Doctrine answer: AI retrieval should be limited to approved, access-controlled knowledge whose sensitivity is classified and whose content excludes secrets, customer records, privileged logs, and other data outside the agent's task boundary.

Validation signal: Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission.

Minimum evidence: sensitivity class, retrieval permission, redaction rule, audit requirement

Report section: Agent Delegation Safety Matrix

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

knowledge-006. Where does documentation drift create delivery risk?

Why it matters: Outdated documentation causes incorrect decisions by humans and agents.

Doctrine answer: Documentation drift creates delivery risk wherever documented ownership, deployment, recovery, architecture, or policy no longer matches observed system behavior and can cause a human or agent to take an invalid action.

Validation signal: Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior.

Minimum evidence: documented procedure, actual procedure, drift instance, risk impact

Report section: Knowledge and Architecture Memory Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

knowledge-007. How are incidents converted into durable system memory?

Why it matters: Learning requires failures to update rules, tests, runbooks, and agent instructions.

Doctrine answer: An incident becomes durable system memory only when verified lessons update executable controls such as tests, alerts, runbooks, ownership, architecture records, workflow rules, or agent instructions.

Validation signal: Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints.

Minimum evidence: incident outcome, updated test, updated runbook, new workflow rule

Report section: Knowledge and Architecture Memory Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

knowledge-008. What evidence proves a distributed contributor is ready for ownership?

Why it matters: Ownership should be evidence-based, not tenure-based.

Doctrine answer: Ownership readiness is demonstrated by accepted work, accurate system explanations, reliable deployments, low correction rates, sound incident behavior, and appropriate escalation across a representative evidence window.

Validation signal: Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior.

Minimum evidence: accepted work, correction rate, deployment success, escalation behavior

Report section: Capacity Topology Readiness Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

execution harness

execution-001. How standardized are CI/CD pipelines across teams, services, and contributor types?

Why it matters: Distributed and AI-assisted capacity requires reproducible execution, not local delivery customs.

Doctrine answer: CI/CD is standardized when teams and contributor types use versioned pipeline templates, required quality and approval gates, consistent deployment paths, controlled exceptions, and equivalent audit evidence.

Validation signal: Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency.

Minimum evidence: pipeline template, required gate, manual override, exception frequency

Report section: Execution Determinism Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

execution-002. Where does execution variance enter the delivery system?

Why it matters: Variance hides inside local workflow differences, skipped gates, environment drift, and undocumented release paths.

Doctrine answer: Execution variance enters wherever teams use divergent templates, manual steps, skipped gates, environment-specific behavior, undocumented release paths, or ungoverned overrides that change outcomes for equivalent work.

Validation signal: Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior.

Minimum evidence: manual step, skipped gate, template divergence, environment drift

Report section: Execution Determinism Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

execution-003. Which SDLC controls are system-enforced versus manually enforced?

Why it matters: Manual enforcement breaks under scale, distribution, and agentic speed.

Doctrine answer: A control is system-enforced when the delivery platform automatically applies and records it; a policy, checklist, or reviewer habit is manually enforced and should not be treated as deterministic control.

Validation signal: Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented.

Minimum evidence: control class, automation status, manual gate, undocumented exception

Report section: Execution Determinism Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

execution-004. How reproducible are production deployments across services?

Why it matters: A topology can scale only when deployments behave as governed system states.

Doctrine answer: Production deployments are reproducible when equivalent versioned inputs, environment state, approvals, and pipeline rules produce consistent releases with tested rollback paths and explainable outcomes across services.

Validation signal: Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services.

Minimum evidence: deployment input, approval path, rollback record, post-deploy outcome

Report section: Execution Determinism Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

execution-005. Where do pipeline failures originate most frequently?

Why it matters: Failure concentration reveals weak execution stages before capacity increases amplify them.

Doctrine answer: The dominant pipeline failure origin is the stage and cause class with the highest recurring failure burden after runs are classified by build, test, security, approval, environment, deployment, and recovery behavior.

Validation signal: Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence.

Minimum evidence: failure stage, cause class, recovery path, recurrence

Report section: Execution Determinism Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

execution-006. Who defines and changes execution rules in the SDLC?

Why it matters: Execution rule ownership is required before distributed teams or agents can safely modify workflows.

Doctrine answer: Execution rules require named owners, authorized approvers, versioned change records, audit history, exception handling, and rollback authority before teams or agents can modify them safely.

Validation signal: Map SDLC execution rules to owners, approval authority, change process, and audit record.

Minimum evidence: rule owner, approval authority, change process, audit record

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

execution-007. How are workflow standards propagated across teams?

Why it matters: Scaling requires controlled propagation of standards rather than informal copying.

Doctrine answer: Workflow standards propagate reliably through versioned templates, automated checks, controlled rollout, conformance telemetry, and explicit exception records rather than documentation and informal copying alone.

Validation signal: Compare documented standards with templates, automated checks, rollout records, and exception logs.

Minimum evidence: standard template, automated check, rollout record, exception

Report section: Execution Determinism Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

execution-008. What is the cost of pipeline inconsistency?

Why it matters: Inconsistency converts capacity into waiting, rework, release risk, and operational overhead.

Doctrine answer: Pipeline inconsistency costs the engineering system the measured cycle time, failed runs, manual intervention, rework, rollback exposure, and release delay attributable to divergent execution paths.

Validation signal: Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class.

Minimum evidence: cycle time by pipeline class, failed run rate, manual intervention, rollback event

Report section: Execution Determinism Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

execution-009. Which execution paths are safe for AI-assisted or external contributors?

Why it matters: Delegation safety depends on deterministic test, review, approval, deployment, and rollback paths.

Doctrine answer: An execution path is safe for AI-assisted or external contribution only when permissions are bounded and tests, review, approval, deployment, audit, and rollback controls constrain the path's blast radius.

Validation signal: Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness.

Minimum evidence: test reliability, approval boundary, production impact, rollback readiness

Report section: Agent Delegation Safety Matrix

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

execution-010. What breaks in execution when delivery volume increases?

Why it matters: Volume exposes weak gates, slow reviews, unstable environments, and fragile deployment paths.

Doctrine answer: When delivery volume rises, the first execution failures appear at gates whose service capacity does not scale, including review, tests, environments, approvals, deployment concurrency, and rollback handling.

Validation signal: Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes.

Minimum evidence: volume change, failure rate, queue time, environment conflict

Report section: Execution Determinism Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

decision grade telemetry

telemetry-001. Which engineering signals are trusted enough to govern capacity topology decisions?

Why it matters: Topology decisions require evidence that explains delivery behavior, not dashboard activity.

Doctrine answer: A signal is trusted for topology governance only when its source, definition, freshness, coverage, aggregation, known bias, and history of decision use are documented and tied to delivery outcomes.

Validation signal: Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history.

Minimum evidence: metric source, freshness, coverage, decision history

Report section: Engineering Capacity OS Diagnostic

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

telemetry-002. Which signals correlate with delivery success rather than activity volume?

Why it matters: Activity metrics can increase while speed, quality, cost, risk, and business value degrade.

Doctrine answer: Outcome signals are metrics that demonstrate a stable relationship with delivery speed, quality, cost, risk, reliability, or business milestones; activity counts without that relationship are not decision-grade evidence.

Validation signal: Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones.

Minimum evidence: metric correlation, defect signal, cycle time, business milestone

Report section: Engineering Capacity OS Diagnostic

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

telemetry-003. How real-time is delivery visibility for leaders?

Why it matters: Slow telemetry creates delayed intervention and makes adaptive control unsafe.

Doctrine answer: Delivery visibility is real-time only to the degree that reporting latency remains below the intervention window for work queues, reviews, pipeline failures, deployments, incidents, and agent actions.

Validation signal: Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions.

Minimum evidence: reporting latency, refresh interval, coverage gap, stale metric

Report section: Engineering Capacity OS Diagnostic

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

telemetry-004. Where are queues invisible to current dashboards?

Why it matters: Hidden queues are a common cause of false capacity conclusions.

Doctrine answer: A queue is invisible when work waits for review, approval, dependencies, decisions, environments, or incident recovery without a distinct timestamped state in the leadership telemetry model.

Validation signal: Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage.

Minimum evidence: hidden wait, approval wait, dependency wait, dashboard coverage

Report section: Engineering Capacity OS Diagnostic

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

telemetry-005. Which telemetry detects quality degradation after capacity, topology, or AI changes?

Why it matters: A capacity intervention is weak if it increases speed while degrading quality or risk.

Doctrine answer: Quality degradation after a capacity or AI change is detected through changes in failed tests, review corrections, reverts, escaped defects, incidents, rollback events, and customer impact against a pre-change baseline.

Validation signal: Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change.

Minimum evidence: defect escape, review correction, revert, rollback, incident

Report section: Agent Delegation Safety Matrix

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

telemetry-006. What telemetry compares topology performance without exposing individual employee data?

Why it matters: Leaders need topology evidence while avoiding surveillance and individual performance misuse.

Doctrine answer: Topology performance should be compared with aggregated workstream or team-level flow, quality, deployment, incident, and rework signals, never individual surveillance or employee ranking.

Validation signal: Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology.

Minimum evidence: aggregate cycle time, team-level queue time, topology class, defect rate

Report section: Capacity Topology Readiness Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

telemetry-007. Which metrics should trigger governance review before scaling automation?

Why it matters: Agentic and adaptive systems need stop conditions before local optimizations harm global performance.

Doctrine answer: Governance review should trigger when agent or automation telemetry crosses predefined limits for failed validation, reverts, policy exceptions, human overrides, quality drift, incident correlation, or unbounded actions.

Validation signal: Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift.

Minimum evidence: validation failure threshold, human override rate, policy exception, quality drift

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

telemetry-008. Which signals are missing but necessary for the next operating decision?

Why it matters: A responsible model should mark unknowns instead of inventing certainty.

Doctrine answer: A necessary signal is missing when the pending decision requires an evidence class that has no reliable source, insufficient coverage, excessive latency, or an unknown definition; the correct result is an instrumentation gap, not an inferred fact.

Validation signal: Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation.

Minimum evidence: required evidence, available evidence, missing instrumentation, confidence tier

Report section: Engineering Capacity OS Diagnostic

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

governed agentic sdlc

agent-001. Which agentic workflows reduce onboarding time for distributed contributors?

Why it matters: AI can improve capacity only if it reduces context acquisition cost without increasing rework.

Doctrine answer: Agentic workflows reduce onboarding time when they accelerate safe context retrieval, environment setup, task decomposition, and feedback while first accepted work arrives sooner without higher correction or escalation rates.

Validation signal: Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency.

Minimum evidence: onboarding duration, first accepted PR, documentation usage, correction rate

Report section: Agent Delegation Safety Matrix

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

agent-002. Which AI-generated outputs can distributed teams safely validate?

Why it matters: Validation authority must match skill, context, and risk.

Doctrine answer: AI-generated output is safely validatable when the reviewer has the required domain context and the output is reversible, testable, provenance-marked, bounded in blast radius, and subject to an explicit approval path.

Validation signal: Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path.

Minimum evidence: output type, reversibility, test coverage, approval path

Report section: Agent Delegation Safety Matrix

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

agent-003. Which AI tools are allowed for each contributor type?

Why it matters: AI usage creates data exposure, IP, and governance risk.

Doctrine answer: Allowed AI tools must be assigned by contributor role, task, data classification, repository boundary, retention policy, permission scope, and audit requirement rather than made universally available.

Validation signal: Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements.

Minimum evidence: approved tool, data class, access class, audit requirement

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

agent-004. How are AI-generated PRs reviewed across distributed teams?

Why it matters: AI can increase review burden if review policy is unclear.

Doctrine answer: AI-generated pull requests require recorded provenance, automated test evidence, risk-based human review, correction tracking, approval authority, and rollback readiness equivalent to or stronger than human-generated changes.

Validation signal: Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence.

Minimum evidence: PR provenance, review path, correction rate, test evidence

Report section: Agent Delegation Safety Matrix

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

agent-005. What telemetry detects agent-generated rework?

Why it matters: AI productivity claims are weak unless rework is measured.

Doctrine answer: Agent-generated rework is detected by linking AI provenance to review corrections, reopened work, failed tests, reverted changes, escaped defects, and downstream cycle-time impact.

Validation signal: Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact.

Minimum evidence: reopened ticket, review correction, failed test, reverted commit

Report section: Agent Delegation Safety Matrix

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

agent-006. Which workflows should remain human-gated until trust improves?

Why it matters: Agentic delegation should expand only when validation and governance mature.

Doctrine answer: Workflows with high ambiguity, sensitive data, architecture authority, customer or production impact, weak validation, or irreversible consequences should remain human-gated until evidence demonstrates bounded agent reliability.

Validation signal: Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences.

Minimum evidence: ambiguity class, data sensitivity, production impact, approval requirement

Report section: Agent Delegation Safety Matrix

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

governed adaptive control loops

adaptive-001. Can the engineering system recommend workflow changes from telemetry without automatically applying them?

Why it matters: Adaptive control should begin with governed recommendations before self-modifying execution.

Doctrine answer: The system may generate evidence-backed workflow recommendations without applying them; each recommendation must expose its source signals, assumptions, expected effect, approval path, measurement plan, and rollback condition.

Validation signal: Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement.

Minimum evidence: recommendation, evidence trail, approval path, rollback path

Report section: Governed Adaptive Control Loop Review

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

adaptive-002. Which workflow rules can be safely modified under governance?

Why it matters: Not every execution rule should be adaptive; some rules encode security, compliance, or architecture constraints.

Doctrine answer: Only reversible, observable, low-blast-radius workflow rules may be adaptive by default; security, compliance, architecture, data, and production authority rules require explicit human governance.

Validation signal: Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval.

Minimum evidence: rule class, blast radius, reversibility, approval requirement

Report section: Governed Adaptive Control Loop Review

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

adaptive-003. How does the system detect when adaptive changes degrade performance?

Why it matters: Learning loops need negative feedback and stop conditions.

Doctrine answer: Adaptive degradation is detected by comparing post-change quality, cycle time, failed validation, override, incident, and rollback signals against baselines and predefined stop conditions.

Validation signal: Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes.

Minimum evidence: post-change delta, quality drift, override rate, rollback trigger

Report section: Governed Adaptive Control Loop Review

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

adaptive-004. Who can approve, audit, and reverse adaptive changes to the SDLC?

Why it matters: Self-improving systems require explicit authority and reversibility.

Doctrine answer: Every adaptive change class must have named approval authority, immutable audit evidence, an accountable system owner, independent rollback authority, and defined emergency stop conditions.

Validation signal: Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions.

Minimum evidence: approver, audit log, rollback authority, stop condition

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

governance security failure modes

gov-001. Who owns delivery risk for externally or agent-produced work?

Why it matters: Distributed and AI-assisted delivery require clear accountability.

Doctrine answer: Delivery risk remains owned by the accountable internal leader who authorizes the work and controls acceptance, production approval, and incident response, even when execution is external or agent-assisted.

Validation signal: Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility.

Minimum evidence: accountable owner, review authority, approval path, incident responsibility

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

gov-002. Which production actions require internal approval?

Why it matters: Production authority must be explicit in distributed systems.

Doctrine answer: Internal approval is required for production actions whose blast radius, data impact, customer effect, irreversibility, or regulatory significance exceeds the organization's predefined authority threshold.

Validation signal: Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement.

Minimum evidence: production action, approval requirement, approver, audit record

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

gov-003. Which systems are off-limits to external contributors or agents?

Why it matters: Security boundaries must be defined before capacity is distributed.

Doctrine answer: External contributors and agents must be excluded from systems whose data sensitivity, privilege level, regulatory boundary, strategic IP, or production blast radius cannot be contained by least-privilege controls.

Validation signal: Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools.

Minimum evidence: restricted system, access boundary, data class, privileged tool

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

gov-004. How is IP assignment and contribution provenance verified?

Why it matters: External and AI-assisted work creates IP and ownership questions.

Doctrine answer: IP assignment and contribution provenance are verified through enforceable agreements, authenticated contributor identity, commit and PR provenance, AI-tool disclosure, review records, and acceptance history.

Validation signal: Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records.

Minimum evidence: IP assignment, commit provenance, tool usage log, approval record

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

gov-005. How are policy exceptions logged and reviewed?

Why it matters: Exceptions reveal where governance is weak or misaligned with reality.

Doctrine answer: Policy exceptions require a timestamped request, business justification, accountable approver, bounded duration, affected assets, compensating controls, remediation owner, recurrence review, and closure evidence.

Validation signal: Compare exception records, approval paths, recurrence, business justification, and remediation actions.

Minimum evidence: exception record, approval path, recurrence, remediation action

Report section: Governance, Security, and IP Control Report

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

gov-006. What breaks first when capacity, distribution, or automation increases?

Why it matters: Failure-mode analysis turns scaling plans into testable risk hypotheses.

Doctrine answer: The first scaling failure is the constraint whose demand grows faster than its control capacity; test this across review queues, architecture decisions, knowledge transfer, pipeline consistency, agent rework, access control, and governance latency.

Validation signal: Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag.

Minimum evidence: hidden queue, review bottleneck, pipeline drift, governance lag

Report section: Engineering Capacity OS Diagnostic

Safe data boundary: Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation.

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, question system, evidence boundary, answer cards, and workflow report contracts for CTO and CIO evaluation.