{ "title": "US CTO/CIO Engineering Capacity OS Learning Cards", "version": "1.0", "schema_version": "learning-card-schema-v1", "status": "public_research_learning_artifact", "generated_from_question_count": 60, "generated_from_formula_count": 25, "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader", "AI Governance Leader" ], "purpose": "Convert Engineering Capacity OS research into machine readable learning cards for LLM retrieval, MCP use, and internal leadership diagnostics. The cards teach the model how to ask for evidence, apply formulas, produce answer cards, and keep private engineering data inside the organization boundary.", "non_goals": [ "vendor recommendation", "staffing funnel", "public customer diagnosis", "private data collection", "replacement for internal engineering judgment" ], "privacy_boundary": "The public cards define questions, evidence classes, formulas, answer shape, and report mapping for the TeamStation AI distributed engineering operating system research layer. Private engineering evidence stays inside the organization controlled MCP server or approved internal LLM workspace.", "source_artifacts": [ "/api/research/questions.json", "/api/research/formulas.json", "/api/research/answer-card-schema.json", "/api/research/workflow-report-system.json", "/api/research/engineering-capacity-paper/paper.md" ], "usage": { "no_mcp_path": "Export aggregate counts, redacted examples, and non-sensitive summaries into an approved internal workspace, then run the same safe prompt templates.", "mcp_path": "Use the cards as retrieval instructions for an internal MCP server connected to work tracker, source control, CI/CD, incident, telemetry, architecture, and policy systems.", "output_promise": "Each card should produce an evidence bound answer card with observed state, confidence, missing evidence, risk flags, decision implication, and next safe action.", "leader_value": "US CTOs and CIOs get a repeatable way to diagnose engineering capacity with math, telemetry, and governance instead of vendor claims or unsupported headcount assumptions." }, "model_cards": [ { "id": "model-card-engineering-performance-function", "title": "Engineering Performance Function", "audience": [ "US CTO", "US CIO", "VP Engineering" ], "purpose": "Explain the top level dependency model used by every Engineering Capacity OS diagnostic.", "formula": { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, "use": "Map a capacity concern to capacity, topology, knowledge, execution, telemetry, agentic action, adaptive loops, and governance before recommending an operating change.", "output": "Speed, quality, cost, risk, and value interpreted as system outputs, not staffing outputs." }, { "id": "model-card-answer-card-boundary", "title": "Answer Card Boundary", "audience": [ "US CTO", "US CIO", "Security Leader" ], "purpose": "Separate public doctrine guidance from private organization evidence.", "public_boundary": "The public answer is doctrine guidance. It explains what a valid answer must prove. It does not guess the customer's internal state.", "private_boundary": "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.", "output": "Evidence bound answer cards with confidence, gaps, risks, and next safe action." }, { "id": "model-card-workflow-report-system", "title": "Workflow Report System", "audience": [ "US CTO", "US CIO", "VP Engineering" ], "purpose": "Convert answer cards into leadership diagnostic reports without exposing private engineering data.", "report_system_title": "Workflow Report System", "output": "Executive summary, system map, evidence table, missing evidence, risk flags, and governance action." } ], "domain_index": { "capacity_intelligence": { "label": "Capacity Intelligence", "question_count": 8, "card_ids": [ "learning-card-capacity-001", "learning-card-capacity-002", "learning-card-capacity-003", "learning-card-capacity-004", "learning-card-capacity-005", "learning-card-capacity-006", "learning-card-capacity-007", "learning-card-capacity-008" ] }, "distributed_capacity_topology": { "label": "Distributed Capacity Topology", "question_count": 10, "card_ids": [ "learning-card-topology-001", "learning-card-topology-002", "learning-card-topology-003", "learning-card-topology-004", "learning-card-topology-005", "learning-card-topology-006", "learning-card-topology-007", "learning-card-topology-008", "learning-card-topology-009", "learning-card-topology-010" ] }, "knowledge_architecture_memory": { "label": "Knowledge Architecture and Memory", "question_count": 8, "card_ids": [ "learning-card-knowledge-001", "learning-card-knowledge-002", "learning-card-knowledge-003", "learning-card-knowledge-004", "learning-card-knowledge-005", "learning-card-knowledge-006", "learning-card-knowledge-007", "learning-card-knowledge-008" ] }, "execution_harness": { "label": "Execution Harness", "question_count": 10, "card_ids": [ "learning-card-execution-001", "learning-card-execution-002", "learning-card-execution-003", "learning-card-execution-004", "learning-card-execution-005", "learning-card-execution-006", "learning-card-execution-007", "learning-card-execution-008", "learning-card-execution-009", "learning-card-execution-010" ] }, "decision_grade_telemetry": { "label": "Decision Grade Telemetry", "question_count": 8, "card_ids": [ "learning-card-telemetry-001", "learning-card-telemetry-002", "learning-card-telemetry-003", "learning-card-telemetry-004", "learning-card-telemetry-005", "learning-card-telemetry-006", "learning-card-telemetry-007", "learning-card-telemetry-008" ] }, "governed_agentic_sdlc": { "label": "Governed Agentic SDLC", "question_count": 6, "card_ids": [ "learning-card-agent-001", "learning-card-agent-002", "learning-card-agent-003", "learning-card-agent-004", "learning-card-agent-005", "learning-card-agent-006" ] }, "governed_adaptive_control_loops": { "label": "Governed Adaptive Control Loops", "question_count": 4, "card_ids": [ "learning-card-adaptive-001", "learning-card-adaptive-002", "learning-card-adaptive-003", "learning-card-adaptive-004" ] }, "governance_security_failure_modes": { "label": "Governance, Security, and Failure Modes", "question_count": 6, "card_ids": [ "learning-card-gov-001", "learning-card-gov-002", "learning-card-gov-003", "learning-card-gov-004", "learning-card-gov-005", "learning-card-gov-006" ] } }, "learning_cards": [ { "id": "learning-card-capacity-001", "source_question_id": "capacity-001", "audience": [ "US CTO", "US CIO", "VP Engineering" ], "domain": "capacity_intelligence", "domain_label": "Capacity Intelligence", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#capacity_intelligence", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "capacity intelligence", "cognitive load", "review capacity", "capacity", "headcount", "cognitive-load", "available_capacity", "review_capacity", "role_fit" ], "decision_context": "Use when leaders need to know whether engineering capacity is real, usable, constrained, or only visible as headcount.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "kingman_wait_time", "label": "Kingman Wait Time Approximation", "formula": "E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau", "plain_language": "As utilization approaches 100 percent, wait time explodes. Variance makes the queue worse.", "diagnostic_use": "Use this to test whether a team is actually capacity constrained or queue constrained.", "required_signals": [ "utilization proxy", "active WIP", "queue age", "cycle time", "arrival variability", "service-time variability", "blocked work" ], "interpretation_rules": [ "If utilization is high and queue age is rising, adding more work will worsen delivery.", "If task-size variance is high, normalize work before scaling capacity.", "If queue data is missing, mark telemetry as insufficient for capacity decisions." ] }, { "formula_id": "engineering_throughput_equation", "label": "Engineering Throughput Equation", "formula": "Throughput = f(Topology, Cognitive Load, Coordination Cost, AI Assistance)", "plain_language": "Throughput is shaped by team topology, cognitive load, coordination cost, and bounded AI assistance, not headcount alone.", "diagnostic_use": "Use this as the bridge between doctrine math and the Engineering Capacity OS capacity topology questions.", "required_signals": [ "team topology", "active WIP", "context switching", "coordination delay", "agent usage", "cycle time", "quality signal" ], "interpretation_rules": [ "If throughput gains come with higher rework or risk, do not report a capacity improvement.", "If AI assistance lowers cognitive load and review drag, classify the workflow as promising but still governed.", "If topology and coordination cost are unknown, throughput claims are unsupported." ] } ], "evidence_to_request_from_internal_mcp": [ "Jira or Linear", "GitHub or GitLab", "incident system", "calendar metadata if approved and aggregated" ], "minimum_evidence": [ "active WIP", "completed work", "review queue age", "incident interruptions" ], "evidence_needed": [ "active WIP", "completed work", "review queue age", "incident interruptions" ], "validation_signal": "Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window.", "score_dimensions": [ "Capacity Reality", "Telemetry Trust" ], "metrics_signals": [ "active WIP", "completed work", "review queue age", "incident interruptions", "Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window.", "Capacity Reality", "Telemetry Trust" ], "risk_flags": [ "hidden_capacity_loss", "review_bottleneck" ], "governance_risk": [ "hidden_capacity_loss", "review_bottleneck" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "good_answer_pattern": "A strong answer directly answers: \"How much usable engineering capacity exists after cognitive load, review load, interruptions, and role fit are accounted for?\" Validation method: Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with Jira or Linear, GitHub or GitLab, incident system, and related approved sources. It misses the operating risk: Headcount does not represent usable capacity when the system loses time to queues, incidents, meetings, or poor work fit.", "answer_card_output": { "answer_type": "capacity_constraint_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window.", "Evidence from Jira or Linear, GitHub or GitLab, incident system, calendar metadata if approved and aggregated.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Engineering Capacity OS Diagnostic." ], "common_failure_modes": [ "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with Jira or Linear, GitHub or GitLab, incident system, and related approved sources. It misses the operating risk: Headcount does not represent usable capacity when the system loses time to queues, incidents, meetings, or poor work fit.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Engineering Capacity OS Diagnostic" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer capacity-001: \"How much usable engineering capacity exists after cognitive load, review load, interruptions, and role fit are accounted for?\"\nUse only aggregate, redacted, or metadata level evidence from: Jira or Linear, GitHub or GitLab, incident system, calendar metadata if approved and aggregated.\nMinimum evidence to check: active WIP, completed work, review queue age, incident interruptions.\nUse these public model references if relevant: engineering_performance_function, kingman_wait_time, engineering_throughput_equation.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-capacity-002", "source_question_id": "capacity-002", "audience": [ "US CTO", "US CIO", "VP Engineering" ], "domain": "capacity_intelligence", "domain_label": "Capacity Intelligence", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#capacity_intelligence", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "capacity intelligence", "cognitive load", "review capacity", "constraints", "roles", "decision-latency", "bottleneck_role", "decision_authority" ], "decision_context": "Use when leaders need to know whether engineering capacity is real, usable, constrained, or only visible as headcount.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "pull request system", "architecture decision records", "approval workflow" ], "minimum_evidence": [ "queue by role", "approval latency", "reviewer availability", "decision age" ], "evidence_needed": [ "queue by role", "approval latency", "reviewer availability", "decision age" ], "validation_signal": "Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency.", "score_dimensions": [ "Capacity Reality", "Execution Determinism" ], "metrics_signals": [ "queue by role", "approval latency", "reviewer availability", "decision age", "Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency.", "Capacity Reality", "Execution Determinism" ], "risk_flags": [ "decision_latency", "role_bottleneck" ], "governance_risk": [ "decision_latency", "role_bottleneck" ], "recommended_report_type": "Capacity Constraint Map", "good_answer_pattern": "A strong answer directly answers: \"Which roles or decision points create the current capacity constraint?\" Validation method: Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, pull request system, architecture decision records, and related approved sources. It misses the operating risk: Adding contributors does not help if the bottleneck is architecture review, product decision latency, release approval, or a specialized reviewer.", "answer_card_output": { "answer_type": "capacity_constraint_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency.", "Evidence from work tracker, pull request system, architecture decision records, approval workflow.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Constraint Map." ], "common_failure_modes": [ "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, pull request system, architecture decision records, and related approved sources. It misses the operating risk: Adding contributors does not help if the bottleneck is architecture review, product decision latency, release approval, or a specialized reviewer.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Constraint Map" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer capacity-002: \"Which roles or decision points create the current capacity constraint?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, pull request system, architecture decision records, approval workflow.\nMinimum evidence to check: queue by role, approval latency, reviewer availability, decision age.\nUse these public model references if relevant: sequential_probability_network.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-capacity-003", "source_question_id": "capacity-003", "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader" ], "domain": "capacity_intelligence", "domain_label": "Capacity Intelligence", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#capacity_intelligence", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "capacity intelligence", "cognitive load", "review capacity", "context-switching", "focus", "ownership", "cognitive_load", "work_fragmentation" ], "decision_context": "Use when leaders need to know whether engineering capacity is real, usable, constrained, or only visible as headcount.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "Context-switching loss is the share of available engineering time consumed by work transitions, interrupted tasks, handoffs, and fragmented ownership rather than completed flow.", "math_and_model_references": [ { "formula_id": "incentive_compatibility_constraint", "label": "Incentive Compatibility Constraint", "formula": "p_n * w_i - c >= zeta_i^x * w_i", "plain_language": "A contributor exerts effort when the expected value of working is greater than the expected value of shirking.", "diagnostic_use": "Use this as a qualitative operating model for effort, friction, unclear ownership, time-zone delay, and downstream safety nets.", "required_signals": [ "decision latency", "blocked time", "handoff delay", "context switching", "work ownership", "review accountability" ], "interpretation_rules": [ "If coordination cost is high, effort drops even when people are busy.", "If ownership is unclear, activity signals are not evidence of productive effort.", "If downstream teams constantly catch upstream issues, the incentive model is distorted." ] }, { "formula_id": "kingman_wait_time", "label": "Kingman Wait Time Approximation", "formula": "E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau", "plain_language": "As utilization approaches 100 percent, wait time explodes. Variance makes the queue worse.", "diagnostic_use": "Use this to test whether a team is actually capacity constrained or queue constrained.", "required_signals": [ "utilization proxy", "active WIP", "queue age", "cycle time", "arrival variability", "service-time variability", "blocked work" ], "interpretation_rules": [ "If utilization is high and queue age is rising, adding more work will worsen delivery.", "If task-size variance is high, normalize work before scaling capacity.", "If queue data is missing, mark telemetry as insufficient for capacity decisions." ] }, { "formula_id": "little_law", "label": "Little's Law", "formula": "L = lambda * W", "plain_language": "Average work in progress equals throughput multiplied by time in system.", "diagnostic_use": "Use this to show why more active work can increase lead time even when people look busy.", "required_signals": [ "active WIP", "throughput", "lead time", "cycle time", "work item aging" ], "interpretation_rules": [ "If WIP rises faster than throughput, lead time must rise.", "If throughput is flat and work starts increase, the system is manufacturing delay.", "If WIP is not measured, do not claim the team has usable spare capacity." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "incident system", "calendar metadata if approved and aggregated" ], "minimum_evidence": [ "active work per contributor", "handoff count", "interruption count", "cycle-time variance" ], "evidence_needed": [ "active work per contributor", "handoff count", "interruption count", "cycle-time variance" ], "validation_signal": "Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance.", "score_dimensions": [ "Capacity Reality", "Upside Potential" ], "metrics_signals": [ "active work per contributor", "handoff count", "interruption count", "cycle-time variance", "Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance.", "Capacity Reality", "Upside Potential" ], "risk_flags": [ "context_switching", "ownership_fragmentation" ], "governance_risk": [ "context_switching", "ownership_fragmentation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "good_answer_pattern": "A strong answer directly answers: \"What percentage of capacity is lost to context switching and fragmented ownership?\" Validation method: Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, incident system, calendar metadata if approved and aggregated. It misses the operating risk: Fragmented work creates apparent activity while reducing throughput, quality, and learning.", "answer_card_output": { "answer_type": "capacity_constraint_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance.", "Evidence from work tracker, incident system, calendar metadata if approved and aggregated.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Engineering Capacity OS Diagnostic." ], "common_failure_modes": [ "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, incident system, calendar metadata if approved and aggregated. It misses the operating risk: Fragmented work creates apparent activity while reducing throughput, quality, and learning.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Engineering Capacity OS Diagnostic" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer capacity-003: \"What percentage of capacity is lost to context switching and fragmented ownership?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, incident system, calendar metadata if approved and aggregated.\nMinimum evidence to check: active work per contributor, handoff count, interruption count, cycle-time variance.\nUse these public model references if relevant: incentive_compatibility_constraint, kingman_wait_time, little_law.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-capacity-004", "source_question_id": "capacity-004", "audience": [ "US CTO", "US CIO", "VP Engineering" ], "domain": "capacity_intelligence", "domain_label": "Capacity Intelligence", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#capacity_intelligence", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "capacity intelligence", "cognitive load", "review capacity", "review", "architecture", "capacity", "review_capacity", "architecture_authority" ], "decision_context": "Use when leaders need to know whether engineering capacity is real, usable, constrained, or only visible as headcount.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "strict_complementarity", "label": "Strict Complementarity", "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ] } ], "evidence_to_request_from_internal_mcp": [ "pull request system", "architecture reviews", "work tracker" ], "minimum_evidence": [ "review dependency", "review queue age", "rework rate", "senior reviewer load" ], "evidence_needed": [ "review dependency", "review queue age", "rework rate", "senior reviewer load" ], "validation_signal": "Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency.", "score_dimensions": [ "Capacity Reality", "Topology Fit" ], "metrics_signals": [ "review dependency", "review queue age", "rework rate", "senior reviewer load", "Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency.", "Capacity Reality", "Topology Fit" ], "risk_flags": [ "senior_review_saturation", "architecture_constraint" ], "governance_risk": [ "senior_review_saturation", "architecture_constraint" ], "recommended_report_type": "Capacity Topology Readiness Report", "good_answer_pattern": "A strong answer directly answers: \"Which work types consume scarce senior review or architecture capacity?\" Validation method: Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with pull request system, architecture reviews, work tracker. It misses the operating risk: Capacity expansion can overload senior reviewers and turn more contributors into slower delivery.", "answer_card_output": { "answer_type": "capacity_constraint_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency.", "Evidence from pull request system, architecture reviews, work tracker.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Topology Readiness Report." ], "common_failure_modes": [ "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with pull request system, architecture reviews, work tracker. It misses the operating risk: Capacity expansion can overload senior reviewers and turn more contributors into slower delivery.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Topology Readiness Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer capacity-004: \"Which work types consume scarce senior review or architecture capacity?\"\nUse only aggregate, redacted, or metadata level evidence from: pull request system, architecture reviews, work tracker.\nMinimum evidence to check: review dependency, review queue age, rework rate, senior reviewer load.\nUse these public model references if relevant: strict_complementarity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-capacity-005", "source_question_id": "capacity-005", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "capacity_intelligence", "domain_label": "Capacity Intelligence", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#capacity_intelligence", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "capacity intelligence", "cognitive load", "review capacity", "absorption", "scaling", "queue-time", "capacity_absorption", "onboarding" ], "decision_context": "Use when leaders need to know whether engineering capacity is real, usable, constrained, or only visible as headcount.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] }, { "formula_id": "kingman_wait_time", "label": "Kingman Wait Time Approximation", "formula": "E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau", "plain_language": "As utilization approaches 100 percent, wait time explodes. Variance makes the queue worse.", "diagnostic_use": "Use this to test whether a team is actually capacity constrained or queue constrained.", "required_signals": [ "utilization proxy", "active WIP", "queue age", "cycle time", "arrival variability", "service-time variability", "blocked work" ], "interpretation_rules": [ "If utilization is high and queue age is rising, adding more work will worsen delivery.", "If task-size variance is high, normalize work before scaling capacity.", "If queue data is missing, mark telemetry as insufficient for capacity decisions." ] }, { "formula_id": "wip_rule_of_two", "label": "Rule of Two WIP Constraint", "formula": "WIP_person <= 2", "plain_language": "A contributor should not carry unlimited active work. Too much WIP hides blocked flow and destroys feedback.", "diagnostic_use": "Use this to identify false capacity created by multitasking and fragmented ownership.", "required_signals": [ "active items per contributor", "work state aging", "blocked items", "handoff count", "review waiting time" ], "interpretation_rules": [ "If contributors carry more active work than the operating limit, treat capacity as fragmented.", "If blocked work causes new work starts, the system is optimizing busyness over delivery.", "If the tracker cannot show WIP by contributor or workstream, mark telemetry incomplete." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "pull request system", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "onboarding duration", "review queue age", "PR correction rate", "deployment success" ], "evidence_needed": [ "onboarding duration", "review queue age", "PR correction rate", "deployment success" ], "validation_signal": "Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling.", "score_dimensions": [ "Capacity Reality", "Knowledge Transfer Readiness", "Execution Determinism" ], "metrics_signals": [ "onboarding duration", "review queue age", "PR correction rate", "deployment success", "Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling.", "Capacity Reality", "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "unabsorbable_capacity", "queue_growth" ], "governance_risk": [ "unabsorbable_capacity", "queue_growth" ], "recommended_report_type": "Capacity Topology Readiness Report", "good_answer_pattern": "A strong answer directly answers: \"Is the engineering system ready to absorb additional contributors without increasing queue time?\" Validation method: Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Knowledge Transfer Readiness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: New capacity can create negative throughput if onboarding, review, knowledge, and release systems are not ready.", "answer_card_output": { "answer_type": "capacity_constraint_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling.", "Evidence from work tracker, pull request system, CI/CD, deployment system, incident system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Topology Readiness Report." ], "common_failure_modes": [ "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: New capacity can create negative throughput if onboarding, review, knowledge, and release systems are not ready.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Topology Readiness Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer capacity-005: \"Is the engineering system ready to absorb additional contributors without increasing queue time?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, pull request system, CI/CD, deployment system, incident system.\nMinimum evidence to check: onboarding duration, review queue age, PR correction rate, deployment success.\nUse these public model references if relevant: sequential_probability_network, kingman_wait_time, wip_rule_of_two.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-capacity-006", "source_question_id": "capacity-006", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "capacity_intelligence", "domain_label": "Capacity Intelligence", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#capacity_intelligence", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "capacity intelligence", "cognitive load", "review capacity", "blocked-work", "decisions", "governance", "decision_latency", "blocked_capacity" ], "decision_context": "Use when leaders need to know whether engineering capacity is real, usable, constrained, or only visible as headcount.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "shirking_margin_zeta", "label": "Shirking Margin", "formula": "zeta_i^x = P(project succeeds | e_i=0, policy x)", "plain_language": "Zeta measures how safe a contributor feels when they do not apply full effort. If the system hides weak effort behind downstream rescue, incentive quality degrades.", "diagnostic_use": "Use this to test whether AI, QA, senior rescue, or vendor buffering is hiding low-quality upstream work.", "required_signals": [ "review correction rate", "reopened work", "QA rescue count", "senior rescue count", "agent-generated rework", "approval override history" ], "interpretation_rules": [ "If downstream rescue repeatedly masks upstream defects, do not treat delivered work as healthy capacity.", "If agent output lowers effort discipline, require stronger validation and ownership boundaries.", "If responsibility is unclear, classify the risk as governance failure before capacity failure." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "decision records", "architecture records", "approval workflow" ], "minimum_evidence": [ "blocked reason", "decision wait time", "approval age", "priority changes" ], "evidence_needed": [ "blocked reason", "decision wait time", "approval age", "priority changes" ], "validation_signal": "Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency.", "score_dimensions": [ "Capacity Reality", "Governance Completeness" ], "metrics_signals": [ "blocked reason", "decision wait time", "approval age", "priority changes", "Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency.", "Capacity Reality", "Governance Completeness" ], "risk_flags": [ "decision_latency", "ambiguous_priority" ], "governance_risk": [ "decision_latency", "ambiguous_priority" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "good_answer_pattern": "A strong answer directly answers: \"What capacity is blocked by missing decisions rather than missing people?\" Validation method: Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, decision records, architecture records, and related approved sources. It misses the operating risk: Many capacity problems are decision-system problems: unclear priority, product ambiguity, architecture approval, or governance delay.", "answer_card_output": { "answer_type": "capacity_constraint_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency.", "Evidence from work tracker, decision records, architecture records, approval workflow.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Engineering Capacity OS Diagnostic." ], "common_failure_modes": [ "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, decision records, architecture records, and related approved sources. It misses the operating risk: Many capacity problems are decision-system problems: unclear priority, product ambiguity, architecture approval, or governance delay.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Engineering Capacity OS Diagnostic" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer capacity-006: \"What capacity is blocked by missing decisions rather than missing people?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, decision records, architecture records, approval workflow.\nMinimum evidence to check: blocked reason, decision wait time, approval age, priority changes.\nUse these public model references if relevant: shirking_margin_zeta.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-capacity-007", "source_question_id": "capacity-007", "audience": [ "US CTO", "US CIO", "VP Engineering" ], "domain": "capacity_intelligence", "domain_label": "Capacity Intelligence", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#capacity_intelligence", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "capacity intelligence", "cognitive load", "review capacity", "skills", "topology", "scarcity", "skill_fit", "topology_fit" ], "decision_context": "Use when leaders need to know whether engineering capacity is real, usable, constrained, or only visible as headcount.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "strict_complementarity", "label": "Strict Complementarity", "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ] }, { "formula_id": "l2_adjusted_score", "label": "L2 Adjusted Communication Score", "formula": "s_adj = s_raw - beta * (f_error - E[f | P])", "plain_language": "Language form errors should not be allowed to erase correct technical reasoning.", "diagnostic_use": "Use this as a public doctrine mapping for fair evaluation of distributed contributors, not as a public scoring engine.", "required_signals": [ "evaluation rubric", "technical reasoning evidence", "communication context", "review calibration", "bias control record" ], "interpretation_rules": [ "Do not use accent or grammar as a proxy for engineering capability.", "Separate reasoning quality from language surface form.", "Do not expose individual evaluation records through the public research workflow." ] }, { "formula_id": "frechet_semantic_distance", "label": "Frechet Semantic Distance", "formula": "FSD(y_q,b_q)=||mu_y-mu_b||_2^2 + Tr(Sigma_y + Sigma_b - 2(Sigma_y^(1/2) Sigma_b Sigma_y^(1/2))^(1/2))", "plain_language": "Semantic similarity should be measured by meaning, not surface phrasing.", "diagnostic_use": "Use this as a public doctrine reference for semantic matching and technical reasoning fidelity.", "required_signals": [ "approved rubric", "ideal answer blueprint", "semantic content evidence", "calibration record" ], "interpretation_rules": [ "Use semantic equivalence only inside approved evaluation or knowledge systems.", "Do not publish private transcript data or proprietary scoring parameters.", "If calibration evidence is missing, mark the semantic claim as unsupported." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "skills inventory", "service ownership map", "pull request system" ], "minimum_evidence": [ "skill demand", "skill supply", "review dependency", "ownership concentration" ], "evidence_needed": [ "skill demand", "skill supply", "review dependency", "ownership concentration" ], "validation_signal": "Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness.", "score_dimensions": [ "Capacity Reality", "Topology Fit" ], "metrics_signals": [ "skill demand", "skill supply", "review dependency", "ownership concentration", "Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness.", "Capacity Reality", "Topology Fit" ], "risk_flags": [ "scarce_skill_constraint", "knowledge_concentration" ], "governance_risk": [ "scarce_skill_constraint", "knowledge_concentration" ], "recommended_report_type": "Capacity Topology Readiness Report", "good_answer_pattern": "A strong answer directly answers: \"Which skills are scarce enough to determine capacity topology decisions?\" Validation method: Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, skills inventory, service ownership map, and related approved sources. It misses the operating risk: Topology decisions should follow scarce skills, knowledge concentration, review authority, and risk boundaries rather than location preference.", "answer_card_output": { "answer_type": "capacity_constraint_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness.", "Evidence from work tracker, skills inventory, service ownership map, pull request system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Topology Readiness Report." ], "common_failure_modes": [ "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, skills inventory, service ownership map, and related approved sources. It misses the operating risk: Topology decisions should follow scarce skills, knowledge concentration, review authority, and risk boundaries rather than location preference.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Topology Readiness Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer capacity-007: \"Which skills are scarce enough to determine capacity topology decisions?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, skills inventory, service ownership map, pull request system.\nMinimum evidence to check: skill demand, skill supply, review dependency, ownership concentration.\nUse these public model references if relevant: strict_complementarity, l2_adjusted_score, frechet_semantic_distance.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-capacity-008", "source_question_id": "capacity-008", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "capacity_intelligence", "domain_label": "Capacity Intelligence", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#capacity_intelligence", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "capacity intelligence", "cognitive load", "review capacity", "repair-before-scale", "capacity", "risk", "system_bottleneck", "capacity_repair" ], "decision_context": "Use when leaders need to know whether engineering capacity is real, usable, constrained, or only visible as headcount.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "wage_equation", "label": "Wage Equation", "formula": "w_i^x = c / (p_n - zeta_i^x)", "plain_language": "As the incentive margin shrinks, the cost required to sustain high effort rises.", "diagnostic_use": "Use this to explain why cheap capacity can become expensive when coordination friction, review drag, and rescue work rise.", "required_signals": [ "cycle time", "review drag", "rework rate", "defect escape", "incident load", "coordination delay", "topology cost" ], "interpretation_rules": [ "If low-cost capacity creates high review drag, the system cost is not low.", "If the evidence does not include rework and delay, do not make a cost claim.", "If capacity topology changes reduce friction, treat the gain as operating leverage." ] }, { "formula_id": "cost_of_delay", "label": "Cost of Delay", "formula": "CoD = dV_lost / dt = -dV_remaining / dt", "plain_language": "Cost of delay is the rate at which waiting destroys remaining value or accumulates lost value. The sign convention must be stated before comparing work.", "diagnostic_use": "Use this to prioritize work by time-sensitive value rather than loudness, politics, or activity volume.", "required_signals": [ "business milestone", "work age", "expected value", "cycle time", "blocked dependency", "release date movement" ], "interpretation_rules": [ "If business value is time-sensitive, queue age becomes economic loss.", "If work priority lacks value and time basis, do not treat priority labels as evidence.", "If telemetry cannot connect work to outcome, report missing value instrumentation." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "pull request system", "CI/CD", "incident system", "architecture records" ], "minimum_evidence": [ "queue impact", "quality impact", "risk impact", "control gaps" ], "evidence_needed": [ "queue impact", "quality impact", "risk impact", "control gaps" ], "validation_signal": "Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls.", "score_dimensions": [ "Capacity Reality", "Upside Potential", "Governance Completeness" ], "metrics_signals": [ "queue impact", "quality impact", "risk impact", "control gaps", "Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls.", "Capacity Reality", "Upside Potential", "Governance Completeness" ], "risk_flags": [ "premature_scaling", "automation_amplifies_bottleneck" ], "governance_risk": [ "premature_scaling", "automation_amplifies_bottleneck" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "good_answer_pattern": "A strong answer directly answers: \"Which capacity constraints should be repaired before any sourcing, hiring, or automation decision is made?\" Validation method: Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Upside Potential, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: A poor system can absorb hiring, partners, or AI agents and still produce worse delivery behavior.", "answer_card_output": { "answer_type": "capacity_constraint_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls.", "Evidence from work tracker, pull request system, CI/CD, incident system, architecture records.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Engineering Capacity OS Diagnostic." ], "common_failure_modes": [ "A weak answer gives a generic capacity intelligence diagnosis instead of proving the research question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: A poor system can absorb hiring, partners, or AI agents and still produce worse delivery behavior.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Engineering Capacity OS Diagnostic" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer capacity-008: \"Which capacity constraints should be repaired before any sourcing, hiring, or automation decision is made?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, pull request system, CI/CD, incident system, architecture records.\nMinimum evidence to check: queue impact, quality impact, risk impact, control gaps.\nUse these public model references if relevant: wage_equation, cost_of_delay.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-topology-001", "source_question_id": "topology-001", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "distributed_capacity_topology", "domain_label": "Distributed Capacity Topology", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#distributed_capacity_topology", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "team topology", "partner topology", "platform topology", "topology", "distribution", "workstreams", "workstream_allocation", "distributed_capacity" ], "decision_context": "Use when leaders must decide how work should be distributed across internal teams, partners, platforms, geographies, and AI systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "The safest workstreams to distribute are low-coupling, explicitly documented, testable, observable, access-bounded, reversible, and supported by sufficient internal review and escalation capacity.", "math_and_model_references": [ { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "service ownership map", "incident system", "architecture documentation" ], "minimum_evidence": [ "workstream complexity", "dependency count", "review requirements", "knowledge availability" ], "evidence_needed": [ "workstream complexity", "dependency count", "review requirements", "knowledge availability" ], "validation_signal": "Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability.", "score_dimensions": [ "Topology Fit", "Knowledge Transfer Readiness", "Governance Completeness" ], "metrics_signals": [ "workstream complexity", "dependency count", "review requirements", "knowledge availability", "Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability.", "Topology Fit", "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "unsafe_distribution", "knowledge_gap" ], "governance_risk": [ "unsafe_distribution", "knowledge_gap" ], "recommended_report_type": "Capacity Topology Readiness Report", "good_answer_pattern": "A strong answer directly answers: \"Which engineering workstreams are safest to distribute beyond the current core team?\" Validation method: Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with work tracker, service ownership map, incident system, and related approved sources. It misses the operating risk: Not all work has the same knowledge, security, coordination, or ownership requirements.", "answer_card_output": { "answer_type": "capacity_topology_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability.", "Evidence from work tracker, service ownership map, incident system, architecture documentation.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Topology Readiness Report." ], "common_failure_modes": [ "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with work tracker, service ownership map, incident system, and related approved sources. It misses the operating risk: Not all work has the same knowledge, security, coordination, or ownership requirements.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Topology Readiness Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer topology-001: \"Which engineering workstreams are safest to distribute beyond the current core team?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, service ownership map, incident system, architecture documentation.\nMinimum evidence to check: workstream complexity, dependency count, review requirements, knowledge availability.\nUse these public model references if relevant: sequential_probability_network.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-topology-002", "source_question_id": "topology-002", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "distributed_capacity_topology", "domain_label": "Distributed Capacity Topology", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#distributed_capacity_topology", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "team topology", "partner topology", "platform topology", "internal-ownership", "risk", "security", "internal_control", "ownership_boundary" ], "decision_context": "Use when leaders must decide how work should be distributed across internal teams, partners, platforms, geographies, and AI systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Which workstreams should remain internally owned?", "why_it_matters": "Some work requires direct architectural, product, security, or customer-context control.", "doctrine_answer_boundary": "Work should remain internally owned when it controls strategic architecture, sensitive data, security authority, customer context, regulated decisions, critical IP, or irreversible production impact.", "math_and_model_references": [ { "formula_id": "strict_complementarity", "label": "Strict Complementarity", "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ] } ], "evidence_to_request_from_internal_mcp": [ "architecture records", "security classification", "service ownership map", "incident system" ], "minimum_evidence": [ "IP sensitivity", "production impact", "data sensitivity", "architecture authority" ], "evidence_needed": [ "IP sensitivity", "production impact", "data sensitivity", "architecture authority" ], "validation_signal": "Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact.", "score_dimensions": [ "Topology Fit", "Governance Completeness" ], "metrics_signals": [ "IP sensitivity", "production impact", "data sensitivity", "architecture authority", "Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact.", "Topology Fit", "Governance Completeness" ], "risk_flags": [ "ip_exposure", "loss_of_architecture_control" ], "governance_risk": [ "ip_exposure", "loss_of_architecture_control" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"Which workstreams should remain internally owned?\" Validation method: Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with architecture records, security classification, service ownership map, and related approved sources. It misses the operating risk: Some work requires direct architectural, product, security, or customer-context control.", "answer_card_output": { "answer_type": "capacity_topology_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact.", "Evidence from architecture records, security classification, service ownership map, incident system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with architecture records, security classification, service ownership map, and related approved sources. It misses the operating risk: Some work requires direct architectural, product, security, or customer-context control.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer topology-002: \"Which workstreams should remain internally owned?\"\nUse only aggregate, redacted, or metadata level evidence from: architecture records, security classification, service ownership map, incident system.\nMinimum evidence to check: IP sensitivity, production impact, data sensitivity, architecture authority.\nUse these public model references if relevant: strict_complementarity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-topology-003", "source_question_id": "topology-003", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "distributed_capacity_topology", "domain_label": "Distributed Capacity Topology", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#distributed_capacity_topology", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "team topology", "partner topology", "platform topology", "topology-fit", "allocation", "strategy", "capacity_topology", "sourcing_topology" ], "decision_context": "Use when leaders must decide how work should be distributed across internal teams, partners, platforms, geographies, and AI systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "wage_equation", "label": "Wage Equation", "formula": "w_i^x = c / (p_n - zeta_i^x)", "plain_language": "As the incentive margin shrinks, the cost required to sustain high effort rises.", "diagnostic_use": "Use this to explain why cheap capacity can become expensive when coordination friction, review drag, and rescue work rise.", "required_signals": [ "cycle time", "review drag", "rework rate", "defect escape", "incident load", "coordination delay", "topology cost" ], "interpretation_rules": [ "If low-cost capacity creates high review drag, the system cost is not low.", "If the evidence does not include rework and delay, do not make a cost claim.", "If capacity topology changes reduce friction, treat the gain as operating leverage." ] }, { "formula_id": "cost_of_delay", "label": "Cost of Delay", "formula": "CoD = dV_lost / dt = -dV_remaining / dt", "plain_language": "Cost of delay is the rate at which waiting destroys remaining value or accumulates lost value. The sign convention must be stated before comparing work.", "diagnostic_use": "Use this to prioritize work by time-sensitive value rather than loudness, politics, or activity volume.", "required_signals": [ "business milestone", "work age", "expected value", "cycle time", "blocked dependency", "release date movement" ], "interpretation_rules": [ "If business value is time-sensitive, queue age becomes economic loss.", "If work priority lacks value and time basis, do not treat priority labels as evidence.", "If telemetry cannot connect work to outcome, report missing value instrumentation." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "skills inventory", "service ownership map", "security policy", "delivery telemetry" ], "minimum_evidence": [ "skill fit", "ownership requirements", "timezone needs", "governance constraints" ], "evidence_needed": [ "skill fit", "ownership requirements", "timezone needs", "governance constraints" ], "validation_signal": "Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence.", "score_dimensions": [ "Topology Fit", "Capacity Reality", "Governance Completeness" ], "metrics_signals": [ "skill fit", "ownership requirements", "timezone needs", "governance constraints", "Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence.", "Topology Fit", "Capacity Reality", "Governance Completeness" ], "risk_flags": [ "topology_mismatch", "coordination_cost" ], "governance_risk": [ "topology_mismatch", "coordination_cost" ], "recommended_report_type": "Capacity Topology Readiness Report", "good_answer_pattern": "A strong answer directly answers: \"Which capacity topology best matches each workstream?\" Validation method: Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Capacity Reality, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with work tracker, skills inventory, service ownership map, and related approved sources. It misses the operating risk: Internal hiring, external partners, nearshore, offshore, platform investment, and AI agents solve different constraints.", "answer_card_output": { "answer_type": "capacity_topology_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence.", "Evidence from work tracker, skills inventory, service ownership map, security policy, delivery telemetry.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Topology Readiness Report." ], "common_failure_modes": [ "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with work tracker, skills inventory, service ownership map, and related approved sources. It misses the operating risk: Internal hiring, external partners, nearshore, offshore, platform investment, and AI agents solve different constraints.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Topology Readiness Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer topology-003: \"Which capacity topology best matches each workstream?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, skills inventory, service ownership map, security policy, delivery telemetry.\nMinimum evidence to check: skill fit, ownership requirements, timezone needs, governance constraints.\nUse these public model references if relevant: engineering_performance_function, wage_equation, cost_of_delay.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-topology-004", "source_question_id": "topology-004", "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader" ], "domain": "distributed_capacity_topology", "domain_label": "Distributed Capacity Topology", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#distributed_capacity_topology", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "team topology", "partner topology", "platform topology", "timezone", "cycle-time", "distributed", "coordination_tolerance", "handoff_delay" ], "decision_context": "Use when leaders must decide how work should be distributed across internal teams, partners, platforms, geographies, and AI systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "incentive_compatibility_constraint", "label": "Incentive Compatibility Constraint", "formula": "p_n * w_i - c >= zeta_i^x * w_i", "plain_language": "A contributor exerts effort when the expected value of working is greater than the expected value of shirking.", "diagnostic_use": "Use this as a qualitative operating model for effort, friction, unclear ownership, time-zone delay, and downstream safety nets.", "required_signals": [ "decision latency", "blocked time", "handoff delay", "context switching", "work ownership", "review accountability" ], "interpretation_rules": [ "If coordination cost is high, effort drops even when people are busy.", "If ownership is unclear, activity signals are not evidence of productive effort.", "If downstream teams constantly catch upstream issues, the incentive model is distorted." ] }, { "formula_id": "synchronization_penalty", "label": "Synchronization Penalty", "formula": "S_p = sum(T_wait + T_context_switch)", "plain_language": "Distributed work pays a penalty whenever waiting time and context switching replace direct feedback.", "diagnostic_use": "Use this to measure whether time-zone overlap, unclear ownership, or missing self-serve context is slowing the SDLC.", "required_signals": [ "wait time", "handoff delay", "blocked comments", "review latency", "time-zone overlap", "context switch count" ], "interpretation_rules": [ "If wait time is caused by missing context, add documentation or ownership before adding people.", "If time-zone overlap materially affects cycle time, topology choice must include overlap as a constraint.", "If context switching is unmeasured, report capacity as partially unknown." ] } ], "evidence_to_request_from_internal_mcp": [ "Jira or Linear", "GitHub or GitLab", "calendar metadata if approved and aggregated", "incident system" ], "minimum_evidence": [ "blocked time", "handoff delay", "review latency", "incident response requirements" ], "evidence_needed": [ "blocked time", "handoff delay", "review latency", "incident response requirements" ], "validation_signal": "Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes.", "score_dimensions": [ "Topology Fit", "Telemetry Trust", "Governance Completeness" ], "metrics_signals": [ "blocked time", "handoff delay", "review latency", "incident response requirements", "Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes.", "Topology Fit", "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "decision_latency", "handoff_delay", "incident_response_risk" ], "governance_risk": [ "decision_latency", "handoff_delay", "incident_response_risk" ], "recommended_report_type": "Capacity Topology Readiness Report", "good_answer_pattern": "A strong answer directly answers: \"Where does time-zone overlap materially affect cycle time?\" Validation method: Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with Jira or Linear, GitHub or GitLab, calendar metadata if approved and aggregated, and related approved sources. It misses the operating risk: Distributed capacity fails when decision latency exceeds the work's coordination tolerance.", "answer_card_output": { "answer_type": "capacity_topology_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes.", "Evidence from Jira or Linear, GitHub or GitLab, calendar metadata if approved and aggregated, incident system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Topology Readiness Report." ], "common_failure_modes": [ "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with Jira or Linear, GitHub or GitLab, calendar metadata if approved and aggregated, and related approved sources. It misses the operating risk: Distributed capacity fails when decision latency exceeds the work's coordination tolerance.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Topology Readiness Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer topology-004: \"Where does time-zone overlap materially affect cycle time?\"\nUse only aggregate, redacted, or metadata level evidence from: Jira or Linear, GitHub or GitLab, calendar metadata if approved and aggregated, incident system.\nMinimum evidence to check: blocked time, handoff delay, review latency, incident response requirements.\nUse these public model references if relevant: incentive_compatibility_constraint, synchronization_penalty.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-topology-005", "source_question_id": "topology-005", "audience": [ "US CTO", "US CIO", "VP Engineering" ], "domain": "distributed_capacity_topology", "domain_label": "Distributed Capacity Topology", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#distributed_capacity_topology", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "team topology", "partner topology", "platform topology", "review-capacity", "contributors", "scaling", "review_capacity", "distributed_contributors" ], "decision_context": "Use when leaders must decide how work should be distributed across internal teams, partners, platforms, geographies, and AI systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "strict_complementarity", "label": "Strict Complementarity", "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ] } ], "evidence_to_request_from_internal_mcp": [ "pull request system", "work tracker", "architecture reviews" ], "minimum_evidence": [ "PR volume", "review queue age", "reviewer availability", "correction rate" ], "evidence_needed": [ "PR volume", "review queue age", "reviewer availability", "correction rate" ], "validation_signal": "Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes.", "score_dimensions": [ "Capacity Reality", "Topology Fit", "Execution Determinism" ], "metrics_signals": [ "PR volume", "review queue age", "reviewer availability", "correction rate", "Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes.", "Capacity Reality", "Topology Fit", "Execution Determinism" ], "risk_flags": [ "review_saturation", "correction_load" ], "governance_risk": [ "review_saturation", "correction_load" ], "recommended_report_type": "Capacity Topology Readiness Report", "good_answer_pattern": "A strong answer directly answers: \"What review capacity must exist before adding distributed contributors?\" Validation method: Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Capacity Reality, Topology Fit, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with pull request system, work tracker, architecture reviews. It misses the operating risk: Additional contributors can increase bottlenecks if review and architecture authority do not scale.", "answer_card_output": { "answer_type": "capacity_topology_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes.", "Evidence from pull request system, work tracker, architecture reviews.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Topology Readiness Report." ], "common_failure_modes": [ "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with pull request system, work tracker, architecture reviews. It misses the operating risk: Additional contributors can increase bottlenecks if review and architecture authority do not scale.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Topology Readiness Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer topology-005: \"What review capacity must exist before adding distributed contributors?\"\nUse only aggregate, redacted, or metadata level evidence from: pull request system, work tracker, architecture reviews.\nMinimum evidence to check: PR volume, review queue age, reviewer availability, correction rate.\nUse these public model references if relevant: strict_complementarity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-topology-006", "source_question_id": "topology-006", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "Platform Leader" ], "domain": "distributed_capacity_topology", "domain_label": "Distributed Capacity Topology", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#distributed_capacity_topology", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "team topology", "partner topology", "platform topology", "ownership", "services", "distributed", "service_ownership", "external_ownership" ], "decision_context": "Use when leaders must decide how work should be distributed across internal teams, partners, platforms, geographies, and AI systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] }, { "formula_id": "dependency_density", "label": "Dependency Density", "formula": "E_max = N(N-1)/2; D = E/E_max", "plain_language": "A system with N nodes can contain at most N(N-1)/2 undirected pairwise dependencies. Actual dependency density is the observed edge count divided by that bound.", "diagnostic_use": "Use this to test whether team, service, or vendor topology is creating integration cost faster than delivery value.", "required_signals": [ "service count", "team count", "interface count", "cross-service changes", "owner map", "dependency incidents" ], "interpretation_rules": [ "If dependency count grows without ownership clarity, integration risk rises.", "If service boundaries exist only on diagrams and not in code or deployment independence, classify as distributed monolith risk.", "If dependency evidence is missing, do not recommend distributed ownership." ] } ], "evidence_to_request_from_internal_mcp": [ "service catalog", "runbooks", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "documentation quality", "test reliability", "deployment reproducibility", "ownership clarity" ], "evidence_needed": [ "documentation quality", "test reliability", "deployment reproducibility", "ownership clarity" ], "validation_signal": "Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity.", "score_dimensions": [ "Topology Fit", "Knowledge Transfer Readiness", "Execution Determinism" ], "metrics_signals": [ "documentation quality", "test reliability", "deployment reproducibility", "ownership clarity", "Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity.", "Topology Fit", "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "ownership_ambiguity", "service_transfer_risk" ], "governance_risk": [ "ownership_ambiguity", "service_transfer_risk" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "good_answer_pattern": "A strong answer directly answers: \"Which systems or services are ready for external or distributed ownership?\" Validation method: Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Knowledge Transfer Readiness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with service catalog, runbooks, CI/CD, and related approved sources. It misses the operating risk: Ownership requires knowledge, test coverage, runbooks, telemetry, and clear escalation paths.", "answer_card_output": { "answer_type": "capacity_topology_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity.", "Evidence from service catalog, runbooks, CI/CD, deployment system, incident system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Knowledge and Architecture Memory Report." ], "common_failure_modes": [ "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with service catalog, runbooks, CI/CD, and related approved sources. It misses the operating risk: Ownership requires knowledge, test coverage, runbooks, telemetry, and clear escalation paths.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Knowledge and Architecture Memory Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer topology-006: \"Which systems or services are ready for external or distributed ownership?\"\nUse only aggregate, redacted, or metadata level evidence from: service catalog, runbooks, CI/CD, deployment system, incident system.\nMinimum evidence to check: documentation quality, test reliability, deployment reproducibility, ownership clarity.\nUse these public model references if relevant: sequential_probability_network, dependency_density.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-topology-007", "source_question_id": "topology-007", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "distributed_capacity_topology", "domain_label": "Distributed Capacity Topology", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#distributed_capacity_topology", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "team topology", "partner topology", "platform topology", "access", "permissions", "security", "access_boundary", "contributor_type" ], "decision_context": "Use when leaders must decide how work should be distributed across internal teams, partners, platforms, geographies, and AI systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] }, { "formula_id": "strict_complementarity", "label": "Strict Complementarity", "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ] } ], "evidence_to_request_from_internal_mcp": [ "identity provider", "repository permissions", "deployment permissions", "security policy" ], "minimum_evidence": [ "access class", "repository scope", "environment permission", "production authority" ], "evidence_needed": [ "access class", "repository scope", "environment permission", "production authority" ], "validation_signal": "Map contributor types to repository, environment, data, secrets, deployment, and production permissions.", "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "metrics_signals": [ "access class", "repository scope", "environment permission", "production authority", "Map contributor types to repository, environment, data, secrets, deployment, and production permissions.", "Governance Completeness", "Topology Fit" ], "risk_flags": [ "access_overreach", "ip_exposure", "production_risk" ], "governance_risk": [ "access_overreach", "ip_exposure", "production_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"What access should each contributor type have?\" Validation method: Map contributor types to repository, environment, data, secrets, deployment, and production permissions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with identity provider, repository permissions, deployment permissions, and related approved sources. It misses the operating risk: Capacity topology creates security and IP exposure if access is not role- and risk-based.", "answer_card_output": { "answer_type": "capacity_topology_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Map contributor types to repository, environment, data, secrets, deployment, and production permissions.", "Evidence from identity provider, repository permissions, deployment permissions, security policy.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with identity provider, repository permissions, deployment permissions, and related approved sources. It misses the operating risk: Capacity topology creates security and IP exposure if access is not role- and risk-based.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer topology-007: \"What access should each contributor type have?\"\nUse only aggregate, redacted, or metadata level evidence from: identity provider, repository permissions, deployment permissions, security policy.\nMinimum evidence to check: access class, repository scope, environment permission, production authority.\nUse these public model references if relevant: engineering_performance_function, sequential_probability_network, strict_complementarity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-topology-008", "source_question_id": "topology-008", "audience": [ "US CTO", "US CIO", "VP Engineering" ], "domain": "distributed_capacity_topology", "domain_label": "Distributed Capacity Topology", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#distributed_capacity_topology", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "team topology", "partner topology", "platform topology", "onboarding", "ramp", "independence", "ramp_curve", "independent_contribution" ], "decision_context": "Use when leaders must decide how work should be distributed across internal teams, partners, platforms, geographies, and AI systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "l2_adjusted_score", "label": "L2 Adjusted Communication Score", "formula": "s_adj = s_raw - beta * (f_error - E[f | P])", "plain_language": "Language form errors should not be allowed to erase correct technical reasoning.", "diagnostic_use": "Use this as a public doctrine mapping for fair evaluation of distributed contributors, not as a public scoring engine.", "required_signals": [ "evaluation rubric", "technical reasoning evidence", "communication context", "review calibration", "bias control record" ], "interpretation_rules": [ "Do not use accent or grammar as a proxy for engineering capability.", "Separate reasoning quality from language surface form.", "Do not expose individual evaluation records through the public research workflow." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "pull request system", "onboarding records", "escalation logs" ], "minimum_evidence": [ "time to first accepted PR", "independent task completion", "correction rate", "escalation frequency" ], "evidence_needed": [ "time to first accepted PR", "independent task completion", "correction rate", "escalation frequency" ], "validation_signal": "Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency.", "score_dimensions": [ "Knowledge Transfer Readiness", "Capacity Reality" ], "metrics_signals": [ "time to first accepted PR", "independent task completion", "correction rate", "escalation frequency", "Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency.", "Knowledge Transfer Readiness", "Capacity Reality" ], "risk_flags": [ "slow_ramp", "supervision_overhead" ], "governance_risk": [ "slow_ramp", "supervision_overhead" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "good_answer_pattern": "A strong answer directly answers: \"What is the ramp curve from onboarding to independent contribution?\" Validation method: Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Capacity Reality.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with work tracker, pull request system, onboarding records, and related approved sources. It misses the operating risk: Capacity is not real until contributors can produce safely without excessive supervision.", "answer_card_output": { "answer_type": "capacity_topology_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency.", "Evidence from work tracker, pull request system, onboarding records, escalation logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Knowledge and Architecture Memory Report." ], "common_failure_modes": [ "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with work tracker, pull request system, onboarding records, and related approved sources. It misses the operating risk: Capacity is not real until contributors can produce safely without excessive supervision.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Knowledge and Architecture Memory Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer topology-008: \"What is the ramp curve from onboarding to independent contribution?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, pull request system, onboarding records, escalation logs.\nMinimum evidence to check: time to first accepted PR, independent task completion, correction rate, escalation frequency.\nUse these public model references if relevant: l2_adjusted_score.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-topology-009", "source_question_id": "topology-009", "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader" ], "domain": "distributed_capacity_topology", "domain_label": "Distributed Capacity Topology", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#distributed_capacity_topology", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "team topology", "partner topology", "platform topology", "rituals", "coordination", "latency", "decision_latency", "operating_rituals" ], "decision_context": "Use when leaders must decide how work should be distributed across internal teams, partners, platforms, geographies, and AI systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Which communication rituals reduce decision latency?", "why_it_matters": "Distributed systems need explicit coordination mechanisms.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "incentive_compatibility_constraint", "label": "Incentive Compatibility Constraint", "formula": "p_n * w_i - c >= zeta_i^x * w_i", "plain_language": "A contributor exerts effort when the expected value of working is greater than the expected value of shirking.", "diagnostic_use": "Use this as a qualitative operating model for effort, friction, unclear ownership, time-zone delay, and downstream safety nets.", "required_signals": [ "decision latency", "blocked time", "handoff delay", "context switching", "work ownership", "review accountability" ], "interpretation_rules": [ "If coordination cost is high, effort drops even when people are busy.", "If ownership is unclear, activity signals are not evidence of productive effort.", "If downstream teams constantly catch upstream issues, the incentive model is distorted." ] }, { "formula_id": "synchronization_penalty", "label": "Synchronization Penalty", "formula": "S_p = sum(T_wait + T_context_switch)", "plain_language": "Distributed work pays a penalty whenever waiting time and context switching replace direct feedback.", "diagnostic_use": "Use this to measure whether time-zone overlap, unclear ownership, or missing self-serve context is slowing the SDLC.", "required_signals": [ "wait time", "handoff delay", "blocked comments", "review latency", "time-zone overlap", "context switch count" ], "interpretation_rules": [ "If wait time is caused by missing context, add documentation or ownership before adding people.", "If time-zone overlap materially affects cycle time, topology choice must include overlap as a constraint.", "If context switching is unmeasured, report capacity as partially unknown." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "decision records", "calendar metadata if approved and aggregated", "pull request system" ], "minimum_evidence": [ "blocked states", "decision wait time", "handoff delay", "meeting load" ], "evidence_needed": [ "blocked states", "decision wait time", "handoff delay", "meeting load" ], "validation_signal": "Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes.", "score_dimensions": [ "Topology Fit", "Telemetry Trust" ], "metrics_signals": [ "blocked states", "decision wait time", "handoff delay", "meeting load", "Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes.", "Topology Fit", "Telemetry Trust" ], "risk_flags": [ "coordination_overhead", "meeting_load" ], "governance_risk": [ "coordination_overhead", "meeting_load" ], "recommended_report_type": "Capacity Topology Readiness Report", "good_answer_pattern": "A strong answer directly answers: \"Which communication rituals reduce decision latency?\" Validation method: Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Topology Fit, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with work tracker, decision records, calendar metadata if approved and aggregated, and related approved sources. It misses the operating risk: Distributed systems need explicit coordination mechanisms.", "answer_card_output": { "answer_type": "capacity_topology_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes.", "Evidence from work tracker, decision records, calendar metadata if approved and aggregated, pull request system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Topology Readiness Report." ], "common_failure_modes": [ "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with work tracker, decision records, calendar metadata if approved and aggregated, and related approved sources. It misses the operating risk: Distributed systems need explicit coordination mechanisms.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Topology Readiness Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer topology-009: \"Which communication rituals reduce decision latency?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, decision records, calendar metadata if approved and aggregated, pull request system.\nMinimum evidence to check: blocked states, decision wait time, handoff delay, meeting load.\nUse these public model references if relevant: incentive_compatibility_constraint, synchronization_penalty.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-topology-010", "source_question_id": "topology-010", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "distributed_capacity_topology", "domain_label": "Distributed Capacity Topology", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#distributed_capacity_topology", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "distributed capacity topology", "team topology", "partner topology", "platform topology", "exit-plan", "governance", "reversibility", "exit_readiness" ], "decision_context": "Use when leaders must decide how work should be distributed across internal teams, partners, platforms, geographies, and AI systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "What is the exit path if a capacity topology underperforms?", "why_it_matters": "Governance requires reversibility, not only rollout plans.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] }, { "formula_id": "strict_complementarity", "label": "Strict Complementarity", "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ] } ], "evidence_to_request_from_internal_mcp": [ "contracts or operating agreements", "access policy", "service ownership map", "documentation inventory" ], "minimum_evidence": [ "exit plan", "access removal", "ownership transfer", "service continuity" ], "evidence_needed": [ "exit plan", "access removal", "ownership transfer", "service continuity" ], "validation_signal": "Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans.", "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "metrics_signals": [ "exit plan", "access removal", "ownership transfer", "service continuity", "Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans.", "Governance Completeness", "Topology Fit" ], "risk_flags": [ "irreversible_topology", "continuity_risk" ], "governance_risk": [ "irreversible_topology", "continuity_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"What is the exit path if a capacity topology underperforms?\" Validation method: Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with contracts or operating agreements, access policy, service ownership map, and related approved sources. It misses the operating risk: Governance requires reversibility, not only rollout plans.", "answer_card_output": { "answer_type": "capacity_topology_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans.", "Evidence from contracts or operating agreements, access policy, service ownership map, documentation inventory.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic distributed capacity topology diagnosis instead of proving the research question with contracts or operating agreements, access policy, service ownership map, and related approved sources. It misses the operating risk: Governance requires reversibility, not only rollout plans.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer topology-010: \"What is the exit path if a capacity topology underperforms?\"\nUse only aggregate, redacted, or metadata level evidence from: contracts or operating agreements, access policy, service ownership map, documentation inventory.\nMinimum evidence to check: exit plan, access removal, ownership transfer, service continuity.\nUse these public model references if relevant: engineering_performance_function, sequential_probability_network, strict_complementarity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-knowledge-001", "source_question_id": "knowledge-001", "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader" ], "domain": "knowledge_architecture_memory", "domain_label": "Knowledge Architecture and Memory", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#knowledge_architecture_memory", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "knowledge architecture", "architecture memory", "ownership map", "context loss", "knowledge", "tribal-knowledge", "architecture", "explicit_knowledge", "knowledge_dependency" ], "decision_context": "Use when leaders need to understand whether delivery is blocked by missing context, ownership gaps, weak documentation, or architecture memory loss.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Which parts of the engineering system depend on tribal knowledge?", "why_it_matters": "Tribal knowledge limits distributed execution and safe AI assistance.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "cognitive_fidelity", "label": "Cognitive Fidelity", "formula": "Quality ~ isomorphism(M_e, S_sys)", "plain_language": "Quality depends on how closely an engineer's mental model matches the actual system state.", "diagnostic_use": "Use this to evaluate whether ownership, documentation, and review systems keep human and agent contributors aligned with reality.", "required_signals": [ "architecture decision records", "documentation usage", "review comments", "rework caused by misunderstanding", "incident root cause", "agent correction rate" ], "interpretation_rules": [ "If contributors act on stale or missing system knowledge, delivery failures are knowledge failures before people failures.", "If AI outputs are correct syntactically but wrong semantically, classify the workflow as human-gated.", "If incidents repeat because lessons are not stored, knowledge memory is broken." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "service ownership map", "documentation inventory", "incident system" ], "minimum_evidence": [ "repeated escalation", "undocumented decision", "onboarding blocker", "individual dependency" ], "evidence_needed": [ "repeated escalation", "undocumented decision", "onboarding blocker", "individual dependency" ], "validation_signal": "Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals.", "score_dimensions": [ "Knowledge Transfer Readiness", "Topology Fit" ], "metrics_signals": [ "repeated escalation", "undocumented decision", "onboarding blocker", "individual dependency", "Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals.", "Knowledge Transfer Readiness", "Topology Fit" ], "risk_flags": [ "tribal_knowledge", "single_point_of_context" ], "governance_risk": [ "tribal_knowledge", "single_point_of_context" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "good_answer_pattern": "A strong answer directly answers: \"Which parts of the engineering system depend on tribal knowledge?\" Validation method: Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with work tracker, service ownership map, documentation inventory, and related approved sources. It misses the operating risk: Tribal knowledge limits distributed execution and safe AI assistance.", "answer_card_output": { "answer_type": "knowledge_memory_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals.", "Evidence from work tracker, service ownership map, documentation inventory, incident system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Knowledge and Architecture Memory Report." ], "common_failure_modes": [ "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with work tracker, service ownership map, documentation inventory, and related approved sources. It misses the operating risk: Tribal knowledge limits distributed execution and safe AI assistance.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Knowledge and Architecture Memory Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer knowledge-001: \"Which parts of the engineering system depend on tribal knowledge?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, service ownership map, documentation inventory, incident system.\nMinimum evidence to check: repeated escalation, undocumented decision, onboarding blocker, individual dependency.\nUse these public model references if relevant: engineering_performance_function, cognitive_fidelity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-knowledge-002", "source_question_id": "knowledge-002", "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader" ], "domain": "knowledge_architecture_memory", "domain_label": "Knowledge Architecture and Memory", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#knowledge_architecture_memory", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "knowledge architecture", "architecture memory", "ownership map", "context loss", "adr", "architecture", "documentation", "architecture_memory", "decision_record" ], "decision_context": "Use when leaders need to understand whether delivery is blocked by missing context, ownership gaps, weak documentation, or architecture memory loss.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "How current are architecture decision records?", "why_it_matters": "Distributed contributors and agents need explicit architectural intent.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] }, { "formula_id": "strict_complementarity", "label": "Strict Complementarity", "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ] } ], "evidence_to_request_from_internal_mcp": [ "architecture decision records", "service catalog", "repository history", "incident reviews" ], "minimum_evidence": [ "ADR freshness", "service dependency match", "recent decision coverage", "incident linkage" ], "evidence_needed": [ "ADR freshness", "service dependency match", "recent decision coverage", "incident linkage" ], "validation_signal": "Compare architecture records against current services, dependencies, incidents, and recent implementation choices.", "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "metrics_signals": [ "ADR freshness", "service dependency match", "recent decision coverage", "incident linkage", "Compare architecture records against current services, dependencies, incidents, and recent implementation choices.", "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "architecture_drift", "stale_decision_memory" ], "governance_risk": [ "architecture_drift", "stale_decision_memory" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "good_answer_pattern": "A strong answer directly answers: \"How current are architecture decision records?\" Validation method: Compare architecture records against current services, dependencies, incidents, and recent implementation choices. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with architecture decision records, service catalog, repository history, and related approved sources. It misses the operating risk: Distributed contributors and agents need explicit architectural intent.", "answer_card_output": { "answer_type": "knowledge_memory_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare architecture records against current services, dependencies, incidents, and recent implementation choices.", "Evidence from architecture decision records, service catalog, repository history, incident reviews.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Knowledge and Architecture Memory Report." ], "common_failure_modes": [ "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with architecture decision records, service catalog, repository history, and related approved sources. It misses the operating risk: Distributed contributors and agents need explicit architectural intent.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Knowledge and Architecture Memory Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer knowledge-002: \"How current are architecture decision records?\"\nUse only aggregate, redacted, or metadata level evidence from: architecture decision records, service catalog, repository history, incident reviews.\nMinimum evidence to check: ADR freshness, service dependency match, recent decision coverage, incident linkage.\nUse these public model references if relevant: engineering_performance_function, sequential_probability_network, strict_complementarity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-knowledge-003", "source_question_id": "knowledge-003", "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader" ], "domain": "knowledge_architecture_memory", "domain_label": "Knowledge Architecture and Memory", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#knowledge_architecture_memory", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "knowledge architecture", "architecture memory", "ownership map", "context loss", "ownership", "service-map", "runbooks", "service_ownership", "escalation_path" ], "decision_context": "Use when leaders need to understand whether delivery is blocked by missing context, ownership gaps, weak documentation, or architecture memory loss.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Which services have clear ownership maps?", "why_it_matters": "Ownership ambiguity creates delays, rework, and incident risk.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] }, { "formula_id": "dependency_density", "label": "Dependency Density", "formula": "E_max = N(N-1)/2; D = E/E_max", "plain_language": "A system with N nodes can contain at most N(N-1)/2 undirected pairwise dependencies. Actual dependency density is the observed edge count divided by that bound.", "diagnostic_use": "Use this to test whether team, service, or vendor topology is creating integration cost faster than delivery value.", "required_signals": [ "service count", "team count", "interface count", "cross-service changes", "owner map", "dependency incidents" ], "interpretation_rules": [ "If dependency count grows without ownership clarity, integration risk rises.", "If service boundaries exist only on diagrams and not in code or deployment independence, classify as distributed monolith risk.", "If dependency evidence is missing, do not recommend distributed ownership." ] } ], "evidence_to_request_from_internal_mcp": [ "service catalog", "ownership map", "incident system", "pull request system" ], "minimum_evidence": [ "named owner", "escalation path", "review authority", "support expectation" ], "evidence_needed": [ "named owner", "escalation path", "review authority", "support expectation" ], "validation_signal": "Verify each service has named owners, escalation paths, review authorities, and support expectations.", "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "metrics_signals": [ "named owner", "escalation path", "review authority", "support expectation", "Verify each service has named owners, escalation paths, review authorities, and support expectations.", "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "ownership_ambiguity", "incident_delay" ], "governance_risk": [ "ownership_ambiguity", "incident_delay" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "good_answer_pattern": "A strong answer directly answers: \"Which services have clear ownership maps?\" Validation method: Verify each service has named owners, escalation paths, review authorities, and support expectations. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with service catalog, ownership map, incident system, and related approved sources. It misses the operating risk: Ownership ambiguity creates delays, rework, and incident risk.", "answer_card_output": { "answer_type": "knowledge_memory_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Verify each service has named owners, escalation paths, review authorities, and support expectations.", "Evidence from service catalog, ownership map, incident system, pull request system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Knowledge and Architecture Memory Report." ], "common_failure_modes": [ "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with service catalog, ownership map, incident system, and related approved sources. It misses the operating risk: Ownership ambiguity creates delays, rework, and incident risk.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Knowledge and Architecture Memory Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer knowledge-003: \"Which services have clear ownership maps?\"\nUse only aggregate, redacted, or metadata level evidence from: service catalog, ownership map, incident system, pull request system.\nMinimum evidence to check: named owner, escalation path, review authority, support expectation.\nUse these public model references if relevant: sequential_probability_network, dependency_density.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-knowledge-004", "source_question_id": "knowledge-004", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "knowledge_architecture_memory", "domain_label": "Knowledge Architecture and Memory", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#knowledge_architecture_memory", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "knowledge architecture", "architecture memory", "ownership map", "context loss", "production", "delegation", "knowledge", "production_readiness", "approval_boundary" ], "decision_context": "Use when leaders need to understand whether delivery is blocked by missing context, ownership gaps, weak documentation, or architecture memory loss.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "What knowledge must a contributor have before production-impacting work?", "why_it_matters": "Unsafe delegation often starts with insufficient context.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "strict_complementarity", "label": "Strict Complementarity", "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ] }, { "formula_id": "cognitive_fidelity", "label": "Cognitive Fidelity", "formula": "Quality ~ isomorphism(M_e, S_sys)", "plain_language": "Quality depends on how closely an engineer's mental model matches the actual system state.", "diagnostic_use": "Use this to evaluate whether ownership, documentation, and review systems keep human and agent contributors aligned with reality.", "required_signals": [ "architecture decision records", "documentation usage", "review comments", "rework caused by misunderstanding", "incident root cause", "agent correction rate" ], "interpretation_rules": [ "If contributors act on stale or missing system knowledge, delivery failures are knowledge failures before people failures.", "If AI outputs are correct syntactically but wrong semantically, classify the workflow as human-gated.", "If incidents repeat because lessons are not stored, knowledge memory is broken." ] } ], "evidence_to_request_from_internal_mcp": [ "runbooks", "deployment procedures", "test strategy", "incident reviews", "approval policy" ], "minimum_evidence": [ "required knowledge checklist", "deployment process", "incident history", "approval boundary" ], "evidence_needed": [ "required knowledge checklist", "deployment process", "incident history", "approval boundary" ], "validation_signal": "Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries.", "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "metrics_signals": [ "required knowledge checklist", "deployment process", "incident history", "approval boundary", "Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries.", "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "unsafe_delegation", "production_impact" ], "governance_risk": [ "unsafe_delegation", "production_impact" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "good_answer_pattern": "A strong answer directly answers: \"What knowledge must a contributor have before production-impacting work?\" Validation method: Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with runbooks, deployment procedures, test strategy, and related approved sources. It misses the operating risk: Unsafe delegation often starts with insufficient context.", "answer_card_output": { "answer_type": "knowledge_memory_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries.", "Evidence from runbooks, deployment procedures, test strategy, incident reviews, approval policy.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Knowledge and Architecture Memory Report." ], "common_failure_modes": [ "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with runbooks, deployment procedures, test strategy, and related approved sources. It misses the operating risk: Unsafe delegation often starts with insufficient context.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Knowledge and Architecture Memory Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer knowledge-004: \"What knowledge must a contributor have before production-impacting work?\"\nUse only aggregate, redacted, or metadata level evidence from: runbooks, deployment procedures, test strategy, incident reviews, approval policy.\nMinimum evidence to check: required knowledge checklist, deployment process, incident history, approval boundary.\nUse these public model references if relevant: strict_complementarity, cognitive_fidelity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-knowledge-005", "source_question_id": "knowledge-005", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader", "Platform Leader" ], "domain": "knowledge_architecture_memory", "domain_label": "Knowledge Architecture and Memory", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#knowledge_architecture_memory", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "knowledge architecture", "architecture memory", "ownership map", "context loss", "ai-retrieval", "privacy", "knowledge", "retrieval_boundary", "privacy_class" ], "decision_context": "Use when leaders need to understand whether delivery is blocked by missing context, ownership gaps, weak documentation, or architecture memory loss.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "frechet_semantic_distance", "label": "Frechet Semantic Distance", "formula": "FSD(y_q,b_q)=||mu_y-mu_b||_2^2 + Tr(Sigma_y + Sigma_b - 2(Sigma_y^(1/2) Sigma_b Sigma_y^(1/2))^(1/2))", "plain_language": "Semantic similarity should be measured by meaning, not surface phrasing.", "diagnostic_use": "Use this as a public doctrine reference for semantic matching and technical reasoning fidelity.", "required_signals": [ "approved rubric", "ideal answer blueprint", "semantic content evidence", "calibration record" ], "interpretation_rules": [ "Use semantic equivalence only inside approved evaluation or knowledge systems.", "Do not publish private transcript data or proprietary scoring parameters.", "If calibration evidence is missing, mark the semantic claim as unsupported." ] } ], "evidence_to_request_from_internal_mcp": [ "documentation system", "security classification", "AI tool policy", "identity provider" ], "minimum_evidence": [ "sensitivity class", "retrieval permission", "redaction rule", "audit requirement" ], "evidence_needed": [ "sensitivity class", "retrieval permission", "redaction rule", "audit requirement" ], "validation_signal": "Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission.", "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "metrics_signals": [ "sensitivity class", "retrieval permission", "redaction rule", "audit requirement", "Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission.", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "data_exposure", "unsafe_ai_retrieval" ], "governance_risk": [ "data_exposure", "unsafe_ai_retrieval" ], "recommended_report_type": "Agent Delegation Safety Matrix", "good_answer_pattern": "A strong answer directly answers: \"Which knowledge sources are safe for AI retrieval?\" Validation method: Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with documentation system, security classification, AI tool policy, and related approved sources. It misses the operating risk: Agentic workflows need context without exposing secrets, customer data, or sensitive records.", "answer_card_output": { "answer_type": "knowledge_memory_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission.", "Evidence from documentation system, security classification, AI tool policy, identity provider.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Agent Delegation Safety Matrix." ], "common_failure_modes": [ "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with documentation system, security classification, AI tool policy, and related approved sources. It misses the operating risk: Agentic workflows need context without exposing secrets, customer data, or sensitive records.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Agent Delegation Safety Matrix" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer knowledge-005: \"Which knowledge sources are safe for AI retrieval?\"\nUse only aggregate, redacted, or metadata level evidence from: documentation system, security classification, AI tool policy, identity provider.\nMinimum evidence to check: sensitivity class, retrieval permission, redaction rule, audit requirement.\nUse these public model references if relevant: frechet_semantic_distance.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-knowledge-006", "source_question_id": "knowledge-006", "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader", "AI Governance Leader" ], "domain": "knowledge_architecture_memory", "domain_label": "Knowledge Architecture and Memory", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#knowledge_architecture_memory", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "knowledge architecture", "architecture memory", "ownership map", "context loss", "documentation-drift", "risk", "agents", "doc_freshness", "procedure_drift" ], "decision_context": "Use when leaders need to understand whether delivery is blocked by missing context, ownership gaps, weak documentation, or architecture memory loss.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Where does documentation drift create delivery risk?", "why_it_matters": "Outdated documentation causes incorrect decisions by humans and agents.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "dependency_density", "label": "Dependency Density", "formula": "E_max = N(N-1)/2; D = E/E_max", "plain_language": "A system with N nodes can contain at most N(N-1)/2 undirected pairwise dependencies. Actual dependency density is the observed edge count divided by that bound.", "diagnostic_use": "Use this to test whether team, service, or vendor topology is creating integration cost faster than delivery value.", "required_signals": [ "service count", "team count", "interface count", "cross-service changes", "owner map", "dependency incidents" ], "interpretation_rules": [ "If dependency count grows without ownership clarity, integration risk rises.", "If service boundaries exist only on diagrams and not in code or deployment independence, classify as distributed monolith risk.", "If dependency evidence is missing, do not recommend distributed ownership." ] }, { "formula_id": "cognitive_fidelity", "label": "Cognitive Fidelity", "formula": "Quality ~ isomorphism(M_e, S_sys)", "plain_language": "Quality depends on how closely an engineer's mental model matches the actual system state.", "diagnostic_use": "Use this to evaluate whether ownership, documentation, and review systems keep human and agent contributors aligned with reality.", "required_signals": [ "architecture decision records", "documentation usage", "review comments", "rework caused by misunderstanding", "incident root cause", "agent correction rate" ], "interpretation_rules": [ "If contributors act on stale or missing system knowledge, delivery failures are knowledge failures before people failures.", "If AI outputs are correct syntactically but wrong semantically, classify the workflow as human-gated.", "If incidents repeat because lessons are not stored, knowledge memory is broken." ] } ], "evidence_to_request_from_internal_mcp": [ "documentation system", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "documented procedure", "actual procedure", "drift instance", "risk impact" ], "evidence_needed": [ "documented procedure", "actual procedure", "drift instance", "risk impact" ], "validation_signal": "Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior.", "score_dimensions": [ "Knowledge Transfer Readiness", "Execution Determinism" ], "metrics_signals": [ "documented procedure", "actual procedure", "drift instance", "risk impact", "Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior.", "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "documentation_drift", "agent_error" ], "governance_risk": [ "documentation_drift", "agent_error" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "good_answer_pattern": "A strong answer directly answers: \"Where does documentation drift create delivery risk?\" Validation method: Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with documentation system, CI/CD, deployment system, and related approved sources. It misses the operating risk: Outdated documentation causes incorrect decisions by humans and agents.", "answer_card_output": { "answer_type": "knowledge_memory_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior.", "Evidence from documentation system, CI/CD, deployment system, incident system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Knowledge and Architecture Memory Report." ], "common_failure_modes": [ "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with documentation system, CI/CD, deployment system, and related approved sources. It misses the operating risk: Outdated documentation causes incorrect decisions by humans and agents.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Knowledge and Architecture Memory Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer knowledge-006: \"Where does documentation drift create delivery risk?\"\nUse only aggregate, redacted, or metadata level evidence from: documentation system, CI/CD, deployment system, incident system.\nMinimum evidence to check: documented procedure, actual procedure, drift instance, risk impact.\nUse these public model references if relevant: dependency_density, cognitive_fidelity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-knowledge-007", "source_question_id": "knowledge-007", "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader" ], "domain": "knowledge_architecture_memory", "domain_label": "Knowledge Architecture and Memory", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#knowledge_architecture_memory", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "knowledge architecture", "architecture memory", "ownership map", "context loss", "incidents", "learning", "memory", "incident_memory", "durable_learning" ], "decision_context": "Use when leaders need to understand whether delivery is blocked by missing context, ownership gaps, weak documentation, or architecture memory loss.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "How are incidents converted into durable system memory?", "why_it_matters": "Learning requires failures to update rules, tests, runbooks, and agent instructions.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] }, { "formula_id": "strict_complementarity", "label": "Strict Complementarity", "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ] } ], "evidence_to_request_from_internal_mcp": [ "incident system", "runbooks", "test suite", "workflow rules", "agent instructions" ], "minimum_evidence": [ "incident outcome", "updated test", "updated runbook", "new workflow rule" ], "evidence_needed": [ "incident outcome", "updated test", "updated runbook", "new workflow rule" ], "validation_signal": "Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints.", "score_dimensions": [ "Knowledge Transfer Readiness", "Upside Potential" ], "metrics_signals": [ "incident outcome", "updated test", "updated runbook", "new workflow rule", "Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints.", "Knowledge Transfer Readiness", "Upside Potential" ], "risk_flags": [ "repeat_failure", "learning_gap" ], "governance_risk": [ "repeat_failure", "learning_gap" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "good_answer_pattern": "A strong answer directly answers: \"How are incidents converted into durable system memory?\" Validation method: Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with incident system, runbooks, test suite, and related approved sources. It misses the operating risk: Learning requires failures to update rules, tests, runbooks, and agent instructions.", "answer_card_output": { "answer_type": "knowledge_memory_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints.", "Evidence from incident system, runbooks, test suite, workflow rules, agent instructions.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Knowledge and Architecture Memory Report." ], "common_failure_modes": [ "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with incident system, runbooks, test suite, and related approved sources. It misses the operating risk: Learning requires failures to update rules, tests, runbooks, and agent instructions.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Knowledge and Architecture Memory Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer knowledge-007: \"How are incidents converted into durable system memory?\"\nUse only aggregate, redacted, or metadata level evidence from: incident system, runbooks, test suite, workflow rules, agent instructions.\nMinimum evidence to check: incident outcome, updated test, updated runbook, new workflow rule.\nUse these public model references if relevant: engineering_performance_function, sequential_probability_network, strict_complementarity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-knowledge-008", "source_question_id": "knowledge-008", "audience": [ "US CTO", "US CIO", "VP Engineering" ], "domain": "knowledge_architecture_memory", "domain_label": "Knowledge Architecture and Memory", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#knowledge_architecture_memory", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "knowledge architecture", "architecture memory", "ownership map", "context loss", "ownership-readiness", "distributed", "evidence", "ownership_readiness", "evidence_based_delegation" ], "decision_context": "Use when leaders need to understand whether delivery is blocked by missing context, ownership gaps, weak documentation, or architecture memory loss.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "What evidence proves a distributed contributor is ready for ownership?", "why_it_matters": "Ownership should be evidence-based, not tenure-based.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "strict_complementarity", "label": "Strict Complementarity", "formula": "p_{k+2} - p_{k+1} > p_{k+1} - p_k", "plain_language": "Improving one node creates more value when the rest of the chain is already strong. Strong people at the wrong point in a broken chain can be wasted.", "diagnostic_use": "Use this to decide whether the system needs stronger upstream architecture, better review capacity, or fewer handoffs before adding contributors.", "required_signals": [ "senior review dependency", "architecture decision age", "rework by reviewer", "handoff failure", "critical knowledge ownership" ], "interpretation_rules": [ "If senior review is the scarce multiplier, adding contributors increases queues unless review capacity changes.", "If architecture decisions are stale or missing, downstream delivery probability is capped.", "If high-skill nodes are placed after weak upstream inputs, report wasted capacity risk." ] }, { "formula_id": "l2_adjusted_score", "label": "L2 Adjusted Communication Score", "formula": "s_adj = s_raw - beta * (f_error - E[f | P])", "plain_language": "Language form errors should not be allowed to erase correct technical reasoning.", "diagnostic_use": "Use this as a public doctrine mapping for fair evaluation of distributed contributors, not as a public scoring engine.", "required_signals": [ "evaluation rubric", "technical reasoning evidence", "communication context", "review calibration", "bias control record" ], "interpretation_rules": [ "Do not use accent or grammar as a proxy for engineering capability.", "Separate reasoning quality from language surface form.", "Do not expose individual evaluation records through the public research workflow." ] }, { "formula_id": "frechet_semantic_distance", "label": "Frechet Semantic Distance", "formula": "FSD(y_q,b_q)=||mu_y-mu_b||_2^2 + Tr(Sigma_y + Sigma_b - 2(Sigma_y^(1/2) Sigma_b Sigma_y^(1/2))^(1/2))", "plain_language": "Semantic similarity should be measured by meaning, not surface phrasing.", "diagnostic_use": "Use this as a public doctrine reference for semantic matching and technical reasoning fidelity.", "required_signals": [ "approved rubric", "ideal answer blueprint", "semantic content evidence", "calibration record" ], "interpretation_rules": [ "Use semantic equivalence only inside approved evaluation or knowledge systems.", "Do not publish private transcript data or proprietary scoring parameters.", "If calibration evidence is missing, mark the semantic claim as unsupported." ] } ], "evidence_to_request_from_internal_mcp": [ "pull request system", "work tracker", "incident system", "deployment system" ], "minimum_evidence": [ "accepted work", "correction rate", "deployment success", "escalation behavior" ], "evidence_needed": [ "accepted work", "correction rate", "deployment success", "escalation behavior" ], "validation_signal": "Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior.", "score_dimensions": [ "Knowledge Transfer Readiness", "Topology Fit" ], "metrics_signals": [ "accepted work", "correction rate", "deployment success", "escalation behavior", "Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior.", "Knowledge Transfer Readiness", "Topology Fit" ], "risk_flags": [ "premature_ownership", "service_risk" ], "governance_risk": [ "premature_ownership", "service_risk" ], "recommended_report_type": "Capacity Topology Readiness Report", "good_answer_pattern": "A strong answer directly answers: \"What evidence proves a distributed contributor is ready for ownership?\" Validation method: Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Knowledge Transfer Readiness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with pull request system, work tracker, incident system, and related approved sources. It misses the operating risk: Ownership should be evidence-based, not tenure-based.", "answer_card_output": { "answer_type": "knowledge_memory_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior.", "Evidence from pull request system, work tracker, incident system, deployment system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Topology Readiness Report." ], "common_failure_modes": [ "A weak answer gives a generic knowledge architecture memory diagnosis instead of proving the research question with pull request system, work tracker, incident system, and related approved sources. It misses the operating risk: Ownership should be evidence-based, not tenure-based.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Topology Readiness Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer knowledge-008: \"What evidence proves a distributed contributor is ready for ownership?\"\nUse only aggregate, redacted, or metadata level evidence from: pull request system, work tracker, incident system, deployment system.\nMinimum evidence to check: accepted work, correction rate, deployment success, escalation behavior.\nUse these public model references if relevant: strict_complementarity, l2_adjusted_score, frechet_semantic_distance.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-execution-001", "source_question_id": "execution-001", "audience": [ "US CTO", "US CIO", "VP Engineering", "DevOps Leader" ], "domain": "execution_harness", "domain_label": "Execution Harness", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#execution_harness", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "execution harness", "SDLC control", "CI/CD governance", "deployment reproducibility", "ci-cd", "standardization", "execution", "execution_harness", "pipeline_standardization" ], "decision_context": "Use when leaders need to evaluate whether the SDLC turns commits into reproducible build, test, approval, and release outcomes.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] } ], "evidence_to_request_from_internal_mcp": [ "CI/CD", "deployment system", "repository templates", "exception logs" ], "minimum_evidence": [ "pipeline template", "required gate", "manual override", "exception frequency" ], "evidence_needed": [ "pipeline template", "required gate", "manual override", "exception frequency" ], "validation_signal": "Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency.", "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "metrics_signals": [ "pipeline template", "required gate", "manual override", "exception frequency", "Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency.", "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "pipeline_variance", "manual_override" ], "governance_risk": [ "pipeline_variance", "manual_override" ], "recommended_report_type": "Execution Determinism Report", "good_answer_pattern": "A strong answer directly answers: \"How standardized are CI/CD pipelines across teams, services, and contributor types?\" Validation method: Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, deployment system, repository templates, and related approved sources. It misses the operating risk: Distributed and AI-assisted capacity requires reproducible execution, not local delivery customs.", "answer_card_output": { "answer_type": "execution_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency.", "Evidence from CI/CD, deployment system, repository templates, exception logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Execution Determinism Report." ], "common_failure_modes": [ "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, deployment system, repository templates, and related approved sources. It misses the operating risk: Distributed and AI-assisted capacity requires reproducible execution, not local delivery customs.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Execution Determinism Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer execution-001: \"How standardized are CI/CD pipelines across teams, services, and contributor types?\"\nUse only aggregate, redacted, or metadata level evidence from: CI/CD, deployment system, repository templates, exception logs.\nMinimum evidence to check: pipeline template, required gate, manual override, exception frequency.\nUse these public model references if relevant: engineering_performance_function.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-execution-002", "source_question_id": "execution-002", "audience": [ "US CTO", "US CIO", "VP Engineering", "DevOps Leader", "Platform Leader" ], "domain": "execution_harness", "domain_label": "Execution Harness", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#execution_harness", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "execution harness", "SDLC control", "CI/CD governance", "deployment reproducibility", "variance", "delivery", "environment", "execution_variance", "environment_drift" ], "decision_context": "Use when leaders need to evaluate whether the SDLC turns commits into reproducible build, test, approval, and release outcomes.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] }, { "formula_id": "kingman_wait_time", "label": "Kingman Wait Time Approximation", "formula": "E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau", "plain_language": "As utilization approaches 100 percent, wait time explodes. Variance makes the queue worse.", "diagnostic_use": "Use this to test whether a team is actually capacity constrained or queue constrained.", "required_signals": [ "utilization proxy", "active WIP", "queue age", "cycle time", "arrival variability", "service-time variability", "blocked work" ], "interpretation_rules": [ "If utilization is high and queue age is rising, adding more work will worsen delivery.", "If task-size variance is high, normalize work before scaling capacity.", "If queue data is missing, mark telemetry as insufficient for capacity decisions." ] } ], "evidence_to_request_from_internal_mcp": [ "CI/CD", "deployment system", "work tracker", "environment inventory" ], "minimum_evidence": [ "manual step", "skipped gate", "template divergence", "environment drift" ], "evidence_needed": [ "manual step", "skipped gate", "template divergence", "environment drift" ], "validation_signal": "Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior.", "score_dimensions": [ "Execution Determinism", "Telemetry Trust" ], "metrics_signals": [ "manual step", "skipped gate", "template divergence", "environment drift", "Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior.", "Execution Determinism", "Telemetry Trust" ], "risk_flags": [ "execution_drift", "environment_drift" ], "governance_risk": [ "execution_drift", "environment_drift" ], "recommended_report_type": "Execution Determinism Report", "good_answer_pattern": "A strong answer directly answers: \"Where does execution variance enter the delivery system?\" Validation method: Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, deployment system, work tracker, and related approved sources. It misses the operating risk: Variance hides inside local workflow differences, skipped gates, environment drift, and undocumented release paths.", "answer_card_output": { "answer_type": "execution_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior.", "Evidence from CI/CD, deployment system, work tracker, environment inventory.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Execution Determinism Report." ], "common_failure_modes": [ "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, deployment system, work tracker, and related approved sources. It misses the operating risk: Variance hides inside local workflow differences, skipped gates, environment drift, and undocumented release paths.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Execution Determinism Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer execution-002: \"Where does execution variance enter the delivery system?\"\nUse only aggregate, redacted, or metadata level evidence from: CI/CD, deployment system, work tracker, environment inventory.\nMinimum evidence to check: manual step, skipped gate, template divergence, environment drift.\nUse these public model references if relevant: engineering_performance_function, sequential_probability_network, kingman_wait_time.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-execution-003", "source_question_id": "execution-003", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "DevOps Leader" ], "domain": "execution_harness", "domain_label": "Execution Harness", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#execution_harness", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "execution harness", "SDLC control", "CI/CD governance", "deployment reproducibility", "controls", "automation", "governance", "system_enforcement", "manual_control" ], "decision_context": "Use when leaders need to evaluate whether the SDLC turns commits into reproducible build, test, approval, and release outcomes.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Which SDLC controls are system-enforced versus manually enforced?", "why_it_matters": "Manual enforcement breaks under scale, distribution, and agentic speed.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "wip_rule_of_two", "label": "Rule of Two WIP Constraint", "formula": "WIP_person <= 2", "plain_language": "A contributor should not carry unlimited active work. Too much WIP hides blocked flow and destroys feedback.", "diagnostic_use": "Use this to identify false capacity created by multitasking and fragmented ownership.", "required_signals": [ "active items per contributor", "work state aging", "blocked items", "handoff count", "review waiting time" ], "interpretation_rules": [ "If contributors carry more active work than the operating limit, treat capacity as fragmented.", "If blocked work causes new work starts, the system is optimizing busyness over delivery.", "If the tracker cannot show WIP by contributor or workstream, mark telemetry incomplete." ] }, { "formula_id": "mttr_limit_behavior", "label": "MTTR Limit Behavior", "formula": "lim_{MTTR -> 0} MTBF / (MTBF + MTTR) = 1", "plain_language": "As recovery time approaches zero, availability approaches one even when failures still happen.", "diagnostic_use": "Use this to evaluate rollback, feature flags, observability, and authority delegation.", "required_signals": [ "rollback path", "feature flag coverage", "incident time to mitigation", "approval latency", "audit record" ], "interpretation_rules": [ "If mitigation requires manual escalation, MTTR is governed by authority latency, not tooling.", "If deployment and release are not separated, rollback risk is higher.", "If feature flags lack ownership and audit, they are not sufficient governance." ] } ], "evidence_to_request_from_internal_mcp": [ "CI/CD", "policy documentation", "repository settings", "approval workflow" ], "minimum_evidence": [ "control class", "automation status", "manual gate", "undocumented exception" ], "evidence_needed": [ "control class", "automation status", "manual gate", "undocumented exception" ], "validation_signal": "Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented.", "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "metrics_signals": [ "control class", "automation status", "manual gate", "undocumented exception", "Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented.", "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "manual_control_failure", "policy_drift" ], "governance_risk": [ "manual_control_failure", "policy_drift" ], "recommended_report_type": "Execution Determinism Report", "good_answer_pattern": "A strong answer directly answers: \"Which SDLC controls are system-enforced versus manually enforced?\" Validation method: Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, policy documentation, repository settings, and related approved sources. It misses the operating risk: Manual enforcement breaks under scale, distribution, and agentic speed.", "answer_card_output": { "answer_type": "execution_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented.", "Evidence from CI/CD, policy documentation, repository settings, approval workflow.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Execution Determinism Report." ], "common_failure_modes": [ "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, policy documentation, repository settings, and related approved sources. It misses the operating risk: Manual enforcement breaks under scale, distribution, and agentic speed.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Execution Determinism Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer execution-003: \"Which SDLC controls are system-enforced versus manually enforced?\"\nUse only aggregate, redacted, or metadata level evidence from: CI/CD, policy documentation, repository settings, approval workflow.\nMinimum evidence to check: control class, automation status, manual gate, undocumented exception.\nUse these public model references if relevant: wip_rule_of_two, mttr_limit_behavior.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-execution-004", "source_question_id": "execution-004", "audience": [ "US CTO", "US CIO", "VP Engineering", "DevOps Leader", "Platform Leader" ], "domain": "execution_harness", "domain_label": "Execution Harness", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#execution_harness", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "execution harness", "SDLC control", "CI/CD governance", "deployment reproducibility", "deployment", "reproducibility", "rollback", "deployment_determinism", "release_path" ], "decision_context": "Use when leaders need to evaluate whether the SDLC turns commits into reproducible build, test, approval, and release outcomes.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "How reproducible are production deployments across services?", "why_it_matters": "A topology can scale only when deployments behave as governed system states.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "availability_mttr", "label": "Availability and MTTR", "formula": "A = MTBF / (MTBF + MTTR)", "plain_language": "Availability improves when recovery time drops. Modern software systems should optimize fast recovery, not frozen change.", "diagnostic_use": "Use this to test whether engineering governance improves recovery or only slows delivery.", "required_signals": [ "deployment frequency", "change failure rate", "MTTR", "rollback duration", "incident detection time", "incident diagnosis time" ], "interpretation_rules": [ "If rollback is slow, execution governance is not production-grade.", "If MTTR improves while deployment frequency improves, governance is enabling flow.", "If incident data is missing, do not make reliability claims." ] }, { "formula_id": "mttr_limit_behavior", "label": "MTTR Limit Behavior", "formula": "lim_{MTTR -> 0} MTBF / (MTBF + MTTR) = 1", "plain_language": "As recovery time approaches zero, availability approaches one even when failures still happen.", "diagnostic_use": "Use this to evaluate rollback, feature flags, observability, and authority delegation.", "required_signals": [ "rollback path", "feature flag coverage", "incident time to mitigation", "approval latency", "audit record" ], "interpretation_rules": [ "If mitigation requires manual escalation, MTTR is governed by authority latency, not tooling.", "If deployment and release are not separated, rollback risk is higher.", "If feature flags lack ownership and audit, they are not sufficient governance." ] } ], "evidence_to_request_from_internal_mcp": [ "deployment system", "CI/CD", "environment inventory", "rollback records" ], "minimum_evidence": [ "deployment input", "approval path", "rollback record", "post-deploy outcome" ], "evidence_needed": [ "deployment input", "approval path", "rollback record", "post-deploy outcome" ], "validation_signal": "Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services.", "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "metrics_signals": [ "deployment input", "approval path", "rollback record", "post-deploy outcome", "Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services.", "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "deployment_non_reproducibility", "rollback_gap" ], "governance_risk": [ "deployment_non_reproducibility", "rollback_gap" ], "recommended_report_type": "Execution Determinism Report", "good_answer_pattern": "A strong answer directly answers: \"How reproducible are production deployments across services?\" Validation method: Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving the research question with deployment system, CI/CD, environment inventory, and related approved sources. It misses the operating risk: A topology can scale only when deployments behave as governed system states.", "answer_card_output": { "answer_type": "execution_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services.", "Evidence from deployment system, CI/CD, environment inventory, rollback records.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Execution Determinism Report." ], "common_failure_modes": [ "A weak answer gives a generic execution harness diagnosis instead of proving the research question with deployment system, CI/CD, environment inventory, and related approved sources. It misses the operating risk: A topology can scale only when deployments behave as governed system states.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Execution Determinism Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer execution-004: \"How reproducible are production deployments across services?\"\nUse only aggregate, redacted, or metadata level evidence from: deployment system, CI/CD, environment inventory, rollback records.\nMinimum evidence to check: deployment input, approval path, rollback record, post-deploy outcome.\nUse these public model references if relevant: availability_mttr, mttr_limit_behavior.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-execution-005", "source_question_id": "execution-005", "audience": [ "US CTO", "US CIO", "VP Engineering", "DevOps Leader" ], "domain": "execution_harness", "domain_label": "Execution Harness", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#execution_harness", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "execution harness", "SDLC control", "CI/CD governance", "deployment reproducibility", "pipeline-failure", "root-cause", "ci-cd", "failure_origin", "build_stage" ], "decision_context": "Use when leaders need to evaluate whether the SDLC turns commits into reproducible build, test, approval, and release outcomes.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Where do pipeline failures originate most frequently?", "why_it_matters": "Failure concentration reveals weak execution stages before capacity increases amplify them.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "availability_mttr", "label": "Availability and MTTR", "formula": "A = MTBF / (MTBF + MTTR)", "plain_language": "Availability improves when recovery time drops. Modern software systems should optimize fast recovery, not frozen change.", "diagnostic_use": "Use this to test whether engineering governance improves recovery or only slows delivery.", "required_signals": [ "deployment frequency", "change failure rate", "MTTR", "rollback duration", "incident detection time", "incident diagnosis time" ], "interpretation_rules": [ "If rollback is slow, execution governance is not production-grade.", "If MTTR improves while deployment frequency improves, governance is enabling flow.", "If incident data is missing, do not make reliability claims." ] } ], "evidence_to_request_from_internal_mcp": [ "CI/CD", "incident system", "deployment system" ], "minimum_evidence": [ "failure stage", "cause class", "recovery path", "recurrence" ], "evidence_needed": [ "failure stage", "cause class", "recovery path", "recurrence" ], "validation_signal": "Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence.", "score_dimensions": [ "Execution Determinism", "Telemetry Trust" ], "metrics_signals": [ "failure stage", "cause class", "recovery path", "recurrence", "Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence.", "Execution Determinism", "Telemetry Trust" ], "risk_flags": [ "pipeline_failure_concentration", "recovery_gap" ], "governance_risk": [ "pipeline_failure_concentration", "recovery_gap" ], "recommended_report_type": "Execution Determinism Report", "good_answer_pattern": "A strong answer directly answers: \"Where do pipeline failures originate most frequently?\" Validation method: Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, incident system, deployment system. It misses the operating risk: Failure concentration reveals weak execution stages before capacity increases amplify them.", "answer_card_output": { "answer_type": "execution_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence.", "Evidence from CI/CD, incident system, deployment system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Execution Determinism Report." ], "common_failure_modes": [ "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, incident system, deployment system. It misses the operating risk: Failure concentration reveals weak execution stages before capacity increases amplify them.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Execution Determinism Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer execution-005: \"Where do pipeline failures originate most frequently?\"\nUse only aggregate, redacted, or metadata level evidence from: CI/CD, incident system, deployment system.\nMinimum evidence to check: failure stage, cause class, recovery path, recurrence.\nUse these public model references if relevant: availability_mttr.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-execution-006", "source_question_id": "execution-006", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "DevOps Leader" ], "domain": "execution_harness", "domain_label": "Execution Harness", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#execution_harness", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "execution harness", "SDLC control", "CI/CD governance", "deployment reproducibility", "execution-rules", "ownership", "audit", "rule_owner", "execution_policy" ], "decision_context": "Use when leaders need to evaluate whether the SDLC turns commits into reproducible build, test, approval, and release outcomes.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] }, { "formula_id": "kingman_wait_time", "label": "Kingman Wait Time Approximation", "formula": "E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau", "plain_language": "As utilization approaches 100 percent, wait time explodes. Variance makes the queue worse.", "diagnostic_use": "Use this to test whether a team is actually capacity constrained or queue constrained.", "required_signals": [ "utilization proxy", "active WIP", "queue age", "cycle time", "arrival variability", "service-time variability", "blocked work" ], "interpretation_rules": [ "If utilization is high and queue age is rising, adding more work will worsen delivery.", "If task-size variance is high, normalize work before scaling capacity.", "If queue data is missing, mark telemetry as insufficient for capacity decisions." ] } ], "evidence_to_request_from_internal_mcp": [ "policy documentation", "CI/CD config", "audit logs", "change management records" ], "minimum_evidence": [ "rule owner", "approval authority", "change process", "audit record" ], "evidence_needed": [ "rule owner", "approval authority", "change process", "audit record" ], "validation_signal": "Map SDLC execution rules to owners, approval authority, change process, and audit record.", "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "metrics_signals": [ "rule owner", "approval authority", "change process", "audit record", "Map SDLC execution rules to owners, approval authority, change process, and audit record.", "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "rule_ownership_gap", "unaudited_change" ], "governance_risk": [ "rule_ownership_gap", "unaudited_change" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"Who defines and changes execution rules in the SDLC?\" Validation method: Map SDLC execution rules to owners, approval authority, change process, and audit record. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving the research question with policy documentation, CI/CD config, audit logs, and related approved sources. It misses the operating risk: Execution rule ownership is required before distributed teams or agents can safely modify workflows.", "answer_card_output": { "answer_type": "execution_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Map SDLC execution rules to owners, approval authority, change process, and audit record.", "Evidence from policy documentation, CI/CD config, audit logs, change management records.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic execution harness diagnosis instead of proving the research question with policy documentation, CI/CD config, audit logs, and related approved sources. It misses the operating risk: Execution rule ownership is required before distributed teams or agents can safely modify workflows.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer execution-006: \"Who defines and changes execution rules in the SDLC?\"\nUse only aggregate, redacted, or metadata level evidence from: policy documentation, CI/CD config, audit logs, change management records.\nMinimum evidence to check: rule owner, approval authority, change process, audit record.\nUse these public model references if relevant: engineering_performance_function, sequential_probability_network, kingman_wait_time.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-execution-007", "source_question_id": "execution-007", "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader", "DevOps Leader" ], "domain": "execution_harness", "domain_label": "Execution Harness", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#execution_harness", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "execution harness", "SDLC control", "CI/CD governance", "deployment reproducibility", "standards", "propagation", "workflow", "workflow_standard", "policy_enforcement" ], "decision_context": "Use when leaders need to evaluate whether the SDLC turns commits into reproducible build, test, approval, and release outcomes.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "How are workflow standards propagated across teams?", "why_it_matters": "Scaling requires controlled propagation of standards rather than informal copying.", "doctrine_answer_boundary": "Workflow standards propagate reliably through versioned templates, automated checks, controlled rollout, conformance telemetry, and explicit exception records rather than documentation and informal copying alone.", "math_and_model_references": [ { "formula_id": "wip_rule_of_two", "label": "Rule of Two WIP Constraint", "formula": "WIP_person <= 2", "plain_language": "A contributor should not carry unlimited active work. Too much WIP hides blocked flow and destroys feedback.", "diagnostic_use": "Use this to identify false capacity created by multitasking and fragmented ownership.", "required_signals": [ "active items per contributor", "work state aging", "blocked items", "handoff count", "review waiting time" ], "interpretation_rules": [ "If contributors carry more active work than the operating limit, treat capacity as fragmented.", "If blocked work causes new work starts, the system is optimizing busyness over delivery.", "If the tracker cannot show WIP by contributor or workstream, mark telemetry incomplete." ] } ], "evidence_to_request_from_internal_mcp": [ "repository templates", "CI/CD", "documentation", "exception logs" ], "minimum_evidence": [ "standard template", "automated check", "rollout record", "exception" ], "evidence_needed": [ "standard template", "automated check", "rollout record", "exception" ], "validation_signal": "Compare documented standards with templates, automated checks, rollout records, and exception logs.", "score_dimensions": [ "Execution Determinism", "Knowledge Transfer Readiness" ], "metrics_signals": [ "standard template", "automated check", "rollout record", "exception", "Compare documented standards with templates, automated checks, rollout records, and exception logs.", "Execution Determinism", "Knowledge Transfer Readiness" ], "risk_flags": [ "standard_drift", "local_execution_variance" ], "governance_risk": [ "standard_drift", "local_execution_variance" ], "recommended_report_type": "Execution Determinism Report", "good_answer_pattern": "A strong answer directly answers: \"How are workflow standards propagated across teams?\" Validation method: Compare documented standards with templates, automated checks, rollout records, and exception logs. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Knowledge Transfer Readiness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving the research question with repository templates, CI/CD, documentation, and related approved sources. It misses the operating risk: Scaling requires controlled propagation of standards rather than informal copying.", "answer_card_output": { "answer_type": "execution_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare documented standards with templates, automated checks, rollout records, and exception logs.", "Evidence from repository templates, CI/CD, documentation, exception logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Execution Determinism Report." ], "common_failure_modes": [ "A weak answer gives a generic execution harness diagnosis instead of proving the research question with repository templates, CI/CD, documentation, and related approved sources. It misses the operating risk: Scaling requires controlled propagation of standards rather than informal copying.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Execution Determinism Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer execution-007: \"How are workflow standards propagated across teams?\"\nUse only aggregate, redacted, or metadata level evidence from: repository templates, CI/CD, documentation, exception logs.\nMinimum evidence to check: standard template, automated check, rollout record, exception.\nUse these public model references if relevant: wip_rule_of_two.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-execution-008", "source_question_id": "execution-008", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "DevOps Leader" ], "domain": "execution_harness", "domain_label": "Execution Harness", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#execution_harness", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "execution harness", "SDLC control", "CI/CD governance", "deployment reproducibility", "cost", "pipeline", "inconsistency", "pipeline_cost", "release_risk" ], "decision_context": "Use when leaders need to evaluate whether the SDLC turns commits into reproducible build, test, approval, and release outcomes.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "What is the cost of pipeline inconsistency?", "why_it_matters": "Inconsistency converts capacity into waiting, rework, release risk, and operational overhead.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "little_law", "label": "Little's Law", "formula": "L = lambda * W", "plain_language": "Average work in progress equals throughput multiplied by time in system.", "diagnostic_use": "Use this to show why more active work can increase lead time even when people look busy.", "required_signals": [ "active WIP", "throughput", "lead time", "cycle time", "work item aging" ], "interpretation_rules": [ "If WIP rises faster than throughput, lead time must rise.", "If throughput is flat and work starts increase, the system is manufacturing delay.", "If WIP is not measured, do not claim the team has usable spare capacity." ] } ], "evidence_to_request_from_internal_mcp": [ "CI/CD", "deployment system", "work tracker", "incident system" ], "minimum_evidence": [ "cycle time by pipeline class", "failed run rate", "manual intervention", "rollback event" ], "evidence_needed": [ "cycle time by pipeline class", "failed run rate", "manual intervention", "rollback event" ], "validation_signal": "Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class.", "score_dimensions": [ "Execution Determinism", "Cost/Value/Risk Economics" ], "metrics_signals": [ "cycle time by pipeline class", "failed run rate", "manual intervention", "rollback event", "Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class.", "Execution Determinism", "Cost/Value/Risk Economics" ], "risk_flags": [ "pipeline_inconsistency_cost", "release_risk" ], "governance_risk": [ "pipeline_inconsistency_cost", "release_risk" ], "recommended_report_type": "Execution Determinism Report", "good_answer_pattern": "A strong answer directly answers: \"What is the cost of pipeline inconsistency?\" Validation method: Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Cost/Value/Risk Economics.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, deployment system, work tracker, and related approved sources. It misses the operating risk: Inconsistency converts capacity into waiting, rework, release risk, and operational overhead.", "answer_card_output": { "answer_type": "execution_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class.", "Evidence from CI/CD, deployment system, work tracker, incident system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Execution Determinism Report." ], "common_failure_modes": [ "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, deployment system, work tracker, and related approved sources. It misses the operating risk: Inconsistency converts capacity into waiting, rework, release risk, and operational overhead.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Execution Determinism Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer execution-008: \"What is the cost of pipeline inconsistency?\"\nUse only aggregate, redacted, or metadata level evidence from: CI/CD, deployment system, work tracker, incident system.\nMinimum evidence to check: cycle time by pipeline class, failed run rate, manual intervention, rollback event.\nUse these public model references if relevant: little_law.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-execution-009", "source_question_id": "execution-009", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader", "DevOps Leader" ], "domain": "execution_harness", "domain_label": "Execution Harness", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#execution_harness", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "execution harness", "SDLC control", "CI/CD governance", "deployment reproducibility", "ai", "external-contributors", "execution-path", "safe_delegation", "approval_path" ], "decision_context": "Use when leaders need to evaluate whether the SDLC turns commits into reproducible build, test, approval, and release outcomes.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "mutation_score", "label": "Mutation Score", "formula": "MS = K / (T - E)", "plain_language": "Test quality is measured by whether tests kill injected faults, not whether lines were merely executed.", "diagnostic_use": "Use this to test whether quality telemetry is meaningful enough to trust AI-generated or distributed engineering output.", "required_signals": [ "test coverage", "mutation score if available", "failed tests", "escaped defects", "review correction rate", "reverts" ], "interpretation_rules": [ "If tests do not catch injected or known defect classes, do not trust automation output.", "If quality telemetry is limited to coverage percentage, mark telemetry as weak.", "If AI-generated code bypasses mutation or regression checks, require human gating." ] } ], "evidence_to_request_from_internal_mcp": [ "CI/CD", "deployment system", "policy documentation", "audit logs" ], "minimum_evidence": [ "test reliability", "approval boundary", "production impact", "rollback readiness" ], "evidence_needed": [ "test reliability", "approval boundary", "production impact", "rollback readiness" ], "validation_signal": "Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness.", "score_dimensions": [ "Execution Determinism", "Agent Delegation Safety", "Governance Completeness" ], "metrics_signals": [ "test reliability", "approval boundary", "production impact", "rollback readiness", "Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness.", "Execution Determinism", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unsafe_execution_path", "agent_blast_radius" ], "governance_risk": [ "unsafe_execution_path", "agent_blast_radius" ], "recommended_report_type": "Agent Delegation Safety Matrix", "good_answer_pattern": "A strong answer directly answers: \"Which execution paths are safe for AI-assisted or external contributors?\" Validation method: Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, deployment system, policy documentation, and related approved sources. It misses the operating risk: Delegation safety depends on deterministic test, review, approval, deployment, and rollback paths.", "answer_card_output": { "answer_type": "execution_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness.", "Evidence from CI/CD, deployment system, policy documentation, audit logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Agent Delegation Safety Matrix." ], "common_failure_modes": [ "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, deployment system, policy documentation, and related approved sources. It misses the operating risk: Delegation safety depends on deterministic test, review, approval, deployment, and rollback paths.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Agent Delegation Safety Matrix" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer execution-009: \"Which execution paths are safe for AI-assisted or external contributors?\"\nUse only aggregate, redacted, or metadata level evidence from: CI/CD, deployment system, policy documentation, audit logs.\nMinimum evidence to check: test reliability, approval boundary, production impact, rollback readiness.\nUse these public model references if relevant: mutation_score.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-execution-010", "source_question_id": "execution-010", "audience": [ "US CTO", "US CIO", "VP Engineering", "DevOps Leader" ], "domain": "execution_harness", "domain_label": "Execution Harness", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#execution_harness", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "execution harness", "SDLC control", "CI/CD governance", "deployment reproducibility", "volume", "scaling", "execution", "delivery_volume", "execution_saturation" ], "decision_context": "Use when leaders need to evaluate whether the SDLC turns commits into reproducible build, test, approval, and release outcomes.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "sequential_probability_network", "label": "Sequential Probability Network", "formula": "P = product(p_i) for i=1..n", "plain_language": "In a sequential engineering chain, the probability of system success is multiplied across nodes. One weak upstream node can cap the entire downstream system.", "diagnostic_use": "Use this to test whether adding capacity will improve throughput or only add more weak links to a fragile chain.", "required_signals": [ "workstream sequence", "handoff count", "blocked work", "dependency wait", "review queue age", "rework by upstream source", "deployment dependency map" ], "interpretation_rules": [ "If success depends on a long chain of handoffs, capacity should be modeled as chain reliability, not seat count.", "If downstream teams are waiting on ambiguous upstream output, adding downstream contributors will not repair the constraint.", "If one service or role caps the sequence, report it as the probability ceiling." ] }, { "formula_id": "kingman_wait_time", "label": "Kingman Wait Time Approximation", "formula": "E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau", "plain_language": "As utilization approaches 100 percent, wait time explodes. Variance makes the queue worse.", "diagnostic_use": "Use this to test whether a team is actually capacity constrained or queue constrained.", "required_signals": [ "utilization proxy", "active WIP", "queue age", "cycle time", "arrival variability", "service-time variability", "blocked work" ], "interpretation_rules": [ "If utilization is high and queue age is rising, adding more work will worsen delivery.", "If task-size variance is high, normalize work before scaling capacity.", "If queue data is missing, mark telemetry as insufficient for capacity decisions." ] } ], "evidence_to_request_from_internal_mcp": [ "CI/CD", "deployment system", "pull request system", "work tracker" ], "minimum_evidence": [ "volume change", "failure rate", "queue time", "environment conflict" ], "evidence_needed": [ "volume change", "failure rate", "queue time", "environment conflict" ], "validation_signal": "Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes.", "score_dimensions": [ "Execution Determinism", "Capacity Reality" ], "metrics_signals": [ "volume change", "failure rate", "queue time", "environment conflict", "Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes.", "Execution Determinism", "Capacity Reality" ], "risk_flags": [ "volume_degradation", "execution_saturation" ], "governance_risk": [ "volume_degradation", "execution_saturation" ], "recommended_report_type": "Execution Determinism Report", "good_answer_pattern": "A strong answer directly answers: \"What breaks in execution when delivery volume increases?\" Validation method: Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Execution Determinism, Capacity Reality.", "common_failure_pattern": "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, deployment system, pull request system, and related approved sources. It misses the operating risk: Volume exposes weak gates, slow reviews, unstable environments, and fragile deployment paths.", "answer_card_output": { "answer_type": "execution_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes.", "Evidence from CI/CD, deployment system, pull request system, work tracker.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Execution Determinism Report." ], "common_failure_modes": [ "A weak answer gives a generic execution harness diagnosis instead of proving the research question with CI/CD, deployment system, pull request system, and related approved sources. It misses the operating risk: Volume exposes weak gates, slow reviews, unstable environments, and fragile deployment paths.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Execution Determinism Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer execution-010: \"What breaks in execution when delivery volume increases?\"\nUse only aggregate, redacted, or metadata level evidence from: CI/CD, deployment system, pull request system, work tracker.\nMinimum evidence to check: volume change, failure rate, queue time, environment conflict.\nUse these public model references if relevant: sequential_probability_network, kingman_wait_time.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-telemetry-001", "source_question_id": "telemetry-001", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "decision_grade_telemetry", "domain_label": "Decision Grade Telemetry", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#decision_grade_telemetry", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering telemetry", "delivery observability", "telemetry trust", "flow metrics", "telemetry", "decision-grade", "metrics", "telemetry_trust", "decision_signal" ], "decision_context": "Use when leaders need to decide whether engineering metrics are trusted enough to govern delivery, capacity, risk, and intervention timing.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "CI/CD", "deployment system", "incident system", "observability dashboards" ], "minimum_evidence": [ "metric source", "freshness", "coverage", "decision history" ], "evidence_needed": [ "metric source", "freshness", "coverage", "decision history" ], "validation_signal": "Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history.", "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "metrics_signals": [ "metric source", "freshness", "coverage", "decision history", "Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history.", "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "dashboard_noise", "low_signal_decision" ], "governance_risk": [ "dashboard_noise", "low_signal_decision" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "good_answer_pattern": "A strong answer directly answers: \"Which engineering signals are trusted enough to govern capacity topology decisions?\" Validation method: Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with work tracker, CI/CD, deployment system, and related approved sources. It misses the operating risk: Topology decisions require evidence that explains delivery behavior, not dashboard activity.", "answer_card_output": { "answer_type": "telemetry_trust_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history.", "Evidence from work tracker, CI/CD, deployment system, incident system, observability dashboards.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Engineering Capacity OS Diagnostic." ], "common_failure_modes": [ "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with work tracker, CI/CD, deployment system, and related approved sources. It misses the operating risk: Topology decisions require evidence that explains delivery behavior, not dashboard activity.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Engineering Capacity OS Diagnostic" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer telemetry-001: \"Which engineering signals are trusted enough to govern capacity topology decisions?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, CI/CD, deployment system, incident system, observability dashboards.\nMinimum evidence to check: metric source, freshness, coverage, decision history.\nUse these public model references if relevant: engineering_performance_function.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-telemetry-002", "source_question_id": "telemetry-002", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "decision_grade_telemetry", "domain_label": "Decision Grade Telemetry", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#decision_grade_telemetry", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering telemetry", "delivery observability", "telemetry trust", "flow metrics", "metrics", "outcomes", "value", "outcome_metric", "activity_metric" ], "decision_context": "Use when leaders need to decide whether engineering metrics are trusted enough to govern delivery, capacity, risk, and intervention timing.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "wage_equation", "label": "Wage Equation", "formula": "w_i^x = c / (p_n - zeta_i^x)", "plain_language": "As the incentive margin shrinks, the cost required to sustain high effort rises.", "diagnostic_use": "Use this to explain why cheap capacity can become expensive when coordination friction, review drag, and rescue work rise.", "required_signals": [ "cycle time", "review drag", "rework rate", "defect escape", "incident load", "coordination delay", "topology cost" ], "interpretation_rules": [ "If low-cost capacity creates high review drag, the system cost is not low.", "If the evidence does not include rework and delay, do not make a cost claim.", "If capacity topology changes reduce friction, treat the gain as operating leverage." ] }, { "formula_id": "little_law", "label": "Little's Law", "formula": "L = lambda * W", "plain_language": "Average work in progress equals throughput multiplied by time in system.", "diagnostic_use": "Use this to show why more active work can increase lead time even when people look busy.", "required_signals": [ "active WIP", "throughput", "lead time", "cycle time", "work item aging" ], "interpretation_rules": [ "If WIP rises faster than throughput, lead time must rise.", "If throughput is flat and work starts increase, the system is manufacturing delay.", "If WIP is not measured, do not claim the team has usable spare capacity." ] }, { "formula_id": "cost_of_delay", "label": "Cost of Delay", "formula": "CoD = dV_lost / dt = -dV_remaining / dt", "plain_language": "Cost of delay is the rate at which waiting destroys remaining value or accumulates lost value. The sign convention must be stated before comparing work.", "diagnostic_use": "Use this to prioritize work by time-sensitive value rather than loudness, politics, or activity volume.", "required_signals": [ "business milestone", "work age", "expected value", "cycle time", "blocked dependency", "release date movement" ], "interpretation_rules": [ "If business value is time-sensitive, queue age becomes economic loss.", "If work priority lacks value and time basis, do not treat priority labels as evidence.", "If telemetry cannot connect work to outcome, report missing value instrumentation." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "quality system", "incident system", "product milestones", "deployment system" ], "minimum_evidence": [ "metric correlation", "defect signal", "cycle time", "business milestone" ], "evidence_needed": [ "metric correlation", "defect signal", "cycle time", "business milestone" ], "validation_signal": "Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones.", "score_dimensions": [ "Telemetry Trust", "Cost/Value/Risk Economics" ], "metrics_signals": [ "metric correlation", "defect signal", "cycle time", "business milestone", "Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones.", "Telemetry Trust", "Cost/Value/Risk Economics" ], "risk_flags": [ "vanity_metric", "activity_bias" ], "governance_risk": [ "vanity_metric", "activity_bias" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "good_answer_pattern": "A strong answer directly answers: \"Which signals correlate with delivery success rather than activity volume?\" Validation method: Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Cost/Value/Risk Economics.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with work tracker, quality system, incident system, and related approved sources. It misses the operating risk: Activity metrics can increase while speed, quality, cost, risk, and business value degrade.", "answer_card_output": { "answer_type": "telemetry_trust_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones.", "Evidence from work tracker, quality system, incident system, product milestones, deployment system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Engineering Capacity OS Diagnostic." ], "common_failure_modes": [ "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with work tracker, quality system, incident system, and related approved sources. It misses the operating risk: Activity metrics can increase while speed, quality, cost, risk, and business value degrade.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Engineering Capacity OS Diagnostic" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer telemetry-002: \"Which signals correlate with delivery success rather than activity volume?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, quality system, incident system, product milestones, deployment system.\nMinimum evidence to check: metric correlation, defect signal, cycle time, business milestone.\nUse these public model references if relevant: wage_equation, little_law, cost_of_delay.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-telemetry-003", "source_question_id": "telemetry-003", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "Platform Leader" ], "domain": "decision_grade_telemetry", "domain_label": "Decision Grade Telemetry", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#decision_grade_telemetry", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering telemetry", "delivery observability", "telemetry trust", "flow metrics", "real-time", "visibility", "telemetry", "telemetry_freshness", "delivery_visibility" ], "decision_context": "Use when leaders need to decide whether engineering metrics are trusted enough to govern delivery, capacity, risk, and intervention timing.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "How real-time is delivery visibility for leaders?", "why_it_matters": "Slow telemetry creates delayed intervention and makes adaptive control unsafe.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "synchronization_penalty", "label": "Synchronization Penalty", "formula": "S_p = sum(T_wait + T_context_switch)", "plain_language": "Distributed work pays a penalty whenever waiting time and context switching replace direct feedback.", "diagnostic_use": "Use this to measure whether time-zone overlap, unclear ownership, or missing self-serve context is slowing the SDLC.", "required_signals": [ "wait time", "handoff delay", "blocked comments", "review latency", "time-zone overlap", "context switch count" ], "interpretation_rules": [ "If wait time is caused by missing context, add documentation or ownership before adding people.", "If time-zone overlap materially affects cycle time, topology choice must include overlap as a constraint.", "If context switching is unmeasured, report capacity as partially unknown." ] }, { "formula_id": "mttr_limit_behavior", "label": "MTTR Limit Behavior", "formula": "lim_{MTTR -> 0} MTBF / (MTBF + MTTR) = 1", "plain_language": "As recovery time approaches zero, availability approaches one even when failures still happen.", "diagnostic_use": "Use this to evaluate rollback, feature flags, observability, and authority delegation.", "required_signals": [ "rollback path", "feature flag coverage", "incident time to mitigation", "approval latency", "audit record" ], "interpretation_rules": [ "If mitigation requires manual escalation, MTTR is governed by authority latency, not tooling.", "If deployment and release are not separated, rollback risk is higher.", "If feature flags lack ownership and audit, they are not sufficient governance." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "pull request system", "CI/CD", "deployment system", "incident system", "agent tool logs" ], "minimum_evidence": [ "reporting latency", "refresh interval", "coverage gap", "stale metric" ], "evidence_needed": [ "reporting latency", "refresh interval", "coverage gap", "stale metric" ], "validation_signal": "Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions.", "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety" ], "metrics_signals": [ "reporting latency", "refresh interval", "coverage gap", "stale metric", "Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions.", "Telemetry Trust", "Agent Delegation Safety" ], "risk_flags": [ "stale_visibility", "late_intervention" ], "governance_risk": [ "stale_visibility", "late_intervention" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "good_answer_pattern": "A strong answer directly answers: \"How real-time is delivery visibility for leaders?\" Validation method: Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: Slow telemetry creates delayed intervention and makes adaptive control unsafe.", "answer_card_output": { "answer_type": "telemetry_trust_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions.", "Evidence from work tracker, pull request system, CI/CD, deployment system, incident system, agent tool logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Engineering Capacity OS Diagnostic." ], "common_failure_modes": [ "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: Slow telemetry creates delayed intervention and makes adaptive control unsafe.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Engineering Capacity OS Diagnostic" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer telemetry-003: \"How real-time is delivery visibility for leaders?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, pull request system, CI/CD, deployment system, incident system, agent tool logs.\nMinimum evidence to check: reporting latency, refresh interval, coverage gap, stale metric.\nUse these public model references if relevant: synchronization_penalty, mttr_limit_behavior.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-telemetry-004", "source_question_id": "telemetry-004", "audience": [ "US CTO", "US CIO", "VP Engineering", "Platform Leader" ], "domain": "decision_grade_telemetry", "domain_label": "Decision Grade Telemetry", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#decision_grade_telemetry", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering telemetry", "delivery observability", "telemetry trust", "flow metrics", "queues", "dashboard", "visibility", "hidden_queue", "queue_time" ], "decision_context": "Use when leaders need to decide whether engineering metrics are trusted enough to govern delivery, capacity, risk, and intervention timing.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Where are queues invisible to current dashboards?", "why_it_matters": "Hidden queues are a common cause of false capacity conclusions.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "kingman_wait_time", "label": "Kingman Wait Time Approximation", "formula": "E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau", "plain_language": "As utilization approaches 100 percent, wait time explodes. Variance makes the queue worse.", "diagnostic_use": "Use this to test whether a team is actually capacity constrained or queue constrained.", "required_signals": [ "utilization proxy", "active WIP", "queue age", "cycle time", "arrival variability", "service-time variability", "blocked work" ], "interpretation_rules": [ "If utilization is high and queue age is rising, adding more work will worsen delivery.", "If task-size variance is high, normalize work before scaling capacity.", "If queue data is missing, mark telemetry as insufficient for capacity decisions." ] }, { "formula_id": "little_law", "label": "Little's Law", "formula": "L = lambda * W", "plain_language": "Average work in progress equals throughput multiplied by time in system.", "diagnostic_use": "Use this to show why more active work can increase lead time even when people look busy.", "required_signals": [ "active WIP", "throughput", "lead time", "cycle time", "work item aging" ], "interpretation_rules": [ "If WIP rises faster than throughput, lead time must rise.", "If throughput is flat and work starts increase, the system is manufacturing delay.", "If WIP is not measured, do not claim the team has usable spare capacity." ] }, { "formula_id": "synchronization_penalty", "label": "Synchronization Penalty", "formula": "S_p = sum(T_wait + T_context_switch)", "plain_language": "Distributed work pays a penalty whenever waiting time and context switching replace direct feedback.", "diagnostic_use": "Use this to measure whether time-zone overlap, unclear ownership, or missing self-serve context is slowing the SDLC.", "required_signals": [ "wait time", "handoff delay", "blocked comments", "review latency", "time-zone overlap", "context switch count" ], "interpretation_rules": [ "If wait time is caused by missing context, add documentation or ownership before adding people.", "If time-zone overlap materially affects cycle time, topology choice must include overlap as a constraint.", "If context switching is unmeasured, report capacity as partially unknown." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "pull request system", "approval workflow", "incident system" ], "minimum_evidence": [ "hidden wait", "approval wait", "dependency wait", "dashboard coverage" ], "evidence_needed": [ "hidden wait", "approval wait", "dependency wait", "dashboard coverage" ], "validation_signal": "Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage.", "score_dimensions": [ "Telemetry Trust", "Capacity Reality" ], "metrics_signals": [ "hidden wait", "approval wait", "dependency wait", "dashboard coverage", "Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage.", "Telemetry Trust", "Capacity Reality" ], "risk_flags": [ "hidden_queue", "misdiagnosed_capacity" ], "governance_risk": [ "hidden_queue", "misdiagnosed_capacity" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "good_answer_pattern": "A strong answer directly answers: \"Where are queues invisible to current dashboards?\" Validation method: Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Capacity Reality.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with work tracker, pull request system, approval workflow, and related approved sources. It misses the operating risk: Hidden queues are a common cause of false capacity conclusions.", "answer_card_output": { "answer_type": "telemetry_trust_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage.", "Evidence from work tracker, pull request system, approval workflow, incident system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Engineering Capacity OS Diagnostic." ], "common_failure_modes": [ "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with work tracker, pull request system, approval workflow, and related approved sources. It misses the operating risk: Hidden queues are a common cause of false capacity conclusions.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Engineering Capacity OS Diagnostic" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer telemetry-004: \"Where are queues invisible to current dashboards?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, pull request system, approval workflow, incident system.\nMinimum evidence to check: hidden wait, approval wait, dependency wait, dashboard coverage.\nUse these public model references if relevant: kingman_wait_time, little_law, synchronization_penalty.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-telemetry-005", "source_question_id": "telemetry-005", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "decision_grade_telemetry", "domain_label": "Decision Grade Telemetry", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#decision_grade_telemetry", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering telemetry", "delivery observability", "telemetry trust", "flow metrics", "quality", "degradation", "ai", "quality_signal", "degradation_detection" ], "decision_context": "Use when leaders need to decide whether engineering metrics are trusted enough to govern delivery, capacity, risk, and intervention timing.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "availability_mttr", "label": "Availability and MTTR", "formula": "A = MTBF / (MTBF + MTTR)", "plain_language": "Availability improves when recovery time drops. Modern software systems should optimize fast recovery, not frozen change.", "diagnostic_use": "Use this to test whether engineering governance improves recovery or only slows delivery.", "required_signals": [ "deployment frequency", "change failure rate", "MTTR", "rollback duration", "incident detection time", "incident diagnosis time" ], "interpretation_rules": [ "If rollback is slow, execution governance is not production-grade.", "If MTTR improves while deployment frequency improves, governance is enabling flow.", "If incident data is missing, do not make reliability claims." ] }, { "formula_id": "mttr_limit_behavior", "label": "MTTR Limit Behavior", "formula": "lim_{MTTR -> 0} MTBF / (MTBF + MTTR) = 1", "plain_language": "As recovery time approaches zero, availability approaches one even when failures still happen.", "diagnostic_use": "Use this to evaluate rollback, feature flags, observability, and authority delegation.", "required_signals": [ "rollback path", "feature flag coverage", "incident time to mitigation", "approval latency", "audit record" ], "interpretation_rules": [ "If mitigation requires manual escalation, MTTR is governed by authority latency, not tooling.", "If deployment and release are not separated, rollback risk is higher.", "If feature flags lack ownership and audit, they are not sufficient governance." ] }, { "formula_id": "mutation_score", "label": "Mutation Score", "formula": "MS = K / (T - E)", "plain_language": "Test quality is measured by whether tests kill injected faults, not whether lines were merely executed.", "diagnostic_use": "Use this to test whether quality telemetry is meaningful enough to trust AI-generated or distributed engineering output.", "required_signals": [ "test coverage", "mutation score if available", "failed tests", "escaped defects", "review correction rate", "reverts" ], "interpretation_rules": [ "If tests do not catch injected or known defect classes, do not trust automation output.", "If quality telemetry is limited to coverage percentage, mark telemetry as weak.", "If AI-generated code bypasses mutation or regression checks, require human gating." ] } ], "evidence_to_request_from_internal_mcp": [ "quality system", "pull request system", "CI/CD", "incident system", "deployment system" ], "minimum_evidence": [ "defect escape", "review correction", "revert", "rollback", "incident" ], "evidence_needed": [ "defect escape", "review correction", "revert", "rollback", "incident" ], "validation_signal": "Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change.", "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Cost/Value/Risk Economics" ], "metrics_signals": [ "defect escape", "review correction", "revert", "rollback", "incident", "Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change.", "Telemetry Trust", "Agent Delegation Safety", "Cost/Value/Risk Economics" ], "risk_flags": [ "quality_degradation", "ai_rework" ], "governance_risk": [ "quality_degradation", "ai_rework" ], "recommended_report_type": "Agent Delegation Safety Matrix", "good_answer_pattern": "A strong answer directly answers: \"Which telemetry detects quality degradation after capacity, topology, or AI changes?\" Validation method: Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety, Cost/Value/Risk Economics.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with quality system, pull request system, CI/CD, and related approved sources. It misses the operating risk: A capacity intervention is weak if it increases speed while degrading quality or risk.", "answer_card_output": { "answer_type": "telemetry_trust_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change.", "Evidence from quality system, pull request system, CI/CD, incident system, deployment system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Agent Delegation Safety Matrix." ], "common_failure_modes": [ "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with quality system, pull request system, CI/CD, and related approved sources. It misses the operating risk: A capacity intervention is weak if it increases speed while degrading quality or risk.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Agent Delegation Safety Matrix" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer telemetry-005: \"Which telemetry detects quality degradation after capacity, topology, or AI changes?\"\nUse only aggregate, redacted, or metadata level evidence from: quality system, pull request system, CI/CD, incident system, deployment system.\nMinimum evidence to check: defect escape, review correction, revert, rollback, incident.\nUse these public model references if relevant: availability_mttr, mttr_limit_behavior, mutation_score.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-telemetry-006", "source_question_id": "telemetry-006", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "decision_grade_telemetry", "domain_label": "Decision Grade Telemetry", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#decision_grade_telemetry", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering telemetry", "delivery observability", "telemetry trust", "flow metrics", "privacy", "topology", "benchmark", "aggregate_telemetry", "privacy_boundary" ], "decision_context": "Use when leaders need to decide whether engineering metrics are trusted enough to govern delivery, capacity, risk, and intervention timing.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "Topology performance should be compared with aggregated workstream or team-level flow, quality, deployment, incident, and rework signals, never individual surveillance or employee ranking.", "math_and_model_references": [ { "formula_id": "wage_equation", "label": "Wage Equation", "formula": "w_i^x = c / (p_n - zeta_i^x)", "plain_language": "As the incentive margin shrinks, the cost required to sustain high effort rises.", "diagnostic_use": "Use this to explain why cheap capacity can become expensive when coordination friction, review drag, and rescue work rise.", "required_signals": [ "cycle time", "review drag", "rework rate", "defect escape", "incident load", "coordination delay", "topology cost" ], "interpretation_rules": [ "If low-cost capacity creates high review drag, the system cost is not low.", "If the evidence does not include rework and delay, do not make a cost claim.", "If capacity topology changes reduce friction, treat the gain as operating leverage." ] }, { "formula_id": "kingman_wait_time", "label": "Kingman Wait Time Approximation", "formula": "E[W_q] approx (rho / (1-rho)) * ((C_a^2 + C_s^2) / 2) * tau", "plain_language": "As utilization approaches 100 percent, wait time explodes. Variance makes the queue worse.", "diagnostic_use": "Use this to test whether a team is actually capacity constrained or queue constrained.", "required_signals": [ "utilization proxy", "active WIP", "queue age", "cycle time", "arrival variability", "service-time variability", "blocked work" ], "interpretation_rules": [ "If utilization is high and queue age is rising, adding more work will worsen delivery.", "If task-size variance is high, normalize work before scaling capacity.", "If queue data is missing, mark telemetry as insufficient for capacity decisions." ] }, { "formula_id": "engineering_throughput_equation", "label": "Engineering Throughput Equation", "formula": "Throughput = f(Topology, Cognitive Load, Coordination Cost, AI Assistance)", "plain_language": "Throughput is shaped by team topology, cognitive load, coordination cost, and bounded AI assistance, not headcount alone.", "diagnostic_use": "Use this as the bridge between doctrine math and the Engineering Capacity OS capacity topology questions.", "required_signals": [ "team topology", "active WIP", "context switching", "coordination delay", "agent usage", "cycle time", "quality signal" ], "interpretation_rules": [ "If throughput gains come with higher rework or risk, do not report a capacity improvement.", "If AI assistance lowers cognitive load and review drag, classify the workflow as promising but still governed.", "If topology and coordination cost are unknown, throughput claims are unsupported." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "aggregate cycle time", "team-level queue time", "topology class", "defect rate" ], "evidence_needed": [ "aggregate cycle time", "team-level queue time", "topology class", "defect rate" ], "validation_signal": "Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology.", "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "metrics_signals": [ "aggregate cycle time", "team-level queue time", "topology class", "defect rate", "Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology.", "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "privacy_violation", "bad_benchmark" ], "governance_risk": [ "privacy_violation", "bad_benchmark" ], "recommended_report_type": "Capacity Topology Readiness Report", "good_answer_pattern": "A strong answer directly answers: \"What telemetry compares topology performance without exposing individual employee data?\" Validation method: Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with work tracker, CI/CD, deployment system, and related approved sources. It misses the operating risk: Leaders need topology evidence while avoiding surveillance and individual performance misuse.", "answer_card_output": { "answer_type": "telemetry_trust_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology.", "Evidence from work tracker, CI/CD, deployment system, incident system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Capacity Topology Readiness Report." ], "common_failure_modes": [ "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with work tracker, CI/CD, deployment system, and related approved sources. It misses the operating risk: Leaders need topology evidence while avoiding surveillance and individual performance misuse.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Capacity Topology Readiness Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer telemetry-006: \"What telemetry compares topology performance without exposing individual employee data?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, CI/CD, deployment system, incident system.\nMinimum evidence to check: aggregate cycle time, team-level queue time, topology class, defect rate.\nUse these public model references if relevant: wage_equation, kingman_wait_time, engineering_throughput_equation.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-telemetry-007", "source_question_id": "telemetry-007", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "decision_grade_telemetry", "domain_label": "Decision Grade Telemetry", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#decision_grade_telemetry", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering telemetry", "delivery observability", "telemetry trust", "flow metrics", "governance", "automation", "stop-condition", "stop_condition", "governance_trigger" ], "decision_context": "Use when leaders need to decide whether engineering metrics are trusted enough to govern delivery, capacity, risk, and intervention timing.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "agentic_intervention_load", "label": "Agentic Intervention Load", "formula": "Intervention Load Hours = Agent Execution Volume * Error Rate * Mean Human Repair Time + Context Switching Hours", "plain_language": "Agent speed is not free. Convert agent errors and context switching into the same human-time unit before comparing agent execution volume with orchestration capacity.", "diagnostic_use": "Use this to decide whether an agentic workflow is increasing throughput or overloading human orchestrators.", "required_signals": [ "agent execution volume", "agent error rate", "human review load", "correction rate", "context switching", "cycle-time impact", "rollback triggers" ], "interpretation_rules": [ "If intervention load exceeds human orchestration capacity, throttle agent execution.", "If agent velocity increases review queues, do not classify the workflow as successful automation.", "If error rate is unknown, keep the workflow human-gated." ] } ], "evidence_to_request_from_internal_mcp": [ "agent tool logs", "CI/CD", "policy exception logs", "incident system", "pull request system" ], "minimum_evidence": [ "validation failure threshold", "human override rate", "policy exception", "quality drift" ], "evidence_needed": [ "validation failure threshold", "human override rate", "policy exception", "quality drift" ], "validation_signal": "Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift.", "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Governance Completeness" ], "metrics_signals": [ "validation failure threshold", "human override rate", "policy exception", "quality drift", "Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift.", "Telemetry Trust", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "automation_without_stop_condition", "recursive_degradation" ], "governance_risk": [ "automation_without_stop_condition", "recursive_degradation" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"Which metrics should trigger governance review before scaling automation?\" Validation method: Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with agent tool logs, CI/CD, policy exception logs, and related approved sources. It misses the operating risk: Agentic and adaptive systems need stop conditions before local optimizations harm global performance.", "answer_card_output": { "answer_type": "telemetry_trust_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift.", "Evidence from agent tool logs, CI/CD, policy exception logs, incident system, pull request system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with agent tool logs, CI/CD, policy exception logs, and related approved sources. It misses the operating risk: Agentic and adaptive systems need stop conditions before local optimizations harm global performance.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer telemetry-007: \"Which metrics should trigger governance review before scaling automation?\"\nUse only aggregate, redacted, or metadata level evidence from: agent tool logs, CI/CD, policy exception logs, incident system, pull request system.\nMinimum evidence to check: validation failure threshold, human override rate, policy exception, quality drift.\nUse these public model references if relevant: agentic_intervention_load.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-telemetry-008", "source_question_id": "telemetry-008", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO" ], "domain": "decision_grade_telemetry", "domain_label": "Decision Grade Telemetry", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#decision_grade_telemetry", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering telemetry", "delivery observability", "telemetry trust", "flow metrics", "missing-data", "confidence", "instrumentation", "unknown_evidence", "confidence_tier" ], "decision_context": "Use when leaders need to decide whether engineering metrics are trusted enough to govern delivery, capacity, risk, and intervention timing.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "cost_of_delay", "label": "Cost of Delay", "formula": "CoD = dV_lost / dt = -dV_remaining / dt", "plain_language": "Cost of delay is the rate at which waiting destroys remaining value or accumulates lost value. The sign convention must be stated before comparing work.", "diagnostic_use": "Use this to prioritize work by time-sensitive value rather than loudness, politics, or activity volume.", "required_signals": [ "business milestone", "work age", "expected value", "cycle time", "blocked dependency", "release date movement" ], "interpretation_rules": [ "If business value is time-sensitive, queue age becomes economic loss.", "If work priority lacks value and time basis, do not treat priority labels as evidence.", "If telemetry cannot connect work to outcome, report missing value instrumentation." ] } ], "evidence_to_request_from_internal_mcp": [ "research question evidence inventory", "metric catalog", "source-system inventory" ], "minimum_evidence": [ "required evidence", "available evidence", "missing instrumentation", "confidence tier" ], "evidence_needed": [ "required evidence", "available evidence", "missing instrumentation", "confidence tier" ], "validation_signal": "Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation.", "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "metrics_signals": [ "required evidence", "available evidence", "missing instrumentation", "confidence tier", "Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation.", "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "false_confidence", "missing_instrumentation" ], "governance_risk": [ "false_confidence", "missing_instrumentation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "good_answer_pattern": "A strong answer directly answers: \"Which signals are missing but necessary for the next operating decision?\" Validation method: Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with research question evidence inventory, metric catalog, source-system inventory. It misses the operating risk: A responsible model should mark unknowns instead of inventing certainty.", "answer_card_output": { "answer_type": "telemetry_trust_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation.", "Evidence from research question evidence inventory, metric catalog, source-system inventory.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Engineering Capacity OS Diagnostic." ], "common_failure_modes": [ "A weak answer gives a generic decision grade telemetry diagnosis instead of proving the research question with research question evidence inventory, metric catalog, source-system inventory. It misses the operating risk: A responsible model should mark unknowns instead of inventing certainty.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Engineering Capacity OS Diagnostic" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer telemetry-008: \"Which signals are missing but necessary for the next operating decision?\"\nUse only aggregate, redacted, or metadata level evidence from: research question evidence inventory, metric catalog, source-system inventory.\nMinimum evidence to check: required evidence, available evidence, missing instrumentation, confidence tier.\nUse these public model references if relevant: cost_of_delay.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-agent-001", "source_question_id": "agent-001", "audience": [ "US CTO", "US CIO", "VP Engineering", "AI Governance Leader" ], "domain": "governed_agentic_sdlc", "domain_label": "Governed Agentic SDLC", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governed_agentic_sdlc", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "AI-governed software delivery", "agent workflow safety", "human approval", "agents", "onboarding", "distributed", "agentic_onboarding", "context_acquisition" ], "decision_context": "Use when leaders need to decide which engineering workflows AI agents can safely execute under human, technical, and policy constraints.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "replacement_kinetics_derivative", "label": "Replacement Kinetics Derivative", "formula": "partial C / partial x_i = Direct Savings - Incentive Distortion", "plain_language": "Replacing or automating a position creates direct savings only if it does not distort incentives and coordination around the rest of the chain.", "diagnostic_use": "Use this to decide whether AI should automate a workflow, augment it, or stay outside the approval path.", "required_signals": [ "workflow step position", "blast radius", "human approval path", "agent error rate", "review correction rate", "rollback evidence" ], "interpretation_rules": [ "End-of-chain validation tasks are more automation tolerant than middle-of-chain architecture decisions.", "If automation removes a human signal needed by other contributors, classify it as protected or human-gated.", "If rollback is missing, do not mark the workflow as safe for adaptive change." ] }, { "formula_id": "agentic_intervention_load", "label": "Agentic Intervention Load", "formula": "Intervention Load Hours = Agent Execution Volume * Error Rate * Mean Human Repair Time + Context Switching Hours", "plain_language": "Agent speed is not free. Convert agent errors and context switching into the same human-time unit before comparing agent execution volume with orchestration capacity.", "diagnostic_use": "Use this to decide whether an agentic workflow is increasing throughput or overloading human orchestrators.", "required_signals": [ "agent execution volume", "agent error rate", "human review load", "correction rate", "context switching", "cycle-time impact", "rollback triggers" ], "interpretation_rules": [ "If intervention load exceeds human orchestration capacity, throttle agent execution.", "If agent velocity increases review queues, do not classify the workflow as successful automation.", "If error rate is unknown, keep the workflow human-gated." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "pull request system", "documentation analytics", "agent tool logs" ], "minimum_evidence": [ "onboarding duration", "first accepted PR", "documentation usage", "correction rate" ], "evidence_needed": [ "onboarding duration", "first accepted PR", "documentation usage", "correction rate" ], "validation_signal": "Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency.", "score_dimensions": [ "Agent Delegation Safety", "Knowledge Transfer Readiness" ], "metrics_signals": [ "onboarding duration", "first accepted PR", "documentation usage", "correction rate", "Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency.", "Agent Delegation Safety", "Knowledge Transfer Readiness" ], "risk_flags": [ "ai_context_error", "rework_increase" ], "governance_risk": [ "ai_context_error", "rework_increase" ], "recommended_report_type": "Agent Delegation Safety Matrix", "good_answer_pattern": "A strong answer directly answers: \"Which agentic workflows reduce onboarding time for distributed contributors?\" Validation method: Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Knowledge Transfer Readiness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with work tracker, pull request system, documentation analytics, and related approved sources. It misses the operating risk: AI can improve capacity only if it reduces context acquisition cost without increasing rework.", "answer_card_output": { "answer_type": "agent_delegation_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency.", "Evidence from work tracker, pull request system, documentation analytics, agent tool logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Agent Delegation Safety Matrix." ], "common_failure_modes": [ "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with work tracker, pull request system, documentation analytics, and related approved sources. It misses the operating risk: AI can improve capacity only if it reduces context acquisition cost without increasing rework.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Agent Delegation Safety Matrix" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer agent-001: \"Which agentic workflows reduce onboarding time for distributed contributors?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, pull request system, documentation analytics, agent tool logs.\nMinimum evidence to check: onboarding duration, first accepted PR, documentation usage, correction rate.\nUse these public model references if relevant: engineering_performance_function, replacement_kinetics_derivative, agentic_intervention_load.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-agent-002", "source_question_id": "agent-002", "audience": [ "US CTO", "US CIO", "VP Engineering", "AI Governance Leader" ], "domain": "governed_agentic_sdlc", "domain_label": "Governed Agentic SDLC", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governed_agentic_sdlc", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "AI-governed software delivery", "agent workflow safety", "human approval", "ai-output", "validation", "distributed", "validation_authority", "blast_radius" ], "decision_context": "Use when leaders need to decide which engineering workflows AI agents can safely execute under human, technical, and policy constraints.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Which AI-generated outputs can distributed teams safely validate?", "why_it_matters": "Validation authority must match skill, context, and risk.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "replacement_kinetics_derivative", "label": "Replacement Kinetics Derivative", "formula": "partial C / partial x_i = Direct Savings - Incentive Distortion", "plain_language": "Replacing or automating a position creates direct savings only if it does not distort incentives and coordination around the rest of the chain.", "diagnostic_use": "Use this to decide whether AI should automate a workflow, augment it, or stay outside the approval path.", "required_signals": [ "workflow step position", "blast radius", "human approval path", "agent error rate", "review correction rate", "rollback evidence" ], "interpretation_rules": [ "End-of-chain validation tasks are more automation tolerant than middle-of-chain architecture decisions.", "If automation removes a human signal needed by other contributors, classify it as protected or human-gated.", "If rollback is missing, do not mark the workflow as safe for adaptive change." ] }, { "formula_id": "mutation_score", "label": "Mutation Score", "formula": "MS = K / (T - E)", "plain_language": "Test quality is measured by whether tests kill injected faults, not whether lines were merely executed.", "diagnostic_use": "Use this to test whether quality telemetry is meaningful enough to trust AI-generated or distributed engineering output.", "required_signals": [ "test coverage", "mutation score if available", "failed tests", "escaped defects", "review correction rate", "reverts" ], "interpretation_rules": [ "If tests do not catch injected or known defect classes, do not trust automation output.", "If quality telemetry is limited to coverage percentage, mark telemetry as weak.", "If AI-generated code bypasses mutation or regression checks, require human gating." ] }, { "formula_id": "cognitive_fidelity", "label": "Cognitive Fidelity", "formula": "Quality ~ isomorphism(M_e, S_sys)", "plain_language": "Quality depends on how closely an engineer's mental model matches the actual system state.", "diagnostic_use": "Use this to evaluate whether ownership, documentation, and review systems keep human and agent contributors aligned with reality.", "required_signals": [ "architecture decision records", "documentation usage", "review comments", "rework caused by misunderstanding", "incident root cause", "agent correction rate" ], "interpretation_rules": [ "If contributors act on stale or missing system knowledge, delivery failures are knowledge failures before people failures.", "If AI outputs are correct syntactically but wrong semantically, classify the workflow as human-gated.", "If incidents repeat because lessons are not stored, knowledge memory is broken." ] } ], "evidence_to_request_from_internal_mcp": [ "agent tool logs", "pull request system", "CI/CD", "approval workflow" ], "minimum_evidence": [ "output type", "reversibility", "test coverage", "approval path" ], "evidence_needed": [ "output type", "reversibility", "test coverage", "approval path" ], "validation_signal": "Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path.", "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "metrics_signals": [ "output type", "reversibility", "test coverage", "approval path", "Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path.", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "validation_authority_gap", "agent_blast_radius" ], "governance_risk": [ "validation_authority_gap", "agent_blast_radius" ], "recommended_report_type": "Agent Delegation Safety Matrix", "good_answer_pattern": "A strong answer directly answers: \"Which AI-generated outputs can distributed teams safely validate?\" Validation method: Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with agent tool logs, pull request system, CI/CD, and related approved sources. It misses the operating risk: Validation authority must match skill, context, and risk.", "answer_card_output": { "answer_type": "agent_delegation_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path.", "Evidence from agent tool logs, pull request system, CI/CD, approval workflow.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Agent Delegation Safety Matrix." ], "common_failure_modes": [ "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with agent tool logs, pull request system, CI/CD, and related approved sources. It misses the operating risk: Validation authority must match skill, context, and risk.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Agent Delegation Safety Matrix" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer agent-002: \"Which AI-generated outputs can distributed teams safely validate?\"\nUse only aggregate, redacted, or metadata level evidence from: agent tool logs, pull request system, CI/CD, approval workflow.\nMinimum evidence to check: output type, reversibility, test coverage, approval path.\nUse these public model references if relevant: replacement_kinetics_derivative, mutation_score, cognitive_fidelity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-agent-003", "source_question_id": "agent-003", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "governed_agentic_sdlc", "domain_label": "Governed Agentic SDLC", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governed_agentic_sdlc", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "AI-governed software delivery", "agent workflow safety", "human approval", "ai-tools", "contributors", "policy", "tool_permission", "prompt_policy" ], "decision_context": "Use when leaders need to decide which engineering workflows AI agents can safely execute under human, technical, and policy constraints.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Which AI tools are allowed for each contributor type?", "why_it_matters": "AI usage creates data exposure, IP, and governance risk.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "shirking_margin_zeta", "label": "Shirking Margin", "formula": "zeta_i^x = P(project succeeds | e_i=0, policy x)", "plain_language": "Zeta measures how safe a contributor feels when they do not apply full effort. If the system hides weak effort behind downstream rescue, incentive quality degrades.", "diagnostic_use": "Use this to test whether AI, QA, senior rescue, or vendor buffering is hiding low-quality upstream work.", "required_signals": [ "review correction rate", "reopened work", "QA rescue count", "senior rescue count", "agent-generated rework", "approval override history" ], "interpretation_rules": [ "If downstream rescue repeatedly masks upstream defects, do not treat delivered work as healthy capacity.", "If agent output lowers effort discipline, require stronger validation and ownership boundaries.", "If responsibility is unclear, classify the risk as governance failure before capacity failure." ] }, { "formula_id": "replacement_kinetics_derivative", "label": "Replacement Kinetics Derivative", "formula": "partial C / partial x_i = Direct Savings - Incentive Distortion", "plain_language": "Replacing or automating a position creates direct savings only if it does not distort incentives and coordination around the rest of the chain.", "diagnostic_use": "Use this to decide whether AI should automate a workflow, augment it, or stay outside the approval path.", "required_signals": [ "workflow step position", "blast radius", "human approval path", "agent error rate", "review correction rate", "rollback evidence" ], "interpretation_rules": [ "End-of-chain validation tasks are more automation tolerant than middle-of-chain architecture decisions.", "If automation removes a human signal needed by other contributors, classify it as protected or human-gated.", "If rollback is missing, do not mark the workflow as safe for adaptive change." ] } ], "evidence_to_request_from_internal_mcp": [ "AI tool policy", "identity provider", "repository permissions", "audit logs" ], "minimum_evidence": [ "approved tool", "data class", "access class", "audit requirement" ], "evidence_needed": [ "approved tool", "data class", "access class", "audit requirement" ], "validation_signal": "Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements.", "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "metrics_signals": [ "approved tool", "data class", "access class", "audit requirement", "Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements.", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unauthorized_ai_tool", "data_exposure" ], "governance_risk": [ "unauthorized_ai_tool", "data_exposure" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"Which AI tools are allowed for each contributor type?\" Validation method: Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with AI tool policy, identity provider, repository permissions, and related approved sources. It misses the operating risk: AI usage creates data exposure, IP, and governance risk.", "answer_card_output": { "answer_type": "agent_delegation_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements.", "Evidence from AI tool policy, identity provider, repository permissions, audit logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with AI tool policy, identity provider, repository permissions, and related approved sources. It misses the operating risk: AI usage creates data exposure, IP, and governance risk.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer agent-003: \"Which AI tools are allowed for each contributor type?\"\nUse only aggregate, redacted, or metadata level evidence from: AI tool policy, identity provider, repository permissions, audit logs.\nMinimum evidence to check: approved tool, data class, access class, audit requirement.\nUse these public model references if relevant: engineering_performance_function, shirking_margin_zeta, replacement_kinetics_derivative.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-agent-004", "source_question_id": "agent-004", "audience": [ "US CTO", "US CIO", "VP Engineering", "AI Governance Leader" ], "domain": "governed_agentic_sdlc", "domain_label": "Governed Agentic SDLC", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governed_agentic_sdlc", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "AI-governed software delivery", "agent workflow safety", "human approval", "ai-pr", "review", "provenance", "pr_provenance", "review_policy" ], "decision_context": "Use when leaders need to decide which engineering workflows AI agents can safely execute under human, technical, and policy constraints.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "How are AI-generated PRs reviewed across distributed teams?", "why_it_matters": "AI can increase review burden if review policy is unclear.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "shirking_margin_zeta", "label": "Shirking Margin", "formula": "zeta_i^x = P(project succeeds | e_i=0, policy x)", "plain_language": "Zeta measures how safe a contributor feels when they do not apply full effort. If the system hides weak effort behind downstream rescue, incentive quality degrades.", "diagnostic_use": "Use this to test whether AI, QA, senior rescue, or vendor buffering is hiding low-quality upstream work.", "required_signals": [ "review correction rate", "reopened work", "QA rescue count", "senior rescue count", "agent-generated rework", "approval override history" ], "interpretation_rules": [ "If downstream rescue repeatedly masks upstream defects, do not treat delivered work as healthy capacity.", "If agent output lowers effort discipline, require stronger validation and ownership boundaries.", "If responsibility is unclear, classify the risk as governance failure before capacity failure." ] }, { "formula_id": "mutation_score", "label": "Mutation Score", "formula": "MS = K / (T - E)", "plain_language": "Test quality is measured by whether tests kill injected faults, not whether lines were merely executed.", "diagnostic_use": "Use this to test whether quality telemetry is meaningful enough to trust AI-generated or distributed engineering output.", "required_signals": [ "test coverage", "mutation score if available", "failed tests", "escaped defects", "review correction rate", "reverts" ], "interpretation_rules": [ "If tests do not catch injected or known defect classes, do not trust automation output.", "If quality telemetry is limited to coverage percentage, mark telemetry as weak.", "If AI-generated code bypasses mutation or regression checks, require human gating." ] }, { "formula_id": "agentic_intervention_load", "label": "Agentic Intervention Load", "formula": "Intervention Load Hours = Agent Execution Volume * Error Rate * Mean Human Repair Time + Context Switching Hours", "plain_language": "Agent speed is not free. Convert agent errors and context switching into the same human-time unit before comparing agent execution volume with orchestration capacity.", "diagnostic_use": "Use this to decide whether an agentic workflow is increasing throughput or overloading human orchestrators.", "required_signals": [ "agent execution volume", "agent error rate", "human review load", "correction rate", "context switching", "cycle-time impact", "rollback triggers" ], "interpretation_rules": [ "If intervention load exceeds human orchestration capacity, throttle agent execution.", "If agent velocity increases review queues, do not classify the workflow as successful automation.", "If error rate is unknown, keep the workflow human-gated." ] } ], "evidence_to_request_from_internal_mcp": [ "pull request system", "agent tool logs", "CI/CD", "approval workflow" ], "minimum_evidence": [ "PR provenance", "review path", "correction rate", "test evidence" ], "evidence_needed": [ "PR provenance", "review path", "correction rate", "test evidence" ], "validation_signal": "Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence.", "score_dimensions": [ "Agent Delegation Safety", "Execution Determinism" ], "metrics_signals": [ "PR provenance", "review path", "correction rate", "test evidence", "Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence.", "Agent Delegation Safety", "Execution Determinism" ], "risk_flags": [ "review_burden", "unknown_pr_provenance" ], "governance_risk": [ "review_burden", "unknown_pr_provenance" ], "recommended_report_type": "Agent Delegation Safety Matrix", "good_answer_pattern": "A strong answer directly answers: \"How are AI-generated PRs reviewed across distributed teams?\" Validation method: Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with pull request system, agent tool logs, CI/CD, and related approved sources. It misses the operating risk: AI can increase review burden if review policy is unclear.", "answer_card_output": { "answer_type": "agent_delegation_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence.", "Evidence from pull request system, agent tool logs, CI/CD, approval workflow.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Agent Delegation Safety Matrix." ], "common_failure_modes": [ "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with pull request system, agent tool logs, CI/CD, and related approved sources. It misses the operating risk: AI can increase review burden if review policy is unclear.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Agent Delegation Safety Matrix" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer agent-004: \"How are AI-generated PRs reviewed across distributed teams?\"\nUse only aggregate, redacted, or metadata level evidence from: pull request system, agent tool logs, CI/CD, approval workflow.\nMinimum evidence to check: PR provenance, review path, correction rate, test evidence.\nUse these public model references if relevant: shirking_margin_zeta, mutation_score, agentic_intervention_load.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-agent-005", "source_question_id": "agent-005", "audience": [ "US CTO", "US CIO", "VP Engineering", "AI Governance Leader" ], "domain": "governed_agentic_sdlc", "domain_label": "Governed Agentic SDLC", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governed_agentic_sdlc", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "AI-governed software delivery", "agent workflow safety", "human approval", "agent-rework", "telemetry", "quality", "rework_signal", "ai_productivity" ], "decision_context": "Use when leaders need to decide which engineering workflows AI agents can safely execute under human, technical, and policy constraints.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "What telemetry detects agent-generated rework?", "why_it_matters": "AI productivity claims are weak unless rework is measured.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "shirking_margin_zeta", "label": "Shirking Margin", "formula": "zeta_i^x = P(project succeeds | e_i=0, policy x)", "plain_language": "Zeta measures how safe a contributor feels when they do not apply full effort. If the system hides weak effort behind downstream rescue, incentive quality degrades.", "diagnostic_use": "Use this to test whether AI, QA, senior rescue, or vendor buffering is hiding low-quality upstream work.", "required_signals": [ "review correction rate", "reopened work", "QA rescue count", "senior rescue count", "agent-generated rework", "approval override history" ], "interpretation_rules": [ "If downstream rescue repeatedly masks upstream defects, do not treat delivered work as healthy capacity.", "If agent output lowers effort discipline, require stronger validation and ownership boundaries.", "If responsibility is unclear, classify the risk as governance failure before capacity failure." ] }, { "formula_id": "agentic_intervention_load", "label": "Agentic Intervention Load", "formula": "Intervention Load Hours = Agent Execution Volume * Error Rate * Mean Human Repair Time + Context Switching Hours", "plain_language": "Agent speed is not free. Convert agent errors and context switching into the same human-time unit before comparing agent execution volume with orchestration capacity.", "diagnostic_use": "Use this to decide whether an agentic workflow is increasing throughput or overloading human orchestrators.", "required_signals": [ "agent execution volume", "agent error rate", "human review load", "correction rate", "context switching", "cycle-time impact", "rollback triggers" ], "interpretation_rules": [ "If intervention load exceeds human orchestration capacity, throttle agent execution.", "If agent velocity increases review queues, do not classify the workflow as successful automation.", "If error rate is unknown, keep the workflow human-gated." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "pull request system", "CI/CD", "quality system", "deployment system" ], "minimum_evidence": [ "reopened ticket", "review correction", "failed test", "reverted commit" ], "evidence_needed": [ "reopened ticket", "review correction", "failed test", "reverted commit" ], "validation_signal": "Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact.", "score_dimensions": [ "Agent Delegation Safety", "Telemetry Trust" ], "metrics_signals": [ "reopened ticket", "review correction", "failed test", "reverted commit", "Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact.", "Agent Delegation Safety", "Telemetry Trust" ], "risk_flags": [ "agent_rework", "false_productivity" ], "governance_risk": [ "agent_rework", "false_productivity" ], "recommended_report_type": "Agent Delegation Safety Matrix", "good_answer_pattern": "A strong answer directly answers: \"What telemetry detects agent-generated rework?\" Validation method: Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: AI productivity claims are weak unless rework is measured.", "answer_card_output": { "answer_type": "agent_delegation_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact.", "Evidence from work tracker, pull request system, CI/CD, quality system, deployment system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Agent Delegation Safety Matrix." ], "common_failure_modes": [ "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: AI productivity claims are weak unless rework is measured.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Agent Delegation Safety Matrix" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer agent-005: \"What telemetry detects agent-generated rework?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, pull request system, CI/CD, quality system, deployment system.\nMinimum evidence to check: reopened ticket, review correction, failed test, reverted commit.\nUse these public model references if relevant: shirking_margin_zeta, agentic_intervention_load.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-agent-006", "source_question_id": "agent-006", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "governed_agentic_sdlc", "domain_label": "Governed Agentic SDLC", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governed_agentic_sdlc", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "AI-governed software delivery", "agent workflow safety", "human approval", "human-gated", "agents", "risk", "human_gate", "trust_boundary" ], "decision_context": "Use when leaders need to decide which engineering workflows AI agents can safely execute under human, technical, and policy constraints.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Which workflows should remain human-gated until trust improves?", "why_it_matters": "Agentic delegation should expand only when validation and governance mature.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "shirking_margin_zeta", "label": "Shirking Margin", "formula": "zeta_i^x = P(project succeeds | e_i=0, policy x)", "plain_language": "Zeta measures how safe a contributor feels when they do not apply full effort. If the system hides weak effort behind downstream rescue, incentive quality degrades.", "diagnostic_use": "Use this to test whether AI, QA, senior rescue, or vendor buffering is hiding low-quality upstream work.", "required_signals": [ "review correction rate", "reopened work", "QA rescue count", "senior rescue count", "agent-generated rework", "approval override history" ], "interpretation_rules": [ "If downstream rescue repeatedly masks upstream defects, do not treat delivered work as healthy capacity.", "If agent output lowers effort discipline, require stronger validation and ownership boundaries.", "If responsibility is unclear, classify the risk as governance failure before capacity failure." ] }, { "formula_id": "replacement_kinetics_derivative", "label": "Replacement Kinetics Derivative", "formula": "partial C / partial x_i = Direct Savings - Incentive Distortion", "plain_language": "Replacing or automating a position creates direct savings only if it does not distort incentives and coordination around the rest of the chain.", "diagnostic_use": "Use this to decide whether AI should automate a workflow, augment it, or stay outside the approval path.", "required_signals": [ "workflow step position", "blast radius", "human approval path", "agent error rate", "review correction rate", "rollback evidence" ], "interpretation_rules": [ "End-of-chain validation tasks are more automation tolerant than middle-of-chain architecture decisions.", "If automation removes a human signal needed by other contributors, classify it as protected or human-gated.", "If rollback is missing, do not mark the workflow as safe for adaptive change." ] }, { "formula_id": "cognitive_fidelity", "label": "Cognitive Fidelity", "formula": "Quality ~ isomorphism(M_e, S_sys)", "plain_language": "Quality depends on how closely an engineer's mental model matches the actual system state.", "diagnostic_use": "Use this to evaluate whether ownership, documentation, and review systems keep human and agent contributors aligned with reality.", "required_signals": [ "architecture decision records", "documentation usage", "review comments", "rework caused by misunderstanding", "incident root cause", "agent correction rate" ], "interpretation_rules": [ "If contributors act on stale or missing system knowledge, delivery failures are knowledge failures before people failures.", "If AI outputs are correct syntactically but wrong semantically, classify the workflow as human-gated.", "If incidents repeat because lessons are not stored, knowledge memory is broken." ] } ], "evidence_to_request_from_internal_mcp": [ "workflow catalog", "security classification", "incident system", "approval policy" ], "minimum_evidence": [ "ambiguity class", "data sensitivity", "production impact", "approval requirement" ], "evidence_needed": [ "ambiguity class", "data sensitivity", "production impact", "approval requirement" ], "validation_signal": "Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences.", "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "metrics_signals": [ "ambiguity class", "data sensitivity", "production impact", "approval requirement", "Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences.", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unsafe_agent_delegation", "irreversible_action" ], "governance_risk": [ "unsafe_agent_delegation", "irreversible_action" ], "recommended_report_type": "Agent Delegation Safety Matrix", "good_answer_pattern": "A strong answer directly answers: \"Which workflows should remain human-gated until trust improves?\" Validation method: Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness.", "common_failure_pattern": "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with workflow catalog, security classification, incident system, and related approved sources. It misses the operating risk: Agentic delegation should expand only when validation and governance mature.", "answer_card_output": { "answer_type": "agent_delegation_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences.", "Evidence from workflow catalog, security classification, incident system, approval policy.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Agent Delegation Safety Matrix." ], "common_failure_modes": [ "A weak answer gives a generic governed agentic sdlc diagnosis instead of proving the research question with workflow catalog, security classification, incident system, and related approved sources. It misses the operating risk: Agentic delegation should expand only when validation and governance mature.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Agent Delegation Safety Matrix" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer agent-006: \"Which workflows should remain human-gated until trust improves?\"\nUse only aggregate, redacted, or metadata level evidence from: workflow catalog, security classification, incident system, approval policy.\nMinimum evidence to check: ambiguity class, data sensitivity, production impact, approval requirement.\nUse these public model references if relevant: shirking_margin_zeta, replacement_kinetics_derivative, cognitive_fidelity.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-adaptive-001", "source_question_id": "adaptive-001", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "governed_adaptive_control_loops", "domain_label": "Governed Adaptive Control Loops", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governed_adaptive_control_loops", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "adaptive control loops", "meta agent loop", "learning loop", "workflow optimization", "adaptive", "recommendation", "governance", "adaptive_control", "governed_recommendation" ], "decision_context": "Use when leaders need to decide whether the engineering system can improve workflow behavior from evidence without uncontrolled automation risk.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] } ], "evidence_to_request_from_internal_mcp": [ "telemetry platform", "workflow rules", "approval workflow", "audit logs" ], "minimum_evidence": [ "recommendation", "evidence trail", "approval path", "rollback path" ], "evidence_needed": [ "recommendation", "evidence trail", "approval path", "rollback path" ], "validation_signal": "Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement.", "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness", "Upside Potential" ], "metrics_signals": [ "recommendation", "evidence trail", "approval path", "rollback path", "Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement.", "Agent Delegation Safety", "Governance Completeness", "Upside Potential" ], "risk_flags": [ "unapproved_self_modification", "automation_overreach" ], "governance_risk": [ "unapproved_self_modification", "automation_overreach" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "good_answer_pattern": "A strong answer directly answers: \"Can the engineering system recommend workflow changes from telemetry without automatically applying them?\" Validation method: Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Agent Delegation Safety, Governance Completeness, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving the research question with telemetry platform, workflow rules, approval workflow, and related approved sources. It misses the operating risk: Adaptive control should begin with governed recommendations before self-modifying execution.", "answer_card_output": { "answer_type": "adaptive_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement.", "Evidence from telemetry platform, workflow rules, approval workflow, audit logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governed Adaptive Control Loop Review." ], "common_failure_modes": [ "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving the research question with telemetry platform, workflow rules, approval workflow, and related approved sources. It misses the operating risk: Adaptive control should begin with governed recommendations before self-modifying execution.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governed Adaptive Control Loop Review" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer adaptive-001: \"Can the engineering system recommend workflow changes from telemetry without automatically applying them?\"\nUse only aggregate, redacted, or metadata level evidence from: telemetry platform, workflow rules, approval workflow, audit logs.\nMinimum evidence to check: recommendation, evidence trail, approval path, rollback path.\nUse these public model references if relevant: engineering_performance_function.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-adaptive-002", "source_question_id": "adaptive-002", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader", "DevOps Leader" ], "domain": "governed_adaptive_control_loops", "domain_label": "Governed Adaptive Control Loops", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governed_adaptive_control_loops", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "adaptive control loops", "meta agent loop", "learning loop", "workflow optimization", "workflow-rules", "adaptive", "policy", "rule_class", "workflow_modification" ], "decision_context": "Use when leaders need to decide whether the engineering system can improve workflow behavior from evidence without uncontrolled automation risk.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "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_boundary": "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.", "math_and_model_references": [ { "formula_id": "replacement_kinetics_derivative", "label": "Replacement Kinetics Derivative", "formula": "partial C / partial x_i = Direct Savings - Incentive Distortion", "plain_language": "Replacing or automating a position creates direct savings only if it does not distort incentives and coordination around the rest of the chain.", "diagnostic_use": "Use this to decide whether AI should automate a workflow, augment it, or stay outside the approval path.", "required_signals": [ "workflow step position", "blast radius", "human approval path", "agent error rate", "review correction rate", "rollback evidence" ], "interpretation_rules": [ "End-of-chain validation tasks are more automation tolerant than middle-of-chain architecture decisions.", "If automation removes a human signal needed by other contributors, classify it as protected or human-gated.", "If rollback is missing, do not mark the workflow as safe for adaptive change." ] } ], "evidence_to_request_from_internal_mcp": [ "workflow rules", "CI/CD config", "policy documentation", "audit logs" ], "minimum_evidence": [ "rule class", "blast radius", "reversibility", "approval requirement" ], "evidence_needed": [ "rule class", "blast radius", "reversibility", "approval requirement" ], "validation_signal": "Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval.", "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "metrics_signals": [ "rule class", "blast radius", "reversibility", "approval requirement", "Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval.", "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "rule_modification_risk", "policy_bypass" ], "governance_risk": [ "rule_modification_risk", "policy_bypass" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "good_answer_pattern": "A strong answer directly answers: \"Which workflow rules can be safely modified under governance?\" Validation method: Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving the research question with workflow rules, CI/CD config, policy documentation, and related approved sources. It misses the operating risk: Not every execution rule should be adaptive; some rules encode security, compliance, or architecture constraints.", "answer_card_output": { "answer_type": "adaptive_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval.", "Evidence from workflow rules, CI/CD config, policy documentation, audit logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governed Adaptive Control Loop Review." ], "common_failure_modes": [ "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving the research question with workflow rules, CI/CD config, policy documentation, and related approved sources. It misses the operating risk: Not every execution rule should be adaptive; some rules encode security, compliance, or architecture constraints.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governed Adaptive Control Loop Review" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer adaptive-002: \"Which workflow rules can be safely modified under governance?\"\nUse only aggregate, redacted, or metadata level evidence from: workflow rules, CI/CD config, policy documentation, audit logs.\nMinimum evidence to check: rule class, blast radius, reversibility, approval requirement.\nUse these public model references if relevant: replacement_kinetics_derivative.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-adaptive-003", "source_question_id": "adaptive-003", "audience": [ "US CTO", "US CIO", "VP Engineering", "AI Governance Leader", "Platform Leader" ], "domain": "governed_adaptive_control_loops", "domain_label": "Governed Adaptive Control Loops", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governed_adaptive_control_loops", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "adaptive control loops", "meta agent loop", "learning loop", "workflow optimization", "degradation", "feedback", "adaptive", "negative_feedback", "post_change_delta" ], "decision_context": "Use when leaders need to decide whether the engineering system can improve workflow behavior from evidence without uncontrolled automation risk.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "How does the system detect when adaptive changes degrade performance?", "why_it_matters": "Learning loops need negative feedback and stop conditions.", "doctrine_answer_boundary": "Adaptive degradation is detected by comparing post-change quality, cycle time, failed validation, override, incident, and rollback signals against baselines and predefined stop conditions.", "math_and_model_references": [ { "formula_id": "agentic_intervention_load", "label": "Agentic Intervention Load", "formula": "Intervention Load Hours = Agent Execution Volume * Error Rate * Mean Human Repair Time + Context Switching Hours", "plain_language": "Agent speed is not free. Convert agent errors and context switching into the same human-time unit before comparing agent execution volume with orchestration capacity.", "diagnostic_use": "Use this to decide whether an agentic workflow is increasing throughput or overloading human orchestrators.", "required_signals": [ "agent execution volume", "agent error rate", "human review load", "correction rate", "context switching", "cycle-time impact", "rollback triggers" ], "interpretation_rules": [ "If intervention load exceeds human orchestration capacity, throttle agent execution.", "If agent velocity increases review queues, do not classify the workflow as successful automation.", "If error rate is unknown, keep the workflow human-gated." ] } ], "evidence_to_request_from_internal_mcp": [ "telemetry platform", "agent tool logs", "CI/CD", "incident system", "rollback records" ], "minimum_evidence": [ "post-change delta", "quality drift", "override rate", "rollback trigger" ], "evidence_needed": [ "post-change delta", "quality drift", "override rate", "rollback trigger" ], "validation_signal": "Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes.", "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Upside Potential" ], "metrics_signals": [ "post-change delta", "quality drift", "override rate", "rollback trigger", "Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes.", "Telemetry Trust", "Agent Delegation Safety", "Upside Potential" ], "risk_flags": [ "recursive_degradation", "missing_negative_feedback" ], "governance_risk": [ "recursive_degradation", "missing_negative_feedback" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "good_answer_pattern": "A strong answer directly answers: \"How does the system detect when adaptive changes degrade performance?\" Validation method: Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Telemetry Trust, Agent Delegation Safety, Upside Potential.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving the research question with telemetry platform, agent tool logs, CI/CD, and related approved sources. It misses the operating risk: Learning loops need negative feedback and stop conditions.", "answer_card_output": { "answer_type": "adaptive_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes.", "Evidence from telemetry platform, agent tool logs, CI/CD, incident system, rollback records.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governed Adaptive Control Loop Review." ], "common_failure_modes": [ "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving the research question with telemetry platform, agent tool logs, CI/CD, and related approved sources. It misses the operating risk: Learning loops need negative feedback and stop conditions.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governed Adaptive Control Loop Review" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer adaptive-003: \"How does the system detect when adaptive changes degrade performance?\"\nUse only aggregate, redacted, or metadata level evidence from: telemetry platform, agent tool logs, CI/CD, incident system, rollback records.\nMinimum evidence to check: post-change delta, quality drift, override rate, rollback trigger.\nUse these public model references if relevant: agentic_intervention_load.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-adaptive-004", "source_question_id": "adaptive-004", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "governed_adaptive_control_loops", "domain_label": "Governed Adaptive Control Loops", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governed_adaptive_control_loops", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "adaptive control loops", "meta agent loop", "learning loop", "workflow optimization", "approval", "audit", "adaptive", "adaptive_authority", "rollback_authority" ], "decision_context": "Use when leaders need to decide whether the engineering system can improve workflow behavior from evidence without uncontrolled automation risk.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Who can approve, audit, and reverse adaptive changes to the SDLC?", "why_it_matters": "Self-improving systems require explicit authority and reversibility.", "doctrine_answer_boundary": "Every adaptive change class must have named approval authority, immutable audit evidence, an accountable system owner, independent rollback authority, and defined emergency stop conditions.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "replacement_kinetics_derivative", "label": "Replacement Kinetics Derivative", "formula": "partial C / partial x_i = Direct Savings - Incentive Distortion", "plain_language": "Replacing or automating a position creates direct savings only if it does not distort incentives and coordination around the rest of the chain.", "diagnostic_use": "Use this to decide whether AI should automate a workflow, augment it, or stay outside the approval path.", "required_signals": [ "workflow step position", "blast radius", "human approval path", "agent error rate", "review correction rate", "rollback evidence" ], "interpretation_rules": [ "End-of-chain validation tasks are more automation tolerant than middle-of-chain architecture decisions.", "If automation removes a human signal needed by other contributors, classify it as protected or human-gated.", "If rollback is missing, do not mark the workflow as safe for adaptive change." ] }, { "formula_id": "agentic_intervention_load", "label": "Agentic Intervention Load", "formula": "Intervention Load Hours = Agent Execution Volume * Error Rate * Mean Human Repair Time + Context Switching Hours", "plain_language": "Agent speed is not free. Convert agent errors and context switching into the same human-time unit before comparing agent execution volume with orchestration capacity.", "diagnostic_use": "Use this to decide whether an agentic workflow is increasing throughput or overloading human orchestrators.", "required_signals": [ "agent execution volume", "agent error rate", "human review load", "correction rate", "context switching", "cycle-time impact", "rollback triggers" ], "interpretation_rules": [ "If intervention load exceeds human orchestration capacity, throttle agent execution.", "If agent velocity increases review queues, do not classify the workflow as successful automation.", "If error rate is unknown, keep the workflow human-gated." ] } ], "evidence_to_request_from_internal_mcp": [ "policy documentation", "approval workflow", "audit logs", "rollback records" ], "minimum_evidence": [ "approver", "audit log", "rollback authority", "stop condition" ], "evidence_needed": [ "approver", "audit log", "rollback authority", "stop condition" ], "validation_signal": "Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions.", "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "metrics_signals": [ "approver", "audit log", "rollback authority", "stop condition", "Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions.", "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "authority_gap", "irreversible_adaptive_change" ], "governance_risk": [ "authority_gap", "irreversible_adaptive_change" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"Who can approve, audit, and reverse adaptive changes to the SDLC?\" Validation method: Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving the research question with policy documentation, approval workflow, audit logs, and related approved sources. It misses the operating risk: Self-improving systems require explicit authority and reversibility.", "answer_card_output": { "answer_type": "adaptive_control_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions.", "Evidence from policy documentation, approval workflow, audit logs, rollback records.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic governed adaptive control loops diagnosis instead of proving the research question with policy documentation, approval workflow, audit logs, and related approved sources. It misses the operating risk: Self-improving systems require explicit authority and reversibility.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer adaptive-004: \"Who can approve, audit, and reverse adaptive changes to the SDLC?\"\nUse only aggregate, redacted, or metadata level evidence from: policy documentation, approval workflow, audit logs, rollback records.\nMinimum evidence to check: approver, audit log, rollback authority, stop condition.\nUse these public model references if relevant: engineering_performance_function, replacement_kinetics_derivative, agentic_intervention_load.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-gov-001", "source_question_id": "gov-001", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "governance_security_failure_modes", "domain_label": "Governance, Security, and Failure Modes", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governance_security_failure_modes", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering governance", "security boundary", "failure modes", "rollback", "accountability", "risk", "external-work", "delivery_risk_owner" ], "decision_context": "Use when leaders need to define authority, auditability, approval, rollback, and stop conditions across deterministic and agentic systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Who owns delivery risk for externally or agent-produced work?", "why_it_matters": "Distributed and AI-assisted delivery require clear accountability.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "shirking_margin_zeta", "label": "Shirking Margin", "formula": "zeta_i^x = P(project succeeds | e_i=0, policy x)", "plain_language": "Zeta measures how safe a contributor feels when they do not apply full effort. If the system hides weak effort behind downstream rescue, incentive quality degrades.", "diagnostic_use": "Use this to test whether AI, QA, senior rescue, or vendor buffering is hiding low-quality upstream work.", "required_signals": [ "review correction rate", "reopened work", "QA rescue count", "senior rescue count", "agent-generated rework", "approval override history" ], "interpretation_rules": [ "If downstream rescue repeatedly masks upstream defects, do not treat delivered work as healthy capacity.", "If agent output lowers effort discipline, require stronger validation and ownership boundaries.", "If responsibility is unclear, classify the risk as governance failure before capacity failure." ] }, { "formula_id": "incentive_compatibility_constraint", "label": "Incentive Compatibility Constraint", "formula": "p_n * w_i - c >= zeta_i^x * w_i", "plain_language": "A contributor exerts effort when the expected value of working is greater than the expected value of shirking.", "diagnostic_use": "Use this as a qualitative operating model for effort, friction, unclear ownership, time-zone delay, and downstream safety nets.", "required_signals": [ "decision latency", "blocked time", "handoff delay", "context switching", "work ownership", "review accountability" ], "interpretation_rules": [ "If coordination cost is high, effort drops even when people are busy.", "If ownership is unclear, activity signals are not evidence of productive effort.", "If downstream teams constantly catch upstream issues, the incentive model is distorted." ] } ], "evidence_to_request_from_internal_mcp": [ "ownership map", "approval workflow", "incident system", "contracts or operating agreements" ], "minimum_evidence": [ "accountable owner", "review authority", "approval path", "incident responsibility" ], "evidence_needed": [ "accountable owner", "review authority", "approval path", "incident responsibility" ], "validation_signal": "Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility.", "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "metrics_signals": [ "accountable owner", "review authority", "approval path", "incident responsibility", "Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility.", "Governance Completeness", "Topology Fit" ], "risk_flags": [ "accountability_gap", "delivery_risk" ], "governance_risk": [ "accountability_gap", "delivery_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"Who owns delivery risk for externally or agent-produced work?\" Validation method: Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Topology Fit.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with ownership map, approval workflow, incident system, and related approved sources. It misses the operating risk: Distributed and AI-assisted delivery require clear accountability.", "answer_card_output": { "answer_type": "governance_failure_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility.", "Evidence from ownership map, approval workflow, incident system, contracts or operating agreements.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with ownership map, approval workflow, incident system, and related approved sources. It misses the operating risk: Distributed and AI-assisted delivery require clear accountability.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer gov-001: \"Who owns delivery risk for externally or agent-produced work?\"\nUse only aggregate, redacted, or metadata level evidence from: ownership map, approval workflow, incident system, contracts or operating agreements.\nMinimum evidence to check: accountable owner, review authority, approval path, incident responsibility.\nUse these public model references if relevant: shirking_margin_zeta, incentive_compatibility_constraint.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-gov-002", "source_question_id": "gov-002", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "DevOps Leader" ], "domain": "governance_security_failure_modes", "domain_label": "Governance, Security, and Failure Modes", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governance_security_failure_modes", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering governance", "security boundary", "failure modes", "rollback", "production", "approval", "governance", "production_authority", "approval_requirement" ], "decision_context": "Use when leaders need to define authority, auditability, approval, rollback, and stop conditions across deterministic and agentic systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Which production actions require internal approval?", "why_it_matters": "Production authority must be explicit in distributed systems.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "replacement_kinetics_derivative", "label": "Replacement Kinetics Derivative", "formula": "partial C / partial x_i = Direct Savings - Incentive Distortion", "plain_language": "Replacing or automating a position creates direct savings only if it does not distort incentives and coordination around the rest of the chain.", "diagnostic_use": "Use this to decide whether AI should automate a workflow, augment it, or stay outside the approval path.", "required_signals": [ "workflow step position", "blast radius", "human approval path", "agent error rate", "review correction rate", "rollback evidence" ], "interpretation_rules": [ "End-of-chain validation tasks are more automation tolerant than middle-of-chain architecture decisions.", "If automation removes a human signal needed by other contributors, classify it as protected or human-gated.", "If rollback is missing, do not mark the workflow as safe for adaptive change." ] }, { "formula_id": "availability_mttr", "label": "Availability and MTTR", "formula": "A = MTBF / (MTBF + MTTR)", "plain_language": "Availability improves when recovery time drops. Modern software systems should optimize fast recovery, not frozen change.", "diagnostic_use": "Use this to test whether engineering governance improves recovery or only slows delivery.", "required_signals": [ "deployment frequency", "change failure rate", "MTTR", "rollback duration", "incident detection time", "incident diagnosis time" ], "interpretation_rules": [ "If rollback is slow, execution governance is not production-grade.", "If MTTR improves while deployment frequency improves, governance is enabling flow.", "If incident data is missing, do not make reliability claims." ] }, { "formula_id": "mttr_limit_behavior", "label": "MTTR Limit Behavior", "formula": "lim_{MTTR -> 0} MTBF / (MTBF + MTTR) = 1", "plain_language": "As recovery time approaches zero, availability approaches one even when failures still happen.", "diagnostic_use": "Use this to evaluate rollback, feature flags, observability, and authority delegation.", "required_signals": [ "rollback path", "feature flag coverage", "incident time to mitigation", "approval latency", "audit record" ], "interpretation_rules": [ "If mitigation requires manual escalation, MTTR is governed by authority latency, not tooling.", "If deployment and release are not separated, rollback risk is higher.", "If feature flags lack ownership and audit, they are not sufficient governance." ] } ], "evidence_to_request_from_internal_mcp": [ "deployment system", "approval workflow", "policy documentation", "audit logs" ], "minimum_evidence": [ "production action", "approval requirement", "approver", "audit record" ], "evidence_needed": [ "production action", "approval requirement", "approver", "audit record" ], "validation_signal": "Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement.", "score_dimensions": [ "Governance Completeness", "Execution Determinism" ], "metrics_signals": [ "production action", "approval requirement", "approver", "audit record", "Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement.", "Governance Completeness", "Execution Determinism" ], "risk_flags": [ "production_authority_gap", "approval_bypass" ], "governance_risk": [ "production_authority_gap", "approval_bypass" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"Which production actions require internal approval?\" Validation method: Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with deployment system, approval workflow, policy documentation, and related approved sources. It misses the operating risk: Production authority must be explicit in distributed systems.", "answer_card_output": { "answer_type": "governance_failure_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement.", "Evidence from deployment system, approval workflow, policy documentation, audit logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with deployment system, approval workflow, policy documentation, and related approved sources. It misses the operating risk: Production authority must be explicit in distributed systems.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer gov-002: \"Which production actions require internal approval?\"\nUse only aggregate, redacted, or metadata level evidence from: deployment system, approval workflow, policy documentation, audit logs.\nMinimum evidence to check: production action, approval requirement, approver, audit record.\nUse these public model references if relevant: replacement_kinetics_derivative, availability_mttr, mttr_limit_behavior.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-gov-003", "source_question_id": "gov-003", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "governance_security_failure_modes", "domain_label": "Governance, Security, and Failure Modes", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governance_security_failure_modes", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering governance", "security boundary", "failure modes", "rollback", "security", "off-limits", "access", "security_boundary", "restricted_system" ], "decision_context": "Use when leaders need to define authority, auditability, approval, rollback, and stop conditions across deterministic and agentic systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "Which systems are off-limits to external contributors or agents?", "why_it_matters": "Security boundaries must be defined before capacity is distributed.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "shirking_margin_zeta", "label": "Shirking Margin", "formula": "zeta_i^x = P(project succeeds | e_i=0, policy x)", "plain_language": "Zeta measures how safe a contributor feels when they do not apply full effort. If the system hides weak effort behind downstream rescue, incentive quality degrades.", "diagnostic_use": "Use this to test whether AI, QA, senior rescue, or vendor buffering is hiding low-quality upstream work.", "required_signals": [ "review correction rate", "reopened work", "QA rescue count", "senior rescue count", "agent-generated rework", "approval override history" ], "interpretation_rules": [ "If downstream rescue repeatedly masks upstream defects, do not treat delivered work as healthy capacity.", "If agent output lowers effort discipline, require stronger validation and ownership boundaries.", "If responsibility is unclear, classify the risk as governance failure before capacity failure." ] }, { "formula_id": "incentive_compatibility_constraint", "label": "Incentive Compatibility Constraint", "formula": "p_n * w_i - c >= zeta_i^x * w_i", "plain_language": "A contributor exerts effort when the expected value of working is greater than the expected value of shirking.", "diagnostic_use": "Use this as a qualitative operating model for effort, friction, unclear ownership, time-zone delay, and downstream safety nets.", "required_signals": [ "decision latency", "blocked time", "handoff delay", "context switching", "work ownership", "review accountability" ], "interpretation_rules": [ "If coordination cost is high, effort drops even when people are busy.", "If ownership is unclear, activity signals are not evidence of productive effort.", "If downstream teams constantly catch upstream issues, the incentive model is distorted." ] } ], "evidence_to_request_from_internal_mcp": [ "security policy", "repository permissions", "identity provider", "data classification" ], "minimum_evidence": [ "restricted system", "access boundary", "data class", "privileged tool" ], "evidence_needed": [ "restricted system", "access boundary", "data class", "privileged tool" ], "validation_signal": "Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools.", "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "metrics_signals": [ "restricted system", "access boundary", "data class", "privileged tool", "Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools.", "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "security_boundary_gap", "privileged_access_overreach" ], "governance_risk": [ "security_boundary_gap", "privileged_access_overreach" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"Which systems are off-limits to external contributors or agents?\" Validation method: Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with security policy, repository permissions, identity provider, and related approved sources. It misses the operating risk: Security boundaries must be defined before capacity is distributed.", "answer_card_output": { "answer_type": "governance_failure_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools.", "Evidence from security policy, repository permissions, identity provider, data classification.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with security policy, repository permissions, identity provider, and related approved sources. It misses the operating risk: Security boundaries must be defined before capacity is distributed.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer gov-003: \"Which systems are off-limits to external contributors or agents?\"\nUse only aggregate, redacted, or metadata level evidence from: security policy, repository permissions, identity provider, data classification.\nMinimum evidence to check: restricted system, access boundary, data class, privileged tool.\nUse these public model references if relevant: engineering_performance_function, shirking_margin_zeta, incentive_compatibility_constraint.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-gov-004", "source_question_id": "gov-004", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "governance_security_failure_modes", "domain_label": "Governance, Security, and Failure Modes", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governance_security_failure_modes", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering governance", "security boundary", "failure modes", "rollback", "ip", "provenance", "contributions", "ip_assignment", "contribution_provenance" ], "decision_context": "Use when leaders need to define authority, auditability, approval, rollback, and stop conditions across deterministic and agentic systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "How is IP assignment and contribution provenance verified?", "why_it_matters": "External and AI-assisted work creates IP and ownership questions.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "l2_adjusted_score", "label": "L2 Adjusted Communication Score", "formula": "s_adj = s_raw - beta * (f_error - E[f | P])", "plain_language": "Language form errors should not be allowed to erase correct technical reasoning.", "diagnostic_use": "Use this as a public doctrine mapping for fair evaluation of distributed contributors, not as a public scoring engine.", "required_signals": [ "evaluation rubric", "technical reasoning evidence", "communication context", "review calibration", "bias control record" ], "interpretation_rules": [ "Do not use accent or grammar as a proxy for engineering capability.", "Separate reasoning quality from language surface form.", "Do not expose individual evaluation records through the public research workflow." ] }, { "formula_id": "frechet_semantic_distance", "label": "Frechet Semantic Distance", "formula": "FSD(y_q,b_q)=||mu_y-mu_b||_2^2 + Tr(Sigma_y + Sigma_b - 2(Sigma_y^(1/2) Sigma_b Sigma_y^(1/2))^(1/2))", "plain_language": "Semantic similarity should be measured by meaning, not surface phrasing.", "diagnostic_use": "Use this as a public doctrine reference for semantic matching and technical reasoning fidelity.", "required_signals": [ "approved rubric", "ideal answer blueprint", "semantic content evidence", "calibration record" ], "interpretation_rules": [ "Use semantic equivalence only inside approved evaluation or knowledge systems.", "Do not publish private transcript data or proprietary scoring parameters.", "If calibration evidence is missing, mark the semantic claim as unsupported." ] }, { "formula_id": "optimal_transport_code_switch", "label": "Optimal Transport With Code Switch Awareness", "formula": "s_q^OT = psi(W_2(P_q,Q_q; C o (1 - lambda M)))", "plain_language": "Code switching should not be treated as technical weakness when meaning is preserved.", "diagnostic_use": "Use this as public governance language for fair interpretation of multilingual technical reasoning.", "required_signals": [ "language context", "semantic content", "evaluation calibration", "bias review" ], "interpretation_rules": [ "Do not penalize multilingual phrasing when technical reasoning is preserved.", "Do not expose raw transcripts in public artifacts.", "Require governance review before using language-sensitive scoring." ] } ], "evidence_to_request_from_internal_mcp": [ "contracts or operating agreements", "repository metadata", "agent tool logs", "approval records" ], "minimum_evidence": [ "IP assignment", "commit provenance", "tool usage log", "approval record" ], "evidence_needed": [ "IP assignment", "commit provenance", "tool usage log", "approval record" ], "validation_signal": "Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records.", "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "metrics_signals": [ "IP assignment", "commit provenance", "tool usage log", "approval record", "Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records.", "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "ip_provenance_gap", "unverified_contribution" ], "governance_risk": [ "ip_provenance_gap", "unverified_contribution" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"How is IP assignment and contribution provenance verified?\" Validation method: Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Agent Delegation Safety.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with contracts or operating agreements, repository metadata, agent tool logs, and related approved sources. It misses the operating risk: External and AI-assisted work creates IP and ownership questions.", "answer_card_output": { "answer_type": "governance_failure_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records.", "Evidence from contracts or operating agreements, repository metadata, agent tool logs, approval records.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with contracts or operating agreements, repository metadata, agent tool logs, and related approved sources. It misses the operating risk: External and AI-assisted work creates IP and ownership questions.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer gov-004: \"How is IP assignment and contribution provenance verified?\"\nUse only aggregate, redacted, or metadata level evidence from: contracts or operating agreements, repository metadata, agent tool logs, approval records.\nMinimum evidence to check: IP assignment, commit provenance, tool usage log, approval record.\nUse these public model references if relevant: l2_adjusted_score, frechet_semantic_distance, optimal_transport_code_switch.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-gov-005", "source_question_id": "gov-005", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "DevOps Leader" ], "domain": "governance_security_failure_modes", "domain_label": "Governance, Security, and Failure Modes", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governance_security_failure_modes", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering governance", "security boundary", "failure modes", "rollback", "policy-exception", "audit", "governance", "policy_exception", "remediation" ], "decision_context": "Use when leaders need to define authority, auditability, approval, rollback, and stop conditions across deterministic and agentic systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "How are policy exceptions logged and reviewed?", "why_it_matters": "Exceptions reveal where governance is weak or misaligned with reality.", "doctrine_answer_boundary": "Policy exceptions require a timestamped request, business justification, accountable approver, bounded duration, affected assets, compensating controls, remediation owner, recurrence review, and closure evidence.", "math_and_model_references": [ { "formula_id": "integrity_l2", "label": "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", "plain_language": "Integrity combines consistency, semantic fidelity, conceptual content, phase coherence, grounding, and translation drift.", "diagnostic_use": "Use this only as public schema context for evaluation governance. Do not expose proprietary weights or private evidence.", "required_signals": [ "approved rubric", "calibration evidence", "grounding check", "translation drift check", "audit record" ], "interpretation_rules": [ "Never publish proprietary scoring weights or raw evaluation records.", "Use aggregate calibration and governance evidence only.", "If audit evidence is missing, classify the evaluation system as not decision-grade." ] }, { "formula_id": "counterfactual_esl_stability", "label": "Counterfactual ESL Stability", "formula": "|c_q - c_q_prime| <= tau_trans", "plain_language": "A score should remain stable when the same technical meaning is expressed in standardized English.", "diagnostic_use": "Use this as an audit question for evaluation systems and AI-assisted talent decisions.", "required_signals": [ "counterfactual test result", "score drift", "translation policy", "audit record" ], "interpretation_rules": [ "If meaning is stable but score changes materially, flag bias risk.", "If the evaluation system lacks counterfactual testing, mark governance incomplete.", "Do not expose raw candidate data through this public research system." ] }, { "formula_id": "adversarial_indistinguishability", "label": "Adversarial Indistinguishability", "formula": "AUC_protected_prediction compared with the 0.5 random-classification baseline", "plain_language": "An adversary that performs near the random-classification baseline has not demonstrated useful prediction of the protected attribute. That result is one diagnostic, not proof of fairness or zero leakage.", "diagnostic_use": "Use this to audit whether evaluation telemetry is fair enough for capacity topology decisions.", "required_signals": [ "adversarial test result", "AUC summary", "feature policy", "model audit record" ], "interpretation_rules": [ "If background prediction is materially better than random, classify the scoring system as biased or leaky.", "If model governance records are unavailable, do not treat the evaluation score as decision-grade.", "Use aggregate audit summaries only." ] } ], "evidence_to_request_from_internal_mcp": [ "policy exception logs", "approval workflow", "audit logs", "incident system" ], "minimum_evidence": [ "exception record", "approval path", "recurrence", "remediation action" ], "evidence_needed": [ "exception record", "approval path", "recurrence", "remediation action" ], "validation_signal": "Compare exception records, approval paths, recurrence, business justification, and remediation actions.", "score_dimensions": [ "Governance Completeness", "Telemetry Trust" ], "metrics_signals": [ "exception record", "approval path", "recurrence", "remediation action", "Compare exception records, approval paths, recurrence, business justification, and remediation actions.", "Governance Completeness", "Telemetry Trust" ], "risk_flags": [ "policy_exception_drift", "governance_lag" ], "governance_risk": [ "policy_exception_drift", "governance_lag" ], "recommended_report_type": "Governance, Security, and IP Control Report", "good_answer_pattern": "A strong answer directly answers: \"How are policy exceptions logged and reviewed?\" Validation method: Compare exception records, approval paths, recurrence, business justification, and remediation actions. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Telemetry Trust.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with policy exception logs, approval workflow, audit logs, and related approved sources. It misses the operating risk: Exceptions reveal where governance is weak or misaligned with reality.", "answer_card_output": { "answer_type": "governance_failure_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Compare exception records, approval paths, recurrence, business justification, and remediation actions.", "Evidence from policy exception logs, approval workflow, audit logs, incident system.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Governance, Security, and IP Control Report." ], "common_failure_modes": [ "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with policy exception logs, approval workflow, audit logs, and related approved sources. It misses the operating risk: Exceptions reveal where governance is weak or misaligned with reality.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Governance, Security, and IP Control Report" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer gov-005: \"How are policy exceptions logged and reviewed?\"\nUse only aggregate, redacted, or metadata level evidence from: policy exception logs, approval workflow, audit logs, incident system.\nMinimum evidence to check: exception record, approval path, recurrence, remediation action.\nUse these public model references if relevant: integrity_l2, counterfactual_esl_stability, adversarial_indistinguishability.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." }, { "id": "learning-card-gov-006", "source_question_id": "gov-006", "audience": [ "US CTO", "US CIO", "VP Engineering", "CIO", "AI Governance Leader" ], "domain": "governance_security_failure_modes", "domain_label": "Governance, Security, and Failure Modes", "canonical_url": "https://engineering.teamstation.dev/research/engineering-operating-system/questions/#governance_security_failure_modes", "source_url": "https://engineering.teamstation.dev/api/research/cto-cio-learning-cards.json", "parent_site": "https://teamstation.dev", "research_hub_url": "https://engineering.teamstation.dev/research/engineering-operating-system/", "related_teamstation_concept_url": "https://teamstation.dev", "topic": [ "engineering systems", "engineering capacity", "agentic SDLC", "telemetry-driven engineering", "engineering governance", "security boundary", "failure modes", "rollback", "failure-mode", "scaling", "risk", "failure_mode_register", "scaling_risk" ], "decision_context": "Use when leaders need to define authority, auditability, approval, rollback, and stop conditions across deterministic and agentic systems.", "learning_objective": "Teach an internal LLM or MCP client how to turn one Engineering Capacity OS question into evidence requirements, model interpretation, an answer card, and a leadership report section.", "core_question": "What breaks first when capacity, distribution, or automation increases?", "why_it_matters": "Failure-mode analysis turns scaling plans into testable risk hypotheses.", "doctrine_answer_boundary": "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.", "math_and_model_references": [ { "formula_id": "engineering_performance_function", "label": "Engineering Performance Function", "formula": "P(t)=f(C,T,K,D,O,A,L,G) -> {Speed, Quality, Cost, Risk, Value}", "plain_language": "Engineering performance at time t is a system output, not a headcount output. It depends on capacity, topology, knowledge, execution, telemetry, agentic action, adaptive learning, and governance.", "diagnostic_use": "Use this as the top-level dependency map for every Engineering Capacity OS report.", "required_signals": [ "committed work", "completed work", "review queue age", "cycle time", "deployment success", "incident interruption load", "ownership map", "approval path", "rollback evidence" ], "interpretation_rules": [ "If speed improves while quality, cost, risk, or value degrade, the system did not improve.", "If one variable is unknown, mark the answer as partial rather than forcing a recommendation.", "If governance evidence is missing, do not recommend capacity expansion or autonomous workflow changes." ] }, { "formula_id": "shirking_margin_zeta", "label": "Shirking Margin", "formula": "zeta_i^x = P(project succeeds | e_i=0, policy x)", "plain_language": "Zeta measures how safe a contributor feels when they do not apply full effort. If the system hides weak effort behind downstream rescue, incentive quality degrades.", "diagnostic_use": "Use this to test whether AI, QA, senior rescue, or vendor buffering is hiding low-quality upstream work.", "required_signals": [ "review correction rate", "reopened work", "QA rescue count", "senior rescue count", "agent-generated rework", "approval override history" ], "interpretation_rules": [ "If downstream rescue repeatedly masks upstream defects, do not treat delivered work as healthy capacity.", "If agent output lowers effort discipline, require stronger validation and ownership boundaries.", "If responsibility is unclear, classify the risk as governance failure before capacity failure." ] }, { "formula_id": "incentive_compatibility_constraint", "label": "Incentive Compatibility Constraint", "formula": "p_n * w_i - c >= zeta_i^x * w_i", "plain_language": "A contributor exerts effort when the expected value of working is greater than the expected value of shirking.", "diagnostic_use": "Use this as a qualitative operating model for effort, friction, unclear ownership, time-zone delay, and downstream safety nets.", "required_signals": [ "decision latency", "blocked time", "handoff delay", "context switching", "work ownership", "review accountability" ], "interpretation_rules": [ "If coordination cost is high, effort drops even when people are busy.", "If ownership is unclear, activity signals are not evidence of productive effort.", "If downstream teams constantly catch upstream issues, the incentive model is distorted." ] } ], "evidence_to_request_from_internal_mcp": [ "work tracker", "pull request system", "CI/CD", "incident system", "audit logs" ], "minimum_evidence": [ "hidden queue", "review bottleneck", "pipeline drift", "governance lag" ], "evidence_needed": [ "hidden queue", "review bottleneck", "pipeline drift", "governance lag" ], "validation_signal": "Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag.", "score_dimensions": [ "Governance Completeness", "Capacity Reality", "Execution Determinism" ], "metrics_signals": [ "hidden queue", "review bottleneck", "pipeline drift", "governance lag", "Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag.", "Governance Completeness", "Capacity Reality", "Execution Determinism" ], "risk_flags": [ "failure_mode_unknown", "scaling_degradation" ], "governance_risk": [ "failure_mode_unknown", "scaling_degradation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "good_answer_pattern": "A strong answer directly answers: \"What breaks first when capacity, distribution, or automation increases?\" Validation method: Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag. It marks observed state, confidence, missing evidence, risk flags, and next safe action across Governance Completeness, Capacity Reality, Execution Determinism.", "common_failure_pattern": "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: Failure-mode analysis turns scaling plans into testable risk hypotheses.", "answer_card_output": { "answer_type": "governance_failure_answer", "required_fields": [ "observed_state", "evidence_summary", "confidence", "missing_evidence", "risk_flags", "decision_implication", "next_safe_action", "source_systems_used", "time_window" ], "good_answer_must_include": [ "Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag.", "Evidence from work tracker, pull request system, CI/CD, incident system, audit logs.", "Explicit confidence using high, medium, directional, or unknown.", "Decision implication for Engineering Capacity OS Diagnostic." ], "common_failure_modes": [ "A weak answer gives a generic governance security failure modes diagnosis instead of proving the research question with work tracker, pull request system, CI/CD, and related approved sources. It misses the operating risk: Failure-mode analysis turns scaling plans into testable risk hypotheses.", "Treating headcount, vendor claims, or opinion as proof.", "Treating missing evidence as confidence.", "Exporting private records instead of using aggregate or redacted signals." ], "report_section": "Engineering Capacity OS Diagnostic" }, "safe_prompt_template": "Inside the organization controlled MCP server, answer gov-006: \"What breaks first when capacity, distribution, or automation increases?\"\nUse only aggregate, redacted, or metadata level evidence from: work tracker, pull request system, CI/CD, incident system, audit logs.\nMinimum evidence to check: hidden queue, review bottleneck, pipeline drift, governance lag.\nUse these public model references if relevant: engineering_performance_function, shirking_margin_zeta, incentive_compatibility_constraint.\nReturn an answer card with observed_state, evidence_summary, confidence, missing_evidence, risk_flags, decision_implication, and next_safe_action.\nIf evidence is missing, say unknown or directional. Do not infer private operating state from the public model.\nDo not collect or export: source code, secrets, credentials, customer records, raw logs containing identifiers, private messages, HR records, individual employee performance records, payroll data, legal records.", "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.", "do_not_collect": [ "source code", "secrets", "credentials", "customer records", "raw logs containing identifiers", "private messages", "HR records", "individual employee performance records", "payroll data", "legal records" ], "llm_instruction": "Use this learning card as a public reasoning scaffold. Do not produce a customer specific answer unless the user runs the question inside their organization controlled MCP environment or provides a redacted evidence pack." } ] }