# Engineering Capacity OS Research Questions

Version: 3.0
Total questions: 60

This Markdown export is generated from the same canonical question array used by the UI and JSON API.

## Capacity Intelligence

Questions: 8

- [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.
  - Validation signal: Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window.
- [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.
  - Validation signal: Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency.
- [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.
  - Validation signal: Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance.
- [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.
  - Validation signal: Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency.
- [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.
  - Validation signal: Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling.
- [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.
  - Validation signal: Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency.
- [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.
  - Validation signal: Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness.
- [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.
  - Validation signal: Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls.

## Distributed Capacity Topology

Questions: 10

- [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.
  - Validation signal: Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability.
- [topology-002] Which workstreams should remain internally owned?
  - Why it matters: Some work requires direct architectural, product, security, or customer-context control.
  - Validation signal: Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact.
- [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.
  - Validation signal: Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence.
- [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.
  - Validation signal: Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes.
- [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.
  - Validation signal: Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes.
- [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.
  - Validation signal: Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity.
- [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.
  - Validation signal: Map contributor types to repository, environment, data, secrets, deployment, and production permissions.
- [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.
  - Validation signal: Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency.
- [topology-009] Which communication rituals reduce decision latency?
  - Why it matters: Distributed systems need explicit coordination mechanisms.
  - Validation signal: Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes.
- [topology-010] What is the exit path if a capacity topology underperforms?
  - Why it matters: Governance requires reversibility, not only rollout plans.
  - Validation signal: Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans.

## Knowledge and Architecture Memory

Questions: 8

- [knowledge-001] Which parts of the engineering system depend on tribal knowledge?
  - Why it matters: Tribal knowledge limits distributed execution and safe AI assistance.
  - Validation signal: Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals.
- [knowledge-002] How current are architecture decision records?
  - Why it matters: Distributed contributors and agents need explicit architectural intent.
  - Validation signal: Compare architecture records against current services, dependencies, incidents, and recent implementation choices.
- [knowledge-003] Which services have clear ownership maps?
  - Why it matters: Ownership ambiguity creates delays, rework, and incident risk.
  - Validation signal: Verify each service has named owners, escalation paths, review authorities, and support expectations.
- [knowledge-004] What knowledge must a contributor have before production-impacting work?
  - Why it matters: Unsafe delegation often starts with insufficient context.
  - Validation signal: Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries.
- [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.
  - Validation signal: Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission.
- [knowledge-006] Where does documentation drift create delivery risk?
  - Why it matters: Outdated documentation causes incorrect decisions by humans and agents.
  - Validation signal: Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior.
- [knowledge-007] How are incidents converted into durable system memory?
  - Why it matters: Learning requires failures to update rules, tests, runbooks, and agent instructions.
  - Validation signal: Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints.
- [knowledge-008] What evidence proves a distributed contributor is ready for ownership?
  - Why it matters: Ownership should be evidence-based, not tenure-based.
  - Validation signal: Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior.

## Execution Harness / SDLC Control Plane

Questions: 10

- [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.
  - Validation signal: Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency.
- [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.
  - Validation signal: Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior.
- [execution-003] Which SDLC controls are system-enforced versus manually enforced?
  - Why it matters: Manual enforcement breaks under scale, distribution, and agentic speed.
  - Validation signal: Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented.
- [execution-004] How reproducible are production deployments across services?
  - Why it matters: A topology can scale only when deployments behave as governed system states.
  - Validation signal: Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services.
- [execution-005] Where do pipeline failures originate most frequently?
  - Why it matters: Failure concentration reveals weak execution stages before capacity increases amplify them.
  - Validation signal: Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence.
- [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.
  - Validation signal: Map SDLC execution rules to owners, approval authority, change process, and audit record.
- [execution-007] How are workflow standards propagated across teams?
  - Why it matters: Scaling requires controlled propagation of standards rather than informal copying.
  - Validation signal: Compare documented standards with templates, automated checks, rollout records, and exception logs.
- [execution-008] What is the cost of pipeline inconsistency?
  - Why it matters: Inconsistency converts capacity into waiting, rework, release risk, and operational overhead.
  - Validation signal: Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class.
- [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.
  - Validation signal: Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness.
- [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.
  - Validation signal: Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes.

## Decision-Grade Engineering Telemetry

Questions: 8

- [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.
  - Validation signal: Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history.
- [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.
  - Validation signal: Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones.
- [telemetry-003] How real-time is delivery visibility for leaders?
  - Why it matters: Slow telemetry creates delayed intervention and makes adaptive control unsafe.
  - Validation signal: Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions.
- [telemetry-004] Where are queues invisible to current dashboards?
  - Why it matters: Hidden queues are a common cause of false capacity conclusions.
  - Validation signal: Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage.
- [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.
  - Validation signal: Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change.
- [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.
  - Validation signal: Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology.
- [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.
  - Validation signal: Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift.
- [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.
  - Validation signal: Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation.

## Governed Agentic SDLC

Questions: 6

- [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.
  - Validation signal: Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency.
- [agent-002] Which AI-generated outputs can distributed teams safely validate?
  - Why it matters: Validation authority must match skill, context, and risk.
  - Validation signal: Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path.
- [agent-003] Which AI tools are allowed for each contributor type?
  - Why it matters: AI usage creates data exposure, IP, and governance risk.
  - Validation signal: Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements.
- [agent-004] How are AI-generated PRs reviewed across distributed teams?
  - Why it matters: AI can increase review burden if review policy is unclear.
  - Validation signal: Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence.
- [agent-005] What telemetry detects agent-generated rework?
  - Why it matters: AI productivity claims are weak unless rework is measured.
  - Validation signal: Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact.
- [agent-006] Which workflows should remain human-gated until trust improves?
  - Why it matters: Agentic delegation should expand only when validation and governance mature.
  - Validation signal: Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences.

## Governed Adaptive Control Loops

Questions: 4

- [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.
  - Validation signal: Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement.
- [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.
  - Validation signal: Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval.
- [adaptive-003] How does the system detect when adaptive changes degrade performance?
  - Why it matters: Learning loops need negative feedback and stop conditions.
  - Validation signal: Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes.
- [adaptive-004] Who can approve, audit, and reverse adaptive changes to the SDLC?
  - Why it matters: Self-improving systems require explicit authority and reversibility.
  - Validation signal: Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions.

## Governance, Security, and Failure Modes

Questions: 6

- [gov-001] Who owns delivery risk for externally or agent-produced work?
  - Why it matters: Distributed and AI-assisted delivery require clear accountability.
  - Validation signal: Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility.
- [gov-002] Which production actions require internal approval?
  - Why it matters: Production authority must be explicit in distributed systems.
  - Validation signal: Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement.
- [gov-003] Which systems are off-limits to external contributors or agents?
  - Why it matters: Security boundaries must be defined before capacity is distributed.
  - Validation signal: Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools.
- [gov-004] How is IP assignment and contribution provenance verified?
  - Why it matters: External and AI-assisted work creates IP and ownership questions.
  - Validation signal: Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records.
- [gov-005] How are policy exceptions logged and reviewed?
  - Why it matters: Exceptions reveal where governance is weak or misaligned with reality.
  - Validation signal: Compare exception records, approval paths, recurrence, business justification, and remediation actions.
- [gov-006] What breaks first when capacity, distribution, or automation increases?
  - Why it matters: Failure-mode analysis turns scaling plans into testable risk hypotheses.
  - Validation signal: Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag.