# Engineering Capacity Operating System Canonical title: Engineering Capacity Operating System Research Version: 3.0 Schema version: 3.0.0 Status: canonical_research_node Human route: https://engineering.teamstation.dev/research/engineering-operating-system JSON route: https://engineering.teamstation.dev/api/research/engineering-operating-system Static JSON route: https://engineering.teamstation.dev/api/research/engineering-operating-system.json Markdown route: https://engineering.teamstation.dev/api/research/engineering-operating-system.md Question API route: https://engineering.teamstation.dev/api/research/questions AI Diagnostic Protocol: https://engineering.teamstation.dev/api/research/engineering-operating-system.skill.md ## Executive Summary A location-agnostic research model for structuring, governing, measuring, and improving distributed engineering capacity across teams, partners, platforms, and AI agents. Engineering teams are no longer defined only by employees, offices, or vendors. Modern capacity is distributed across internal teams, external partners, global talent, platforms, and AI agents. Engineering Capacity OS helps CTOs, CIOs, and VPs of Engineering decide where engineering work should live, which workflows can be safely delegated, which controls must exist before capacity is scaled, and which telemetry is trustworthy enough to govern the system. This page is not a staffing recommendation, vendor thesis, or location thesis. It is a research artifact for evaluating how engineering capacity should be structured, measured, and governed. ## Location-Agnostic Positioning Engineering capacity is no longer a location decision. It is an operating-system decision. The model does not assume that engineering work should be centralized, nearshore, offshore, outsourced, insourced, or automated. It treats each option as a capacity topology that must be tested against evidence: skill fit, knowledge availability, execution determinism, telemetry trust, governance, security, cost, and delivery risk. The right intervention may be internal hiring, distributed team design, nearshore pods, offshore delivery, platform investment, AI-assisted workflows, vendor consolidation, process redesign, or no capacity expansion until bottlenecks are resolved. ### This Artifact Is Not - staffing landing page - nearshore sales page - vendor recommendation - location thesis - outsourcing funnel ## Core Thesis 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. ## System Model Formula `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. ### Terms - C: Capacity intelligence - T: Distributed capacity topology - K: Knowledge and architecture memory - D: Execution determinism - O: Observability and telemetry - A: Agentic action - L: Learning and adaptive control loops - G: Governance ### Outcomes - speed - quality - cost - risk - business_value ## Audience Paths ### CTO - capacity constraints - architecture ownership - delivery speed and quality - AI-assisted SDLC readiness - work allocation decisions ### CIO - governance - security - auditability - vendor and policy risk - cost and data exposure boundaries ### VP Engineering - team topology - review queues - execution consistency - CI/CD variance - distributed delivery flow ### Platform Leader - paved roads - service ownership - developer experience bottlenecks - execution harness readiness ### DevOps Leader - pipeline determinism - deployment reproducibility - environment controls - rollback readiness ### AI Governance Leader - agent tool permissions - retrieval boundaries - human approval gates - audit and rollback controls ## Use Case Paths - Build or revise a distributed capacity strategy. - Decide what work should remain internal, external, distributed, or AI-assisted. - Diagnose whether engineering bottlenecks are caused by capacity, execution, knowledge, telemetry, or governance. - Assess whether agentic SDLC workflows are safe to introduce. - Evaluate whether the system can absorb more capacity before adding headcount or partners. ## Seven Primary Operating Layers A primary operating layer is a part of the engineering system that can be measured, governed, and changed to alter delivery behavior. ### Capacity Intelligence Schema node: `capacity_intelligence` Notation: `C` Definition: Models usable engineering capacity after cognitive load, role fit, review constraints, interruptions, skill distribution, decision latency, and organizational bottlenecks are accounted for. Purpose: - Move beyond headcount. - Identify real available capacity. - Distinguish staffing problems from system bottlenecks. - Prevent leaders from adding capacity into an unabsorbable system. Key question: How much usable engineering capacity exists after load, constraints, and fit are accounted for? Evidence examples: - active WIP - review queue age - incident interruption load - role-to-work fit - decision wait time Related diagnostic report: Capacity Constraint Map ### Distributed Capacity Topology Schema node: `distributed_capacity_topology` Notation: `T` Definition: Defines how engineering work is allocated across internal teams, external partners, contractors, global talent, platform teams, and AI agents based on skill fit, ownership, time-zone overlap, knowledge requirements, security boundaries, governance, and delivery risk. Purpose: - Make the model location-agnostic. - Treat internal hiring, external partners, nearshore, offshore, platform investment, and AI agents as topology choices. - Determine where work should live based on evidence. - Clarify ownership and access boundaries. Key question: Which capacity topology best fits the work, risk, knowledge, governance, and performance requirements of the engineering system? Evidence examples: - workstream complexity - ownership requirements - time-zone overlap - security boundary - ramp curve Related diagnostic report: Capacity Topology Readiness Report ### Knowledge and Architecture Memory Schema node: `knowledge_architecture_memory` Notation: `K` Definition: Captures codebase context, architecture decisions, product intent, service ownership, runbooks, incidents, standards, constraints, and domain knowledge so distributed humans and AI agents can act safely. Purpose: - Reduce tribal knowledge dependency. - Improve onboarding speed. - Make distributed execution safer. - Improve AI-agent context quality. Key question: Does the engineering system have enough explicit knowledge for distributed contributors and AI agents to make safe, high-quality decisions? Evidence examples: - ADRs - service ownership maps - runbooks - incident reviews - documentation freshness Related diagnostic report: Knowledge and Architecture Memory Report ### Execution Harness / SDLC Control Plane Schema node: `execution_harness` Notation: `D` Definition: The deterministic SDLC control plane that governs how work moves from idea to production through CI/CD, workflow rules, deployment pipelines, quality gates, environment controls, review paths, and release processes. Purpose: - Standardize execution. - Reduce pipeline variance. - Make distributed delivery reproducible. - Make AI-assisted work governable. Key question: How consistently does the SDLC produce reproducible outcomes across teams, services, locations, partners, and agentic workflows? Evidence examples: - pipeline templates - deployment success rate - manual overrides - rollback records - environment drift Related diagnostic report: Execution Determinism Report ### Decision-Grade Engineering Telemetry Schema node: `decision_grade_telemetry` Notation: `O` Definition: Identifies which engineering signals are trusted enough to guide operating decisions about capacity, execution, quality, risk, cost, and system degradation. Purpose: - Separate decision-grade signals from dashboard noise. - Detect degradation. - Compare capacity topology performance. - Govern AI-assisted workflows. Key question: Which engineering signals are trusted enough to govern the system? Evidence examples: - cycle-time distribution - queue time - change failure rate - review latency - quality drift Related diagnostic report: Engineering Capacity OS Diagnostic ### Governed Agentic SDLC Schema node: `governed_agentic_sdlc` Notation: `A` Definition: Coordinates AI-assisted engineering workflows where agents execute bounded tasks under validation, approval, audit, security, and rollback constraints. Purpose: - Identify safe agent workflows. - Define human approval boundaries. - Prevent agents from amplifying rework. - Validate AI-generated engineering actions. Key question: Which engineering workflows can agents safely execute today, and under what human, technical, and governance constraints? Evidence examples: - agent tool calls - AI-generated PR outcomes - human override rate - approval boundary hits - rework signal Related diagnostic report: Agent Delegation Safety Matrix ### Governed Adaptive Control Loops Schema node: `governed_adaptive_control_loops` Notation: `L` Definition: Allows the engineering system to learn from telemetry, detect inefficiency, recommend workflow changes, and modify execution behavior only under explicit governance, approval, rollback, and audit constraints. Purpose: - Support adaptive workflow optimization. - Prevent recursive automation failures. - Ensure workflow modification is governed. - Keep learning loops reversible and auditable. Key question: Can the engineering system improve its own execution behavior based on evidence without creating uncontrolled automation risk? Evidence examples: - workflow rule changes - optimization experiments - post-change deltas - rollback triggers - audit records Related diagnostic report: Governed Adaptive Control Loop Review ## Cross-Cutting Constraints ### Governance, Security, Audit, and Rollback Schema node: `governance_security_audit_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. Executive question: Who has the authority to change the engineering system, how is that change validated, and how can it be reversed? ### Failure Mode Register Schema node: `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. Executive question: What breaks first when capacity, distribution, or automation increases? ### Cost, Value, and Risk Economics Schema node: `cost_value_risk_economics` Evaluation of tradeoffs across cost, quality, risk, speed, and business value instead of treating speed as the only performance dimension. Executive question: Which capacity topology produces the best balance of speed, quality, cost, risk, and business value? ## Capacity Topology Patterns ### Centralized internal engineering Schema node: `centralized_internal_engineering` Best when strategic IP, architecture authority, and high-context product work require tight internal ownership. Best-fit conditions: - clear internal ownership - direct architecture control - sensitive product context Risk indicators: - internal queues already saturated - specialists overloaded Required controls: - ownership map - review capacity - decision rights Evidence required before scaling: - capacity constraints - review queue age - architecture decision latency ### Distributed internal engineering Schema node: `distributed_internal_engineering` Best when internal teams can operate across locations with shared standards, documentation, and execution harnesses. Best-fit conditions: - strong documentation - clear service ownership - time-zone coordination rituals Risk indicators: - handoff latency - documentation drift Required controls: - operating agreements - shared CI/CD gates - decision rituals Evidence required before scaling: - cycle time by team - handoff delay - documentation freshness ### Contributor capacity model Schema node: `staff_augmentation` Best for bounded tasks where internal ownership, review, and architecture authority remain clear. Best-fit conditions: - clear task boundaries - available review capacity - low ownership ambiguity Risk indicators: - review queues saturated - ambiguous requirements Required controls: - access policy - review path - definition of done Evidence required before scaling: - PR correction rate - ramp time - review queue age ### External engineering partner Schema node: `external_partner` Best when a partner can own bounded outcomes under explicit governance, telemetry, and exit controls. Best-fit conditions: - bounded workstream - defined outcome - clear governance Risk indicators: - incentive mismatch - weak exit path Required controls: - operating agreement - telemetry baseline - exit plan Evidence required before scaling: - delivery outcomes - quality metrics - access audit ### Nearshore pod Schema node: `nearshore_pod` Best when collaboration overlap matters and work can be distributed with clear ownership, test coverage, and access boundaries. Best-fit conditions: - collaboration overlap needed - documentation sufficient - review authority available Risk indicators: - tribal architecture knowledge - unclear production access Required controls: - service ownership map - access policy - CI/CD gates - exit plan Evidence required before scaling: - cycle time by work type - review age - deployment success - documentation completeness ### Offshore pod Schema node: `offshore_pod` Best for well-specified work with low synchronous decision dependency and mature execution controls. Best-fit conditions: - low ambiguity - strong async documentation - clear acceptance tests Risk indicators: - decision latency tolerance low - incident response needs high Required controls: - async rituals - test gates - handoff rules Evidence required before scaling: - handoff delay - blocked time - test reliability ### Managed vendor team Schema node: `managed_vendor_team` Best when a bounded capability can be delegated with service-level evidence, auditability, and reversible ownership. Best-fit conditions: - clear outcome boundary - vendor governance mature - performance telemetry exists Risk indicators: - opaque delivery - unclear IP provenance Required controls: - audit rights - IP controls - service continuity plan Evidence required before scaling: - SLOs - defect rate - exception logs - provenance records ### Platform-led capacity model Schema node: `platform_led_capacity` Best when bottlenecks are caused by tooling, paved roads, CI/CD variance, and developer experience constraints. Best-fit conditions: - many teams blocked by same platform gap - high manual toil Risk indicators: - platform roadmap detached from product needs Required controls: - platform telemetry - service catalog - standard templates Evidence required before scaling: - developer wait time - pipeline variance - manual intervention ### Build-operate-transfer Schema node: `build_operate_transfer` Best when an external group can establish a capability and transfer ownership after knowledge, controls, and evidence mature. Best-fit conditions: - defined transfer target - knowledge plan - governance plan Risk indicators: - transfer criteria vague - documentation weak Required controls: - transfer checklist - ownership map - access revocation plan Evidence required before scaling: - knowledge completeness - ownership readiness - exit plan ### AI-assisted internal team Schema node: `ai_assisted_internal_team` Best when internal teams retain judgment while agents reduce documentation, test generation, review preparation, or workflow routing costs. Best-fit conditions: - strong validation - clear tool policy - human ownership Risk indicators: - AI rework invisible - prompt policy unclear Required controls: - approved tools - audit logs - human gates Evidence required before scaling: - agent tool calls - correction rate - failed validations ### AI-assisted external team Schema node: `ai_assisted_external_team` Best when external contributors use approved AI under strict retrieval, access, audit, and validation controls. Best-fit conditions: - approved tools by contributor class - safe retrieval index - clear review authority Risk indicators: - data exposure risk - unverified PR provenance Required controls: - AI policy - retrieval boundary - audit requirements Evidence required before scaling: - tool usage logs - PR provenance - access classes ### Human-agent hybrid delivery system Schema node: `human_agent_hybrid_delivery` Best when humans and agents operate as one controlled delivery system with explicit approval, telemetry, and rollback boundaries. Best-fit conditions: - bounded agent actions - decision-grade telemetry - rollback ready Risk indicators: - recursive automation - weak stop conditions Required controls: - agent action policy - stop conditions - rollback authority Evidence required before scaling: - human override rate - quality drift - policy exceptions ## Capacity Topology Readiness Scorecard ### Capacity Reality Schema node: `capacity_reality` Whether usable capacity is known beyond headcount. ### Topology Fit Schema node: `topology_fit` Whether work allocation fits skill, ownership, time-zone, risk, and knowledge needs. ### Knowledge Transfer Readiness Schema node: `knowledge_transfer_readiness` Whether context can move without tribal bottlenecks. ### Execution Determinism Schema node: `execution_determinism` Whether CI/CD and SDLC flows are standardized and reproducible. ### Telemetry Trust Schema node: `telemetry_trust` Whether metrics are good enough for operating decisions. ### Agent Delegation Safety Schema node: `agent_delegation_safety` Whether AI workflows can be bounded, validated, audited, and reversed. ### Governance Completeness Schema node: `governance_completeness` Whether access, approval, audit, security, and rollback are controlled. ### Upside Potential Schema node: `upside_potential` Whether the system can compound productivity gains safely. ### Readiness Classifications - not_ready_to_scale_capacity - ready_for_internal_process_repair_only - ready_for_bounded_contributor_capacity - ready_for_distributed_team_execution - ready_for_external_partner_or_pod_ownership - ready_for_ai_assisted_distributed_delivery - ready_for_governed_adaptive_optimization ## Private Engineering Evidence Model Engineering Capacity OS diagnostics are designed to run inside the organization's own environment using approved MCP-connected systems, aggregate exports, metadata, summaries, or redacted evidence packs. Privacy boundary: Use aggregate metadata, summaries, and redacted examples only. Do not expose source code, secrets, customer data, raw logs, private messages, HR records, or individual employee performance data. ### Evidence Classes - observed: Directly measured by an approved source system. - modeled: Inferred from multiple signals. - directional: Weak but useful trend evidence. - unknown: Insufficient evidence. ### Workflow 1. select: Choose one operating decision and the smallest relevant analysis boundary. 2. constrain: Set privacy, source, time-window, aggregation, and redaction boundaries before retrieval. 3. retrieve: Use approved MCP-connected systems or aggregate exports for summarized evidence only. 4. classify: Mark evidence as observed, modeled, directional, or unknown. 5. analyze: Map evidence to capacity, topology, knowledge, execution, telemetry, agentic, adaptive-loop, and governance layers. 6. report: Produce an internal diagnostic report with confidence tier, gaps, risks, and one safe next action. ### Recommended Source Categories - Jira / Linear / Azure DevOps - GitHub / GitLab / Bitbucket - CI/CD systems - deployment systems - pull requests and review queues - incident systems - observability dashboards - architecture documentation - runbooks - service ownership maps - agent tool-call logs - calendar or collaboration metadata only if approved and aggregated ### If There Is No MCP Server 1. export: Pull aggregate snapshots from work tracking, source control, CI/CD, incident, review, deployment, documentation, and agent systems. 2. redact: Remove secrets, customer identifiers, raw source code, private logs, HR records, personal details, and sensitive proprietary records. 3. summarize: Convert exports into counts, distributions, time windows, queue ages, failure rates, and short redacted examples. 4. analyze: Paste the evidence pack and AI Diagnostic Protocol into an LLM approved for internal analysis. 5. validate: Treat the output as a hypothesis until a leader checks source systems, confidence, and missing instrumentation. ## Manual Evidence Pack Title: Engineering Capacity OS Manual Evidence Pack ### Operating Decision Examples - Should we add more engineers or fix bottlenecks first? - Which workstreams can be distributed safely? - Which work should remain internal? - Which workflows can be AI-assisted? - Is our engineering system ready to absorb external capacity? - Is our telemetry good enough to govern distributed delivery? ### Aggregate Evidence Fields - work-in-progress counts - cycle time distribution - review queue age - review correction rate - CI/CD pass rate - deployment frequency - rollback or failure events - incident interruption load - architecture documentation status - service ownership clarity - runbook completeness - onboarding duration - agent tool-call count - agent-generated PR outcomes - human approval events - policy exceptions - access exceptions - external contributor access classes ## AI Diagnostic Protocol Use the downloadable AI Diagnostic Protocol when an approved AI agent should analyze aggregate MCP evidence or a redacted evidence pack. The protocol tells the agent not to assume the answer is hiring, nearshore, offshore, outsourcing, insourcing, vendor replacement, AI automation, or platform investment. It evaluates evidence first. Protocol route: https://engineering.teamstation.dev/api/research/engineering-operating-system.skill.md ## Report Templates ### Engineering Capacity OS Diagnostic Schema node: `engineering_capacity_os_diagnostic` Use for: Broad operating assessment. Includes: - operating decision - included teams/services - time window - current capacity topology - capacity findings - knowledge readiness findings - execution harness findings - telemetry trust findings - agentic SDLC readiness - adaptive control-loop readiness - governance/security/IP findings - failure mode register - scorecard results - confidence tiers - safe next actions ### Capacity Topology Readiness Report Schema node: `capacity_topology_readiness_report` Use for: Deciding where work should live. Includes: - current topology - candidate topology options - workstream allocation map - internal ownership requirements - external/distributed ownership candidates - AI-assisted workflow candidates - required controls - risks - exit paths - recommendation with confidence ### Knowledge and Architecture Memory Report Schema node: `knowledge_architecture_memory_report` Use for: Evaluating distributed or AI-assisted readiness. Includes: - architecture documentation status - service ownership maps - tribal knowledge risk - runbook maturity - incident memory - documentation drift - AI retrieval safety - onboarding readiness - recommended knowledge interventions ### Execution Determinism Report Schema node: `execution_determinism_report` Use for: Evaluating whether the SDLC can absorb more capacity. Includes: - pipeline standardization - manual overrides - deployment reproducibility - review queue health - environment drift - failure concentration - governance gaps - scaling risks ### Agent Delegation Safety Matrix Schema node: `agent_delegation_safety_matrix` Use for: Deciding which workflows agents can safely support. Includes: - safe now - human-gated - unsafe - insufficiently instrumented - validation method - approval requirement - rollback path - audit evidence - data exposure risk - blast radius ### Governance, Security, and IP Control Report Schema node: `governance_security_ip_control_report` Use for: CIO, security, and executive governance concerns. Includes: - access boundaries - vendor/partner access - agent tool permissions - IP provenance - policy exceptions - audit completeness - production approval controls - rollback authority - data exposure risks - exit readiness ## Research Participation Model The model is validated from leader-controlled evidence only: internal MCP analysis, redacted aggregate evidence packs, structured interview notes, anonymized pattern submissions, or benchmark packets using non-sensitive operating metrics. ### Evidence Source Model - Internal MCP: the leader runs the questions inside their own environment and keeps raw evidence private. - Manual evidence pack: the leader exports aggregate counts, distributions, time windows, queue ages, and redacted examples. - Structured interview: the leader describes the operating decision, current topology, constraints, and missing telemetry. - Anonymized pattern: the leader contributes a generalized capacity, governance, telemetry, or agentic SDLC pattern with identifiers removed. - Benchmark packet: only aggregate, non-sensitive measures are compared across participating organizations. Participation does not require exposing source code, secrets, customer data, employee-level performance data, raw logs, or proprietary engineering records. Leaders can use aggregate metrics, redacted examples, or private MCP-connected evidence inside their own environment. ### Privacy Commitment - No source code required. - No secrets required. - No customer data required. - No raw logs required. - No employee-level performance data required. - Aggregate metrics and redacted examples are sufficient. ### Participation Modes - Use the public diagnostic internally (`use_public_diagnostic`) - Submit anonymized feedback on the model (`submit_anonymized_feedback`) - Join a structured research interview (`join_research_interview`) - Contribute an anonymized capacity or governance pattern (`contribute_anonymized_pattern`) - Join a benchmark cohort using aggregate, non-sensitive evidence (`join_benchmark_cohort`) ## Question Bank Overview Total questions: 60 ### Capacity Intelligence Schema node: `capacity_intelligence` Questions: 8 - [capacity-001] How much usable engineering capacity exists after cognitive load, review load, interruptions, and role fit are accounted for? - [capacity-002] Which roles or decision points create the current capacity constraint? - [capacity-003] What percentage of capacity is lost to context switching and fragmented ownership? - [capacity-004] Which work types consume scarce senior review or architecture capacity? - [capacity-005] Is the engineering system ready to absorb additional contributors without increasing queue time? - [capacity-006] What capacity is blocked by missing decisions rather than missing people? - [capacity-007] Which skills are scarce enough to determine capacity topology decisions? - [capacity-008] Which capacity constraints should be repaired before any sourcing, hiring, or automation decision is made? ### Distributed Capacity Topology Schema node: `distributed_capacity_topology` Questions: 10 - [topology-001] Which engineering workstreams are safest to distribute beyond the current core team? - [topology-002] Which workstreams should remain internally owned? - [topology-003] Which capacity topology best matches each workstream? - [topology-004] Where does time-zone overlap materially affect cycle time? - [topology-005] What review capacity must exist before adding distributed contributors? - [topology-006] Which systems or services are ready for external or distributed ownership? - [topology-007] What access should each contributor type have? - [topology-008] What is the ramp curve from onboarding to independent contribution? - [topology-009] Which communication rituals reduce decision latency? - [topology-010] What is the exit path if a capacity topology underperforms? ### Knowledge and Architecture Memory Schema node: `knowledge_architecture_memory` Questions: 8 - [knowledge-001] Which parts of the engineering system depend on tribal knowledge? - [knowledge-002] How current are architecture decision records? - [knowledge-003] Which services have clear ownership maps? - [knowledge-004] What knowledge must a contributor have before production-impacting work? - [knowledge-005] Which knowledge sources are safe for AI retrieval? - [knowledge-006] Where does documentation drift create delivery risk? - [knowledge-007] How are incidents converted into durable system memory? - [knowledge-008] What evidence proves a distributed contributor is ready for ownership? ### Execution Harness / SDLC Control Plane Schema node: `execution_harness` Questions: 10 - [execution-001] How standardized are CI/CD pipelines across teams, services, and contributor types? - [execution-002] Where does execution variance enter the delivery system? - [execution-003] Which SDLC controls are system-enforced versus manually enforced? - [execution-004] How reproducible are production deployments across services? - [execution-005] Where do pipeline failures originate most frequently? - [execution-006] Who defines and changes execution rules in the SDLC? - [execution-007] How are workflow standards propagated across teams? - [execution-008] What is the cost of pipeline inconsistency? - [execution-009] Which execution paths are safe for AI-assisted or external contributors? - [execution-010] What breaks in execution when delivery volume increases? ### Decision-Grade Engineering Telemetry Schema node: `decision_grade_telemetry` Questions: 8 - [telemetry-001] Which engineering signals are trusted enough to govern capacity topology decisions? - [telemetry-002] Which signals correlate with delivery success rather than activity volume? - [telemetry-003] How real-time is delivery visibility for leaders? - [telemetry-004] Where are queues invisible to current dashboards? - [telemetry-005] Which telemetry detects quality degradation after capacity, topology, or AI changes? - [telemetry-006] What telemetry compares topology performance without exposing individual employee data? - [telemetry-007] Which metrics should trigger governance review before scaling automation? - [telemetry-008] Which signals are missing but necessary for the next operating decision? ### Governed Agentic SDLC Schema node: `governed_agentic_sdlc` Questions: 6 - [agent-001] Which agentic workflows reduce onboarding time for distributed contributors? - [agent-002] Which AI-generated outputs can distributed teams safely validate? - [agent-003] Which AI tools are allowed for each contributor type? - [agent-004] How are AI-generated PRs reviewed across distributed teams? - [agent-005] What telemetry detects agent-generated rework? - [agent-006] Which workflows should remain human-gated until trust improves? ### Governed Adaptive Control Loops Schema node: `governed_adaptive_control_loops` Questions: 4 - [adaptive-001] Can the engineering system recommend workflow changes from telemetry without automatically applying them? - [adaptive-002] Which workflow rules can be safely modified under governance? - [adaptive-003] How does the system detect when adaptive changes degrade performance? - [adaptive-004] Who can approve, audit, and reverse adaptive changes to the SDLC? ### Governance, Security, and Failure Modes Schema node: `governance_security_failure_modes` Questions: 6 - [gov-001] Who owns delivery risk for externally or agent-produced work? - [gov-002] Which production actions require internal approval? - [gov-003] Which systems are off-limits to external contributors or agents? - [gov-004] How is IP assignment and contribution provenance verified? - [gov-005] How are policy exceptions logged and reviewed? - [gov-006] What breaks first when capacity, distribution, or automation increases? ## LLM Prompt Templates ### Engineering Capacity OS Diagnostic ```text Using only approved internal MCP-accessible aggregate data or a redacted evidence pack, generate an Engineering Capacity OS diagnostic for the last 90 days. Do not assume the answer is hiring, nearshore, offshore, outsourcing, insourcing, platform investment, vendor replacement, or AI automation. Evaluate evidence first. Map findings to capacity_intelligence, distributed_capacity_topology, knowledge_architecture_memory, execution_harness, decision_grade_telemetry, governed_agentic_sdlc, governed_adaptive_control_loops, and governance_security_failure_modes. For each finding include evidence class, source system, time window, confidence tier, operational risk, missing evidence, and one safe next action. Do not expose source code, secrets, customer data, raw logs, private messages, or individual employee performance data. ``` ### Capacity Topology Readiness ```text Analyze which capacity topology best fits the selected workstreams. Compare internal ownership, distributed internal teams, contributor capacity, external partners, nearshore pods, offshore pods, platform investment, AI-assisted workflows, and human-agent hybrid delivery. Use aggregate evidence only. Return readiness scorecard results, required controls, risk flags, exit paths, confidence tier, and the safest next action. ``` ### Agent Delegation Safety ```text Analyze which SDLC workflows can be safely delegated to agents today. Use aggregate signals for PR outcomes, review latency, CI/CD failures, rollback events, tool-call logs, approval records, and incident correlation. Classify each workflow as safe_now, human_gated, unsafe, or insufficiently_instrumented. Explain validation method, approval requirement, rollback path, audit evidence, data exposure risk, blast radius, and missing controls. ``` ## Machine-Readable Artifact Index - Human page: https://engineering.teamstation.dev/research/engineering-operating-system - Canonical Markdown: https://engineering.teamstation.dev/api/research/engineering-operating-system.md - Machine-readable JSON: https://engineering.teamstation.dev/api/research/engineering-operating-system - Static JSON mirror: https://engineering.teamstation.dev/api/research/engineering-operating-system.json - Question bank JSON: https://engineering.teamstation.dev/api/research/questions.json - Question bank Markdown: https://engineering.teamstation.dev/api/research/questions.md - Question API: https://engineering.teamstation.dev/api/research/questions - AI Diagnostic Protocol: https://engineering.teamstation.dev/api/research/engineering-operating-system.skill.md - OpenAPI: https://engineering.teamstation.dev/openapi.json ## Objective Engineering Capacity OS is a location-agnostic research model for leaders deciding how to scale engineering capacity in the AI-assisted SDLC era. It does not assume the answer is hiring, outsourcing, nearshore, offshore, platform investment, or AI automation. It helps CTOs, CIOs, and VPs of Engineering evaluate operating evidence, identify constraints, and choose the safest capacity topology for speed, quality, cost, risk, and business value. ## Answer Card System The answer card turns each CTO research question into a private, evidence-bound diagnostic object. The public site supplies the question, doctrine answer, evidence requirements, confidence rubric, and report shape. The customer answer is generated inside the organization's own MCP environment or from a redacted manual evidence pack. The public site answers the doctrine part of each question: what a valid answer must prove, what evidence is acceptable, what confidence means, and what report should receive the answer. The customer's actual state is answered only inside the customer's approved environment. ### Public Answer Boundary The public answer is doctrine guidance. It explains what a valid answer must prove. It does not guess the customer's internal state. Real answers require private Jira, Linear, GitHub, GitLab, CI/CD, incident, architecture, review, telemetry, policy, and access data. That data should stay inside the organization boundary. ### Answer Card Fields - question_id: Stable identifier from the question bank. - domain: Research domain that owns the question. - question: Atomic CTO question being answered. - doctrine_answer: Public baseline answer from the Engineering Capacity OS model. - evidence_summary: Aggregate, redacted summary of what the internal evidence shows. - observed_state: observed, modeled, directional, or unknown. - confidence: high, medium, directional, or unknown. - source_classes: Approved source categories used, never raw sensitive records. - missing_evidence: Evidence needed before the answer can be treated as reliable. - risk_flags: System risks surfaced by the answer. - recommended_report_section: Report section where the answer belongs. - next_safe_action: One reversible action or measurement step. - do_not_collect: Sensitive data classes that should not be exported. ### Answer Workflow - Select question: Choose one operating decision and one question. Do not run the whole bank when the leader needs a specific decision. - Constrain evidence: Define source systems, time window, aggregation level, redaction rules, and data classes that must not leave the organization. - Retrieve aggregate signals: Use MCP or exports to retrieve counts, distributions, metadata, examples, and summaries rather than raw source code, secrets, logs, or employee records. - Map to doctrine answer: Compare the evidence to the Engineering Capacity OS doctrine answer and identify whether the question is observed, modeled, directional, or unknown. - Write answer card: Produce one answer card with confidence, risk flags, missing evidence, report section, and one next safe action. - Validate with the owner: A human system owner checks the source classes, assumptions, confidence tier, missing evidence, and action boundary before the answer is used. ### Synthetic Example Answer Card ```json { "question_id": "topology-005", "domain": "distributed_capacity_topology", "question": "What review capacity must exist before adding distributed contributors?", "doctrine_answer": "Additional contributors increase throughput only when review capacity, architecture authority, and approval paths can absorb the added work. If review is the constraint, more contributors create more queue time.", "evidence_summary": "Synthetic example: PR review queue age is above 36 hours for platform services, correction rate is rising, and reviewer availability is concentrated in two senior engineers.", "observed_state": "directional", "confidence": "medium", "source_classes": [ "pull request metadata", "review queue age", "service ownership map", "deployment metadata" ], "missing_evidence": [ "reviewer calendar load", "architecture decision latency", "post-merge defect trend" ], "risk_flags": [ "review_bottleneck", "architecture_authority_constraint" ], "recommended_report_section": "Capacity Topology Readiness Report", "next_safe_action": "Measure reviewer availability, PR correction rate, approval latency, and service ownership coverage for 30 days before adding distributed contributors.", "do_not_collect": [ "source code", "secrets", "customer data", "raw private messages", "individual employee performance records" ] } ``` ## Workflow Report System The report system converts answer cards into executive operating reports. A report should tell a CTO, CIO, or VP Engineering what the system is doing, what evidence supports that view, where confidence is weak, and what can be changed safely. ### Required Report Sections - Operating decision - Evidence boundary - Answer cards - System diagnosis - Confidence table - Missing instrumentation - Risk register - Recommended next safe actions - Human approval and rollback boundary ### Report Types #### Engineering Capacity OS Diagnostic Executive view of capacity, topology, telemetry, governance, and AI readiness. Primary domains: - capacity_intelligence - decision_grade_telemetry - governance_security_failure_modes Output questions: - What is the actual constraint? - What evidence supports that conclusion? - Can the system absorb more capacity? - Where is instrumentation missing? #### Capacity Topology Readiness Report Decision support for internal hiring, distributed teams, external partners, nearshore, offshore, platform investment, or agentic workflows. Primary domains: - distributed_capacity_topology - knowledge_architecture_memory - execution_harness Output questions: - Which workstreams are distributable? - Which workstreams should remain internally owned? - What controls must exist before the topology changes? - Where would the model create hidden risk? #### Agentic SDLC Readiness Report Assessment of which engineering workflows can be safely delegated to agents. Primary domains: - governed_agentic_sdlc - governed_adaptive_control_loops - governance_security_failure_modes Output questions: - Which tasks are safe for agent assistance? - Where is human judgment still required? - What telemetry proves agents are helping? - What approval, audit, and rollback controls are required? #### Execution Control Plane Report Review of CI/CD, deployment, environment, rollback, quality-gate, and workflow determinism. Primary domains: - execution_harness - decision_grade_telemetry - governance_security_failure_modes Output questions: - Where does execution variance enter the SDLC? - Which controls are manually enforced? - Which controls are system-enforced? - How reproducible are deployments across environments?