# Engineering Capacity OS Diagnostic Protocol

Version: 3.0

## Purpose

Help an approved AI agent run a location-agnostic diagnostic of engineering capacity, topology, knowledge readiness, execution determinism, telemetry trust, agentic SDLC safety, adaptive control-loop readiness, and governance completeness.

The protocol must evaluate evidence before recommending any intervention.

## Do Not Assume

- Hiring.
- Nearshore.
- Offshore.
- Outsourcing.
- Insourcing.
- Vendor replacement.
- AI automation.
- Platform investment.

Treat each as a capacity topology option that must be tested against operating evidence.

## Privacy Boundary

Never request source code, secrets, customer data, raw logs, HR records, private messages, or individual employee performance data. Use aggregate metrics, metadata, summaries, redacted examples, and approved internal MCP signals only.

## Diagnostic Sequence

1. Capture the leader's operating decision.
2. Define the analysis boundary: time window, teams, services, excluded systems, source permissions, and privacy constraints.
3. Identify the current capacity topology.
4. Retrieve or request aggregate evidence only.
5. Classify evidence as observed, modeled, directional, or unknown.
6. Score readiness dimensions.
7. Identify bottlenecks.
8. Identify topology options.
9. Identify governance, security, IP, and failure-mode risks.
10. Recommend the safest next action.
11. Mark confidence and missing evidence.
12. Avoid asking for sensitive 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.

## Readiness Dimensions

- Capacity Reality: Whether usable capacity is known beyond headcount.
- Topology Fit: Whether work allocation fits skill, ownership, time-zone, risk, and knowledge needs.
- Knowledge Transfer Readiness: Whether context can move without tribal bottlenecks.
- Execution Determinism: Whether CI/CD and SDLC flows are standardized and reproducible.
- Telemetry Trust: Whether metrics are good enough for operating decisions.
- Agent Delegation Safety: Whether AI workflows can be bounded, validated, audited, and reversed.
- Governance Completeness: Whether access, approval, audit, security, and rollback are controlled.
- Upside Potential: Whether the system can compound productivity gains safely.

## Required Report Shape

```json
{
  "operating_decision": "",
  "analysis_boundary": {
    "time_window": "",
    "included_teams_or_services": [],
    "excluded_systems": [],
    "privacy_boundary": "aggregate and redacted evidence only"
  },
  "current_capacity_topology": "",
  "evidence_summary": [],
  "readiness_scorecard": [],
  "bottlenecks": [],
  "topology_options": [],
  "governance_security_ip_risks": [],
  "failure_modes": [],
  "confidence_tier": "observed | modeled | directional | unknown",
  "missing_evidence": [],
  "safest_next_action": ""
}
```

## Prompt Template

```text
Using only approved internal MCP-accessible aggregate data or a redacted evidence pack, generate an Engineering Capacity OS diagnostic. Do not assume the answer is hiring, nearshore, offshore, outsourcing, insourcing, vendor replacement, AI automation, or platform investment. 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.
```