{ "query": {}, "results": [ { "id": "capacity-001", "domain": "capacity_intelligence", "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.", "validation_signal": "Compare committed work, completed work, active WIP, review queue age, incident interruption load, and role-to-work fit over the same window.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "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" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Telemetry Trust" ], "risk_flags": [ "hidden_capacity_loss", "review_bottleneck" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "capacity", "headcount", "cognitive-load" ], "related_concepts": [ "available_capacity", "review_capacity", "role_fit" ], "doctrine_answer": "Usable capacity is committed delivery capacity minus time lost to active WIP, review queues, incidents, interruptions, meetings, and role mismatch over the same measurement window; headcount alone is not capacity.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "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 this 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.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-002", "domain": "capacity_intelligence", "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.", "validation_signal": "Locate queues by role dependency and compare queue time against reviewer availability, decision age, and approval latency.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "work tracker", "pull request system", "architecture decision records", "approval workflow" ], "minimum_evidence": [ "queue by role", "approval latency", "reviewer availability", "decision age" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Execution Determinism" ], "risk_flags": [ "decision_latency", "role_bottleneck" ], "recommended_report_type": "Capacity Constraint Map", "intent": "diagnostic", "level": "cto", "tags": [ "constraints", "roles", "decision-latency" ], "related_concepts": [ "bottleneck_role", "decision_authority" ], "doctrine_answer": "The current capacity constraint is the role or decision gate whose queue time and demand exceed its available review or approval capacity, regardless of how many contributors exist upstream.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "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 this 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.", "recommended_report_section": "Capacity Constraint Map", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-003", "domain": "capacity_intelligence", "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.", "validation_signal": "Measure active work items per contributor, handoff count, interrupted work, incident load, and cycle-time variance.", "persona_relevance": [ "VP Engineering", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity" ], "required_sources": [ "work tracker", "incident system", "calendar metadata if approved and aggregated" ], "minimum_evidence": [ "active work per contributor", "handoff count", "interruption count", "cycle-time variance" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Upside Potential" ], "risk_flags": [ "context_switching", "ownership_fragmentation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "context-switching", "focus", "ownership" ], "related_concepts": [ "cognitive_load", "work_fragmentation" ], "doctrine_answer": "Context-switching loss is the share of available engineering time consumed by work transitions, interrupted tasks, handoffs, and fragmented ownership rather than completed flow.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "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 this 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.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-004", "domain": "capacity_intelligence", "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.", "validation_signal": "Classify PRs, design reviews, escalations, and rework by work type and senior-review dependency.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "pull request system", "architecture reviews", "work tracker" ], "minimum_evidence": [ "review dependency", "review queue age", "rework rate", "senior reviewer load" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Topology Fit" ], "risk_flags": [ "senior_review_saturation", "architecture_constraint" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "review", "architecture", "capacity" ], "related_concepts": [ "review_capacity", "architecture_authority" ], "doctrine_answer": "Work types with high architectural ambiguity, cross-service impact, security exposure, or weak test boundaries consume the most scarce senior review capacity and should be ranked by measured review demand.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "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 this 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.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-005", "domain": "capacity_intelligence", "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.", "validation_signal": "Compare onboarding duration, PR correction rate, review queue age, test reliability, deployment frequency, and incident load before scaling.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "determine_capacity_absorption_readiness", "build_distributed_capacity_strategy" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "onboarding duration", "review queue age", "PR correction rate", "deployment success" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "unabsorbable_capacity", "queue_growth" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "absorption", "scaling", "queue-time" ], "related_concepts": [ "capacity_absorption", "onboarding" ], "doctrine_answer": "The system is ready for more contributors only when onboarding, knowledge access, review capacity, test reliability, and release controls can absorb the marginal work without increasing queue age or rework.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "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 this 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.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-006", "domain": "capacity_intelligence", "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.", "validation_signal": "Identify blocked work items by blocker class and compare blocked time caused by people availability, technical dependency, policy, or decision latency.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "work tracker", "decision records", "architecture records", "approval workflow" ], "minimum_evidence": [ "blocked reason", "decision wait time", "approval age", "priority changes" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Governance Completeness" ], "risk_flags": [ "decision_latency", "ambiguous_priority" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "blocked-work", "decisions", "governance" ], "related_concepts": [ "decision_latency", "blocked_capacity" ], "doctrine_answer": "Decision-blocked capacity is the delivery time lost to unresolved priority, product, architecture, policy, or approval decisions; it must be separated from shortages in contributor availability.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "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 this 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.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-007", "domain": "capacity_intelligence", "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.", "validation_signal": "Map workstream demand to skill supply, review capacity, architecture knowledge, and validated contributor readiness.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "skills inventory", "service ownership map", "pull request system" ], "minimum_evidence": [ "skill demand", "skill supply", "review dependency", "ownership concentration" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Topology Fit" ], "risk_flags": [ "scarce_skill_constraint", "knowledge_concentration" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "skills", "topology", "scarcity" ], "related_concepts": [ "skill_fit", "topology_fit" ], "doctrine_answer": "A skill is topology-determining when demand for that skill, knowledge, or approval authority repeatedly exceeds validated supply and creates a measurable queue or risk boundary.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "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 this 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.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "capacity-008", "domain": "capacity_intelligence", "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.", "validation_signal": "Rank constraints by queue impact, quality impact, risk impact, reversibility, and required controls.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness", "build_distributed_capacity_strategy" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "incident system", "architecture records" ], "minimum_evidence": [ "queue impact", "quality impact", "risk impact", "control gaps" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Upside Potential", "Governance Completeness" ], "risk_flags": [ "premature_scaling", "automation_amplifies_bottleneck" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "repair-before-scale", "capacity", "risk" ], "related_concepts": [ "system_bottleneck", "capacity_repair" ], "doctrine_answer": "Repair the constraints with the greatest demonstrated queue, quality, and risk impact before adding people, partners, or agents, especially review bottlenecks, decision latency, missing knowledge, and unreliable execution controls.", "answer_card_template": { "answer_type": "capacity_constraint_answer", "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 this 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.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-001", "domain": "distributed_capacity_topology", "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.", "validation_signal": "Compare workstream complexity, dependency count, review requirements, incident risk, and knowledge availability.", "persona_relevance": [ "CTO", "VP Engineering", "CIO" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "service ownership map", "incident system", "architecture documentation" ], "minimum_evidence": [ "workstream complexity", "dependency count", "review requirements", "knowledge availability" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "unsafe_distribution", "knowledge_gap" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "topology", "distribution", "workstreams" ], "related_concepts": [ "workstream_allocation", "distributed_capacity" ], "doctrine_answer": "The safest workstreams to distribute are low-coupling, explicitly documented, testable, observable, access-bounded, reversible, and supported by sufficient internal review and escalation capacity.", "answer_card_template": { "answer_type": "capacity_topology_answer", "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 this 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.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-002", "domain": "distributed_capacity_topology", "question": "Which workstreams should remain internally owned?", "why_it_matters": "Some work requires direct architectural, product, security, or customer-context control.", "validation_signal": "Identify work tied to strategic IP, high-risk systems, sensitive data, architecture authority, or irreversible production impact.", "persona_relevance": [ "CTO", "CIO" ], "use_cases": [ "build_distributed_capacity_strategy", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "architecture records", "security classification", "service ownership map", "incident system" ], "minimum_evidence": [ "IP sensitivity", "production impact", "data sensitivity", "architecture authority" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Governance Completeness" ], "risk_flags": [ "ip_exposure", "loss_of_architecture_control" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cto", "tags": [ "internal-ownership", "risk", "security" ], "related_concepts": [ "internal_control", "ownership_boundary" ], "doctrine_answer": "Work should remain internally owned when it controls strategic architecture, sensitive data, security authority, customer context, regulated decisions, critical IP, or irreversible production impact.", "answer_card_template": { "answer_type": "capacity_topology_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-003", "domain": "distributed_capacity_topology", "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.", "validation_signal": "Map workstreams to skill fit, ownership requirements, time-zone needs, governance constraints, and performance evidence.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "skills inventory", "service ownership map", "security policy", "delivery telemetry" ], "minimum_evidence": [ "skill fit", "ownership requirements", "timezone needs", "governance constraints" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Capacity Reality", "Governance Completeness" ], "risk_flags": [ "topology_mismatch", "coordination_cost" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "topology-fit", "allocation", "strategy" ], "related_concepts": [ "capacity_topology", "sourcing_topology" ], "doctrine_answer": "The correct topology is selected per workstream by matching skill scarcity, ownership depth, coordination latency, security boundary, review capacity, execution determinism, and telemetry coverage to the available operating model.", "answer_card_template": { "answer_type": "capacity_topology_answer", "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 this 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.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-004", "domain": "distributed_capacity_topology", "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.", "validation_signal": "Compare blocked time, handoff delay, review latency, meeting dependency, and incident response requirements across work classes.", "persona_relevance": [ "CTO", "VP Engineering", "Platform Leader" ], "use_cases": [ "build_distributed_capacity_strategy", "improve_existing_capacity_topology", "diagnose_delivery_latency" ], "required_sources": [ "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" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "decision_latency", "handoff_delay", "incident_response_risk" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "timezone", "cycle-time", "distributed" ], "related_concepts": [ "coordination_tolerance", "handoff_delay" ], "doctrine_answer": "Time-zone overlap materially affects cycle time when work requires same-window architecture decisions, rapid review, coordinated releases, customer response, or incident control; asynchronous work with explicit interfaces is less sensitive.", "answer_card_template": { "answer_type": "capacity_topology_answer", "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 this 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.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-005", "domain": "distributed_capacity_topology", "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.", "validation_signal": "Compare PR volume, review queue age, reviewer availability, correction rate, and approval latency before and after capacity changes.", "persona_relevance": [ "CTO", "VP Engineering" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "pull request system", "work tracker", "architecture reviews" ], "minimum_evidence": [ "PR volume", "review queue age", "reviewer availability", "correction rate" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Capacity Reality", "Topology Fit", "Execution Determinism" ], "risk_flags": [ "review_saturation", "correction_load" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cto", "tags": [ "review-capacity", "contributors", "scaling" ], "related_concepts": [ "review_capacity", "distributed_contributors" ], "doctrine_answer": "Distributed contributors should be added only after reviewer availability and architecture authority can meet a defined review service level without increasing correction rate, approval latency, or queue age.", "answer_card_template": { "answer_type": "capacity_topology_answer", "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 this 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.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-006", "domain": "distributed_capacity_topology", "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.", "validation_signal": "Score each service by documentation quality, incident history, test reliability, deployment reproducibility, and ownership clarity.", "persona_relevance": [ "CTO", "CIO", "VP Engineering", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "service catalog", "runbooks", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "documentation quality", "test reliability", "deployment reproducibility", "ownership clarity" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "ownership_ambiguity", "service_transfer_risk" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "ownership", "services", "distributed" ], "related_concepts": [ "service_ownership", "external_ownership" ], "doctrine_answer": "A service is ready for distributed ownership when ownership is explicit and current documentation, tests, deployment controls, telemetry, runbooks, escalation paths, and rollback procedures make operation reproducible.", "answer_card_template": { "answer_type": "capacity_topology_answer", "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 this 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.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-007", "domain": "distributed_capacity_topology", "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.", "validation_signal": "Map contributor types to repository, environment, data, secrets, deployment, and production permissions.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "improve_existing_capacity_topology" ], "required_sources": [ "identity provider", "repository permissions", "deployment permissions", "security policy" ], "minimum_evidence": [ "access class", "repository scope", "environment permission", "production authority" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "risk_flags": [ "access_overreach", "ip_exposure", "production_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "access", "permissions", "security" ], "related_concepts": [ "access_boundary", "contributor_type" ], "doctrine_answer": "Each contributor type should receive the least repository, environment, data, secret, deployment, and production access required for its approved work, with time bounds, auditability, and revocation.", "answer_card_template": { "answer_type": "capacity_topology_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-008", "domain": "distributed_capacity_topology", "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.", "validation_signal": "Measure time to first accepted PR, time to independent task completion, review correction rate, and escalation frequency.", "persona_relevance": [ "VP Engineering", "CTO" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "pull request system", "onboarding records", "escalation logs" ], "minimum_evidence": [ "time to first accepted PR", "independent task completion", "correction rate", "escalation frequency" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Capacity Reality" ], "risk_flags": [ "slow_ramp", "supervision_overhead" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "onboarding", "ramp", "independence" ], "related_concepts": [ "ramp_curve", "independent_contribution" ], "doctrine_answer": "The ramp curve is the measured progression from access and context acquisition to first accepted change, independent task completion, production-safe contribution, and ownership with declining correction and escalation rates.", "answer_card_template": { "answer_type": "capacity_topology_answer", "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 this 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.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-009", "domain": "distributed_capacity_topology", "question": "Which communication rituals reduce decision latency?", "why_it_matters": "Distributed systems need explicit coordination mechanisms.", "validation_signal": "Compare blocked states, decision wait time, rework, handoff delay, and meeting load before and after ritual changes.", "persona_relevance": [ "VP Engineering", "Platform Leader" ], "use_cases": [ "diagnose_delivery_latency", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "decision records", "calendar metadata if approved and aggregated", "pull request system" ], "minimum_evidence": [ "blocked states", "decision wait time", "handoff delay", "meeting load" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Topology Fit", "Telemetry Trust" ], "risk_flags": [ "coordination_overhead", "meeting_load" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "rituals", "coordination", "latency" ], "related_concepts": [ "decision_latency", "operating_rituals" ], "doctrine_answer": "Useful communication rituals reduce decision latency by making ownership, decision records, handoffs, escalation windows, and unresolved blockers explicit without adding more meeting load than the delay they remove.", "answer_card_template": { "answer_type": "capacity_topology_answer", "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 this 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.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "topology-010", "domain": "distributed_capacity_topology", "question": "What is the exit path if a capacity topology underperforms?", "why_it_matters": "Governance requires reversibility, not only rollout plans.", "validation_signal": "Verify ownership transfer, documentation continuity, access removal, IP control, work reassignment, and service continuity plans.", "persona_relevance": [ "CIO", "CTO" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "build_distributed_capacity_strategy" ], "required_sources": [ "contracts or operating agreements", "access policy", "service ownership map", "documentation inventory" ], "minimum_evidence": [ "exit plan", "access removal", "ownership transfer", "service continuity" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "risk_flags": [ "irreversible_topology", "continuity_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "exit-plan", "governance", "reversibility" ], "related_concepts": [ "exit_readiness", "reversibility" ], "doctrine_answer": "A governed exit path preserves service continuity through documented ownership transfer, knowledge capture, access revocation, IP confirmation, work reassignment, and rollback or replacement triggers defined before rollout.", "answer_card_template": { "answer_type": "capacity_topology_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-001", "domain": "knowledge_architecture_memory", "question": "Which parts of the engineering system depend on tribal knowledge?", "why_it_matters": "Tribal knowledge limits distributed execution and safe AI assistance.", "validation_signal": "Identify repeated escalations, undocumented decisions, onboarding blockers, and work items requiring specific individuals.", "persona_relevance": [ "CTO", "VP Engineering", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "assess_agentic_sdlc_readiness", "determine_capacity_absorption_readiness" ], "required_sources": [ "work tracker", "service ownership map", "documentation inventory", "incident system" ], "minimum_evidence": [ "repeated escalation", "undocumented decision", "onboarding blocker", "individual dependency" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Topology Fit" ], "risk_flags": [ "tribal_knowledge", "single_point_of_context" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "knowledge", "tribal-knowledge", "architecture" ], "related_concepts": [ "explicit_knowledge", "knowledge_dependency" ], "doctrine_answer": "Tribal-knowledge dependencies are system areas where delivery, review, deployment, or incident response repeatedly requires specific individuals because the necessary decisions, constraints, or procedures are not durable artifacts.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "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 this 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.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-002", "domain": "knowledge_architecture_memory", "question": "How current are architecture decision records?", "why_it_matters": "Distributed contributors and agents need explicit architectural intent.", "validation_signal": "Compare architecture records against current services, dependencies, incidents, and recent implementation choices.", "persona_relevance": [ "CTO", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "assess_agentic_sdlc_readiness" ], "required_sources": [ "architecture decision records", "service catalog", "repository history", "incident reviews" ], "minimum_evidence": [ "ADR freshness", "service dependency match", "recent decision coverage", "incident linkage" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "architecture_drift", "stale_decision_memory" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "adr", "architecture", "documentation" ], "related_concepts": [ "architecture_memory", "decision_record" ], "doctrine_answer": "Architecture decision records are current only when they still match deployed services, dependencies, constraints, ownership, and recent implementation and incident evidence; document age alone does not establish validity.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "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 this 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.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-003", "domain": "knowledge_architecture_memory", "question": "Which services have clear ownership maps?", "why_it_matters": "Ownership ambiguity creates delays, rework, and incident risk.", "validation_signal": "Verify each service has named owners, escalation paths, review authorities, and support expectations.", "persona_relevance": [ "CTO", "VP Engineering", "Platform Leader" ], "use_cases": [ "improve_existing_capacity_topology", "diagnose_engineering_capacity" ], "required_sources": [ "service catalog", "ownership map", "incident system", "pull request system" ], "minimum_evidence": [ "named owner", "escalation path", "review authority", "support expectation" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "ownership_ambiguity", "incident_delay" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "ownership", "service-map", "runbooks" ], "related_concepts": [ "service_ownership", "escalation_path" ], "doctrine_answer": "A clear service ownership map names the accountable owner, review authority, operational responder, escalation path, and support expectation for every production service and critical dependency.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "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 this 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.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-004", "domain": "knowledge_architecture_memory", "question": "What knowledge must a contributor have before production-impacting work?", "why_it_matters": "Unsafe delegation often starts with insufficient context.", "validation_signal": "Define required service knowledge, system constraints, tests, deployment process, incident history, and approval boundaries.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "runbooks", "deployment procedures", "test strategy", "incident reviews", "approval policy" ], "minimum_evidence": [ "required knowledge checklist", "deployment process", "incident history", "approval boundary" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Governance Completeness" ], "risk_flags": [ "unsafe_delegation", "production_impact" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "production", "delegation", "knowledge" ], "related_concepts": [ "production_readiness", "approval_boundary" ], "doctrine_answer": "Before production-impacting work, a contributor needs verified knowledge of service behavior, architecture constraints, data sensitivity, tests, deployment and rollback procedures, incident history, and approval boundaries.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "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 this question with runbooks, deployment procedures, test strategy, and related approved sources. It misses the operating risk: Unsafe delegation often starts with insufficient context.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-005", "domain": "knowledge_architecture_memory", "question": "Which knowledge sources are safe for AI retrieval?", "why_it_matters": "Agentic workflows need context without exposing secrets, customer data, or sensitive records.", "validation_signal": "Classify documentation, tickets, code references, runbooks, logs, and incidents by sensitivity and retrieval permission.", "persona_relevance": [ "CIO", "AI Governance Leader", "Platform Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "documentation system", "security classification", "AI tool policy", "identity provider" ], "minimum_evidence": [ "sensitivity class", "retrieval permission", "redaction rule", "audit requirement" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "data_exposure", "unsafe_ai_retrieval" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cio", "tags": [ "ai-retrieval", "privacy", "knowledge" ], "related_concepts": [ "retrieval_boundary", "privacy_class" ], "doctrine_answer": "AI retrieval should be limited to approved, access-controlled knowledge whose sensitivity is classified and whose content excludes secrets, customer records, privileged logs, and other data outside the agent's task boundary.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "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 this 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.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-006", "domain": "knowledge_architecture_memory", "question": "Where does documentation drift create delivery risk?", "why_it_matters": "Outdated documentation causes incorrect decisions by humans and agents.", "validation_signal": "Compare documented procedures against actual deployment paths, incident response steps, code ownership, and pipeline behavior.", "persona_relevance": [ "VP Engineering", "Platform Leader", "AI Governance Leader" ], "use_cases": [ "diagnose_engineering_capacity", "assess_agentic_sdlc_readiness" ], "required_sources": [ "documentation system", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "documented procedure", "actual procedure", "drift instance", "risk impact" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Execution Determinism" ], "risk_flags": [ "documentation_drift", "agent_error" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "documentation-drift", "risk", "agents" ], "related_concepts": [ "doc_freshness", "procedure_drift" ], "doctrine_answer": "Documentation drift creates delivery risk wherever documented ownership, deployment, recovery, architecture, or policy no longer matches observed system behavior and can cause a human or agent to take an invalid action.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "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 this 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.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-007", "domain": "knowledge_architecture_memory", "question": "How are incidents converted into durable system memory?", "why_it_matters": "Learning requires failures to update rules, tests, runbooks, and agent instructions.", "validation_signal": "Verify incident outcomes produced updated tests, documentation, alerts, workflow rules, or governance constraints.", "persona_relevance": [ "CTO", "Platform Leader", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "assess_agentic_sdlc_readiness" ], "required_sources": [ "incident system", "runbooks", "test suite", "workflow rules", "agent instructions" ], "minimum_evidence": [ "incident outcome", "updated test", "updated runbook", "new workflow rule" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Upside Potential" ], "risk_flags": [ "repeat_failure", "learning_gap" ], "recommended_report_type": "Knowledge and Architecture Memory Report", "intent": "diagnostic", "level": "cto", "tags": [ "incidents", "learning", "memory" ], "related_concepts": [ "incident_memory", "durable_learning" ], "doctrine_answer": "An incident becomes durable system memory only when verified lessons update executable controls such as tests, alerts, runbooks, ownership, architecture records, workflow rules, or agent instructions.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "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 this 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.", "recommended_report_section": "Knowledge and Architecture Memory Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "knowledge-008", "domain": "knowledge_architecture_memory", "question": "What evidence proves a distributed contributor is ready for ownership?", "why_it_matters": "Ownership should be evidence-based, not tenure-based.", "validation_signal": "Review accepted work, correction rate, service understanding, incident handling, deployment success, and escalation behavior.", "persona_relevance": [ "VP Engineering", "CTO" ], "use_cases": [ "improve_existing_capacity_topology", "determine_capacity_absorption_readiness" ], "required_sources": [ "pull request system", "work tracker", "incident system", "deployment system" ], "minimum_evidence": [ "accepted work", "correction rate", "deployment success", "escalation behavior" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Knowledge Transfer Readiness", "Topology Fit" ], "risk_flags": [ "premature_ownership", "service_risk" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "ownership-readiness", "distributed", "evidence" ], "related_concepts": [ "ownership_readiness", "evidence_based_delegation" ], "doctrine_answer": "Ownership readiness is demonstrated by accepted work, accurate system explanations, reliable deployments, low correction rates, sound incident behavior, and appropriate escalation across a representative evidence window.", "answer_card_template": { "answer_type": "knowledge_memory_answer", "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 this 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.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-001", "domain": "execution_harness", "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.", "validation_signal": "Compare pipeline templates, required gates, deployment paths, manual overrides, and exception frequency.", "persona_relevance": [ "CTO", "VP Engineering", "DevOps Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "CI/CD", "deployment system", "repository templates", "exception logs" ], "minimum_evidence": [ "pipeline template", "required gate", "manual override", "exception frequency" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "pipeline_variance", "manual_override" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cto", "tags": [ "ci-cd", "standardization", "execution" ], "related_concepts": [ "execution_harness", "pipeline_standardization" ], "doctrine_answer": "CI/CD is standardized when teams and contributor types use versioned pipeline templates, required quality and approval gates, consistent deployment paths, controlled exceptions, and equivalent audit evidence.", "answer_card_template": { "answer_type": "execution_control_answer", "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 this 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.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-002", "domain": "execution_harness", "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.", "validation_signal": "Trace delivery flows by team and identify manual steps, skipped gates, divergent templates, and environment-specific behavior.", "persona_relevance": [ "VP Engineering", "DevOps Leader", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "CI/CD", "deployment system", "work tracker", "environment inventory" ], "minimum_evidence": [ "manual step", "skipped gate", "template divergence", "environment drift" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Telemetry Trust" ], "risk_flags": [ "execution_drift", "environment_drift" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "variance", "delivery", "environment" ], "related_concepts": [ "execution_variance", "environment_drift" ], "doctrine_answer": "Execution variance enters wherever teams use divergent templates, manual steps, skipped gates, environment-specific behavior, undocumented release paths, or ungoverned overrides that change outcomes for equivalent work.", "answer_card_template": { "answer_type": "execution_control_answer", "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 this 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.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-003", "domain": "execution_harness", "question": "Which SDLC controls are system-enforced versus manually enforced?", "why_it_matters": "Manual enforcement breaks under scale, distribution, and agentic speed.", "validation_signal": "Classify each SDLC control as automated, policy-enforced, manually enforced, or undocumented.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "determine_capacity_absorption_readiness" ], "required_sources": [ "CI/CD", "policy documentation", "repository settings", "approval workflow" ], "minimum_evidence": [ "control class", "automation status", "manual gate", "undocumented exception" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "manual_control_failure", "policy_drift" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cio", "tags": [ "controls", "automation", "governance" ], "related_concepts": [ "system_enforcement", "manual_control" ], "doctrine_answer": "A control is system-enforced when the delivery platform automatically applies and records it; a policy, checklist, or reviewer habit is manually enforced and should not be treated as deterministic control.", "answer_card_template": { "answer_type": "execution_control_answer", "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 this 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.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-004", "domain": "execution_harness", "question": "How reproducible are production deployments across services?", "why_it_matters": "A topology can scale only when deployments behave as governed system states.", "validation_signal": "Compare deployment inputs, environment state, approval paths, rollback readiness, and post-deploy outcomes across services.", "persona_relevance": [ "CTO", "DevOps Leader", "Platform Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "deployment system", "CI/CD", "environment inventory", "rollback records" ], "minimum_evidence": [ "deployment input", "approval path", "rollback record", "post-deploy outcome" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "deployment_non_reproducibility", "rollback_gap" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cto", "tags": [ "deployment", "reproducibility", "rollback" ], "related_concepts": [ "deployment_determinism", "release_path" ], "doctrine_answer": "Production deployments are reproducible when equivalent versioned inputs, environment state, approvals, and pipeline rules produce consistent releases with tested rollback paths and explainable outcomes across services.", "answer_card_template": { "answer_type": "execution_control_answer", "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 this 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.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-005", "domain": "execution_harness", "question": "Where do pipeline failures originate most frequently?", "why_it_matters": "Failure concentration reveals weak execution stages before capacity increases amplify them.", "validation_signal": "Classify failed pipeline runs by stage, owner, cause class, recovery path, and recurrence.", "persona_relevance": [ "VP Engineering", "DevOps Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "CI/CD", "incident system", "deployment system" ], "minimum_evidence": [ "failure stage", "cause class", "recovery path", "recurrence" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Telemetry Trust" ], "risk_flags": [ "pipeline_failure_concentration", "recovery_gap" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "pipeline-failure", "root-cause", "ci-cd" ], "related_concepts": [ "failure_origin", "build_stage" ], "doctrine_answer": "The dominant pipeline failure origin is the stage and cause class with the highest recurring failure burden after runs are classified by build, test, security, approval, environment, deployment, and recovery behavior.", "answer_card_template": { "answer_type": "execution_control_answer", "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 this question with CI/CD, incident system, deployment system. It misses the operating risk: Failure concentration reveals weak execution stages before capacity increases amplify them.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-006", "domain": "execution_harness", "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.", "validation_signal": "Map SDLC execution rules to owners, approval authority, change process, and audit record.", "persona_relevance": [ "CTO", "CIO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "assess_agentic_sdlc_readiness" ], "required_sources": [ "policy documentation", "CI/CD config", "audit logs", "change management records" ], "minimum_evidence": [ "rule owner", "approval authority", "change process", "audit record" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Governance Completeness" ], "risk_flags": [ "rule_ownership_gap", "unaudited_change" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cto", "tags": [ "execution-rules", "ownership", "audit" ], "related_concepts": [ "rule_owner", "execution_policy" ], "doctrine_answer": "Execution rules require named owners, authorized approvers, versioned change records, audit history, exception handling, and rollback authority before teams or agents can modify them safely.", "answer_card_template": { "answer_type": "execution_control_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-007", "domain": "execution_harness", "question": "How are workflow standards propagated across teams?", "why_it_matters": "Scaling requires controlled propagation of standards rather than informal copying.", "validation_signal": "Compare documented standards with templates, automated checks, rollout records, and exception logs.", "persona_relevance": [ "VP Engineering", "Platform Leader", "DevOps Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "repository templates", "CI/CD", "documentation", "exception logs" ], "minimum_evidence": [ "standard template", "automated check", "rollout record", "exception" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Knowledge Transfer Readiness" ], "risk_flags": [ "standard_drift", "local_execution_variance" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "standards", "propagation", "workflow" ], "related_concepts": [ "workflow_standard", "policy_enforcement" ], "doctrine_answer": "Workflow standards propagate reliably through versioned templates, automated checks, controlled rollout, conformance telemetry, and explicit exception records rather than documentation and informal copying alone.", "answer_card_template": { "answer_type": "execution_control_answer", "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 this 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.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-008", "domain": "execution_harness", "question": "What is the cost of pipeline inconsistency?", "why_it_matters": "Inconsistency converts capacity into waiting, rework, release risk, and operational overhead.", "validation_signal": "Compare cycle time, failed runs, manual intervention, rollback events, and rework by pipeline class.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "diagnose_engineering_capacity", "build_distributed_capacity_strategy" ], "required_sources": [ "CI/CD", "deployment system", "work tracker", "incident system" ], "minimum_evidence": [ "cycle time by pipeline class", "failed run rate", "manual intervention", "rollback event" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Cost/Value/Risk Economics" ], "risk_flags": [ "pipeline_inconsistency_cost", "release_risk" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cio", "tags": [ "cost", "pipeline", "inconsistency" ], "related_concepts": [ "pipeline_cost", "release_risk" ], "doctrine_answer": "Pipeline inconsistency costs the engineering system the measured cycle time, failed runs, manual intervention, rework, rollback exposure, and release delay attributable to divergent execution paths.", "answer_card_template": { "answer_type": "execution_control_answer", "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 this 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.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-009", "domain": "execution_harness", "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.", "validation_signal": "Classify execution paths by test reliability, approval boundary, production impact, auditability, and rollback readiness.", "persona_relevance": [ "CTO", "CIO", "AI Governance Leader", "DevOps Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "CI/CD", "deployment system", "policy documentation", "audit logs" ], "minimum_evidence": [ "test reliability", "approval boundary", "production impact", "rollback readiness" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unsafe_execution_path", "agent_blast_radius" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "ai", "external-contributors", "execution-path" ], "related_concepts": [ "safe_delegation", "approval_path" ], "doctrine_answer": "An execution path is safe for AI-assisted or external contribution only when permissions are bounded and tests, review, approval, deployment, audit, and rollback controls constrain the path's blast radius.", "answer_card_template": { "answer_type": "execution_control_answer", "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 this 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.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "execution-010", "domain": "execution_harness", "question": "What breaks in execution when delivery volume increases?", "why_it_matters": "Volume exposes weak gates, slow reviews, unstable environments, and fragile deployment paths.", "validation_signal": "Compare failure rates, queue times, environment conflicts, rollback events, and approval latency before and after volume changes.", "persona_relevance": [ "CTO", "VP Engineering", "DevOps Leader" ], "use_cases": [ "determine_capacity_absorption_readiness", "diagnose_engineering_capacity" ], "required_sources": [ "CI/CD", "deployment system", "pull request system", "work tracker" ], "minimum_evidence": [ "volume change", "failure rate", "queue time", "environment conflict" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Execution Determinism", "Capacity Reality" ], "risk_flags": [ "volume_degradation", "execution_saturation" ], "recommended_report_type": "Execution Determinism Report", "intent": "diagnostic", "level": "cto", "tags": [ "volume", "scaling", "execution" ], "related_concepts": [ "delivery_volume", "execution_saturation" ], "doctrine_answer": "When delivery volume rises, the first execution failures appear at gates whose service capacity does not scale, including review, tests, environments, approvals, deployment concurrency, and rollback handling.", "answer_card_template": { "answer_type": "execution_control_answer", "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 this 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.", "recommended_report_section": "Execution Determinism Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-001", "domain": "decision_grade_telemetry", "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.", "validation_signal": "Inventory metrics used for decisions and classify each by source reliability, freshness, coverage, and decision history.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "diagnose_engineering_capacity" ], "required_sources": [ "work tracker", "CI/CD", "deployment system", "incident system", "observability dashboards" ], "minimum_evidence": [ "metric source", "freshness", "coverage", "decision history" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "dashboard_noise", "low_signal_decision" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "telemetry", "decision-grade", "metrics" ], "related_concepts": [ "telemetry_trust", "decision_signal" ], "doctrine_answer": "A signal is trusted for topology governance only when its source, definition, freshness, coverage, aggregation, known bias, and history of decision use are documented and tied to delivery outcomes.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "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 this 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.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-002", "domain": "decision_grade_telemetry", "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.", "validation_signal": "Compare candidate metrics with delivery outcomes, escaped defects, rework, cycle time, incident impact, and business milestones.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "diagnose_engineering_capacity", "build_distributed_capacity_strategy" ], "required_sources": [ "work tracker", "quality system", "incident system", "product milestones", "deployment system" ], "minimum_evidence": [ "metric correlation", "defect signal", "cycle time", "business milestone" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Cost/Value/Risk Economics" ], "risk_flags": [ "vanity_metric", "activity_bias" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "metrics", "outcomes", "value" ], "related_concepts": [ "outcome_metric", "activity_metric" ], "doctrine_answer": "Outcome signals are metrics that demonstrate a stable relationship with delivery speed, quality, cost, risk, reliability, or business milestones; activity counts without that relationship are not decision-grade evidence.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "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 this 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.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-003", "domain": "decision_grade_telemetry", "question": "How real-time is delivery visibility for leaders?", "why_it_matters": "Slow telemetry creates delayed intervention and makes adaptive control unsafe.", "validation_signal": "Measure reporting latency for work state, review queues, CI/CD failures, deployment outcomes, incidents, and agent actions.", "persona_relevance": [ "CTO", "CIO", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity", "assess_agentic_sdlc_readiness" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "deployment system", "incident system", "agent tool logs" ], "minimum_evidence": [ "reporting latency", "refresh interval", "coverage gap", "stale metric" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety" ], "risk_flags": [ "stale_visibility", "late_intervention" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "real-time", "visibility", "telemetry" ], "related_concepts": [ "telemetry_freshness", "delivery_visibility" ], "doctrine_answer": "Delivery visibility is real-time only to the degree that reporting latency remains below the intervention window for work queues, reviews, pipeline failures, deployments, incidents, and agent actions.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "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 this 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.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-004", "domain": "decision_grade_telemetry", "question": "Where are queues invisible to current dashboards?", "why_it_matters": "Hidden queues are a common cause of false capacity conclusions.", "validation_signal": "Compare work tracker states, PR waiting time, approval wait, dependency wait, incident interruption, and blocked comments against dashboard coverage.", "persona_relevance": [ "VP Engineering", "Platform Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness" ], "required_sources": [ "work tracker", "pull request system", "approval workflow", "incident system" ], "minimum_evidence": [ "hidden wait", "approval wait", "dependency wait", "dashboard coverage" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Capacity Reality" ], "risk_flags": [ "hidden_queue", "misdiagnosed_capacity" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "engineering_lead", "tags": [ "queues", "dashboard", "visibility" ], "related_concepts": [ "hidden_queue", "queue_time" ], "doctrine_answer": "A queue is invisible when work waits for review, approval, dependencies, decisions, environments, or incident recovery without a distinct timestamped state in the leadership telemetry model.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "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 this 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.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-005", "domain": "decision_grade_telemetry", "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.", "validation_signal": "Track defect escape, failed tests, review correction rate, reverts, incidents, rollback events, and customer-impacting defects after change.", "persona_relevance": [ "CTO", "CIO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "quality system", "pull request system", "CI/CD", "incident system", "deployment system" ], "minimum_evidence": [ "defect escape", "review correction", "revert", "rollback", "incident" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Cost/Value/Risk Economics" ], "risk_flags": [ "quality_degradation", "ai_rework" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "quality", "degradation", "ai" ], "related_concepts": [ "quality_signal", "degradation_detection" ], "doctrine_answer": "Quality degradation after a capacity or AI change is detected through changes in failed tests, review corrections, reverts, escaped defects, incidents, rollback events, and customer impact against a pre-change baseline.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "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 this 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.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-006", "domain": "decision_grade_telemetry", "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.", "validation_signal": "Aggregate cycle time, queue time, deployment success, defect rate, incident interruption, and rework by workstream or team-level topology.", "persona_relevance": [ "CIO", "CTO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "work tracker", "CI/CD", "deployment system", "incident system" ], "minimum_evidence": [ "aggregate cycle time", "team-level queue time", "topology class", "defect rate" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "privacy_violation", "bad_benchmark" ], "recommended_report_type": "Capacity Topology Readiness Report", "intent": "diagnostic", "level": "cio", "tags": [ "privacy", "topology", "benchmark" ], "related_concepts": [ "aggregate_telemetry", "privacy_boundary" ], "doctrine_answer": "Topology performance should be compared with aggregated workstream or team-level flow, quality, deployment, incident, and rework signals, never individual surveillance or employee ranking.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "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 this 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.", "recommended_report_section": "Capacity Topology Readiness Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-007", "domain": "decision_grade_telemetry", "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.", "validation_signal": "Define thresholds for failed validations, reverted changes, policy exceptions, human overrides, incident correlation, and quality drift.", "persona_relevance": [ "CIO", "AI Governance Leader", "CTO" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "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" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "automation_without_stop_condition", "recursive_degradation" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "governance", "automation", "stop-condition" ], "related_concepts": [ "stop_condition", "governance_trigger" ], "doctrine_answer": "Governance review should trigger when agent or automation telemetry crosses predefined limits for failed validation, reverts, policy exceptions, human overrides, quality drift, incident correlation, or unbounded actions.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "telemetry-008", "domain": "decision_grade_telemetry", "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.", "validation_signal": "Compare the decision to required sources, available evidence, confidence tier, and missing instrumentation.", "persona_relevance": [ "CTO", "CIO", "VP Engineering" ], "use_cases": [ "build_distributed_capacity_strategy", "diagnose_engineering_capacity", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "research question evidence inventory", "metric catalog", "source-system inventory" ], "minimum_evidence": [ "required evidence", "available evidence", "missing instrumentation", "confidence tier" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Governance Completeness" ], "risk_flags": [ "false_confidence", "missing_instrumentation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "missing-data", "confidence", "instrumentation" ], "related_concepts": [ "unknown_evidence", "confidence_tier" ], "doctrine_answer": "A necessary signal is missing when the pending decision requires an evidence class that has no reliable source, insufficient coverage, excessive latency, or an unknown definition; the correct result is an instrumentation gap, not an inferred fact.", "answer_card_template": { "answer_type": "telemetry_trust_answer", "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 this 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.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-001", "domain": "governed_agentic_sdlc", "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.", "validation_signal": "Compare onboarding duration, first accepted PR, documentation usage, correction rate, and escalation frequency.", "persona_relevance": [ "CTO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "work tracker", "pull request system", "documentation analytics", "agent tool logs" ], "minimum_evidence": [ "onboarding duration", "first accepted PR", "documentation usage", "correction rate" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Knowledge Transfer Readiness" ], "risk_flags": [ "ai_context_error", "rework_increase" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "agents", "onboarding", "distributed" ], "related_concepts": [ "agentic_onboarding", "context_acquisition" ], "doctrine_answer": "Agentic workflows reduce onboarding time when they accelerate safe context retrieval, environment setup, task decomposition, and feedback while first accepted work arrives sooner without higher correction or escalation rates.", "answer_card_template": { "answer_type": "agent_delegation_answer", "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 this 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.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-002", "domain": "governed_agentic_sdlc", "question": "Which AI-generated outputs can distributed teams safely validate?", "why_it_matters": "Validation authority must match skill, context, and risk.", "validation_signal": "Classify outputs by reversibility, test coverage, blast radius, required domain knowledge, and approval path.", "persona_relevance": [ "CTO", "AI Governance Leader", "VP Engineering" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "agent tool logs", "pull request system", "CI/CD", "approval workflow" ], "minimum_evidence": [ "output type", "reversibility", "test coverage", "approval path" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "validation_authority_gap", "agent_blast_radius" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "ai-output", "validation", "distributed" ], "related_concepts": [ "validation_authority", "blast_radius" ], "doctrine_answer": "AI-generated output is safely validatable when the reviewer has the required domain context and the output is reversible, testable, provenance-marked, bounded in blast radius, and subject to an explicit approval path.", "answer_card_template": { "answer_type": "agent_delegation_answer", "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 this 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.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-003", "domain": "governed_agentic_sdlc", "question": "Which AI tools are allowed for each contributor type?", "why_it_matters": "AI usage creates data exposure, IP, and governance risk.", "validation_signal": "Map contributor type to approved tools, data classes, repository access, prompt policy, and audit requirements.", "persona_relevance": [ "CIO", "AI Governance Leader", "CTO" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "AI tool policy", "identity provider", "repository permissions", "audit logs" ], "minimum_evidence": [ "approved tool", "data class", "access class", "audit requirement" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unauthorized_ai_tool", "data_exposure" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "ai-tools", "contributors", "policy" ], "related_concepts": [ "tool_permission", "prompt_policy" ], "doctrine_answer": "Allowed AI tools must be assigned by contributor role, task, data classification, repository boundary, retention policy, permission scope, and audit requirement rather than made universally available.", "answer_card_template": { "answer_type": "agent_delegation_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-004", "domain": "governed_agentic_sdlc", "question": "How are AI-generated PRs reviewed across distributed teams?", "why_it_matters": "AI can increase review burden if review policy is unclear.", "validation_signal": "Track PR provenance, review path, correction rate, test evidence, approval authority, and rollback evidence.", "persona_relevance": [ "CTO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "determine_capacity_absorption_readiness" ], "required_sources": [ "pull request system", "agent tool logs", "CI/CD", "approval workflow" ], "minimum_evidence": [ "PR provenance", "review path", "correction rate", "test evidence" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Execution Determinism" ], "risk_flags": [ "review_burden", "unknown_pr_provenance" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "ai-pr", "review", "provenance" ], "related_concepts": [ "pr_provenance", "review_policy" ], "doctrine_answer": "AI-generated pull requests require recorded provenance, automated test evidence, risk-based human review, correction tracking, approval authority, and rollback readiness equivalent to or stronger than human-generated changes.", "answer_card_template": { "answer_type": "agent_delegation_answer", "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 this 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.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-005", "domain": "governed_agentic_sdlc", "question": "What telemetry detects agent-generated rework?", "why_it_matters": "AI productivity claims are weak unless rework is measured.", "validation_signal": "Compare reopened tickets, review corrections, failed tests, reverted commits, escaped defects, and cycle-time impact.", "persona_relevance": [ "CTO", "AI Governance Leader", "VP Engineering" ], "use_cases": [ "assess_agentic_sdlc_readiness", "diagnose_engineering_capacity" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "quality system", "deployment system" ], "minimum_evidence": [ "reopened ticket", "review correction", "failed test", "reverted commit" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Telemetry Trust" ], "risk_flags": [ "agent_rework", "false_productivity" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cto", "tags": [ "agent-rework", "telemetry", "quality" ], "related_concepts": [ "rework_signal", "ai_productivity" ], "doctrine_answer": "Agent-generated rework is detected by linking AI provenance to review corrections, reopened work, failed tests, reverted changes, escaped defects, and downstream cycle-time impact.", "answer_card_template": { "answer_type": "agent_delegation_answer", "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 this 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.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "agent-006", "domain": "governed_agentic_sdlc", "question": "Which workflows should remain human-gated until trust improves?", "why_it_matters": "Agentic delegation should expand only when validation and governance mature.", "validation_signal": "Identify workflows with high ambiguity, sensitive data, customer impact, production impact, or irreversible consequences.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "workflow catalog", "security classification", "incident system", "approval policy" ], "minimum_evidence": [ "ambiguity class", "data sensitivity", "production impact", "approval requirement" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness" ], "risk_flags": [ "unsafe_agent_delegation", "irreversible_action" ], "recommended_report_type": "Agent Delegation Safety Matrix", "intent": "diagnostic", "level": "cio", "tags": [ "human-gated", "agents", "risk" ], "related_concepts": [ "human_gate", "trust_boundary" ], "doctrine_answer": "Workflows with high ambiguity, sensitive data, architecture authority, customer or production impact, weak validation, or irreversible consequences should remain human-gated until evidence demonstrates bounded agent reliability.", "answer_card_template": { "answer_type": "agent_delegation_answer", "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 this 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.", "recommended_report_section": "Agent Delegation Safety Matrix", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-001", "domain": "governed_adaptive_control_loops", "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.", "validation_signal": "Verify recommendation source, evidence trail, approval path, rollback path, and post-change measurement.", "persona_relevance": [ "CTO", "CIO", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "telemetry platform", "workflow rules", "approval workflow", "audit logs" ], "minimum_evidence": [ "recommendation", "evidence trail", "approval path", "rollback path" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Agent Delegation Safety", "Governance Completeness", "Upside Potential" ], "risk_flags": [ "unapproved_self_modification", "automation_overreach" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "intent": "diagnostic", "level": "cto", "tags": [ "adaptive", "recommendation", "governance" ], "related_concepts": [ "adaptive_control", "governed_recommendation" ], "doctrine_answer": "The system may generate evidence-backed workflow recommendations without applying them; each recommendation must expose its source signals, assumptions, expected effect, approval path, measurement plan, and rollback condition.", "answer_card_template": { "answer_type": "adaptive_control_answer", "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 this 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.", "recommended_report_section": "Governed Adaptive Control Loop Review", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-002", "domain": "governed_adaptive_control_loops", "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.", "validation_signal": "Classify rules by blast radius, reversibility, policy class, source-system owner, and required approval.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader", "DevOps Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "workflow rules", "CI/CD config", "policy documentation", "audit logs" ], "minimum_evidence": [ "rule class", "blast radius", "reversibility", "approval requirement" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "rule_modification_risk", "policy_bypass" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "intent": "diagnostic", "level": "cio", "tags": [ "workflow-rules", "adaptive", "policy" ], "related_concepts": [ "rule_class", "workflow_modification" ], "doctrine_answer": "Only reversible, observable, low-blast-radius workflow rules may be adaptive by default; security, compliance, architecture, data, and production authority rules require explicit human governance.", "answer_card_template": { "answer_type": "adaptive_control_answer", "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 this 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.", "recommended_report_section": "Governed Adaptive Control Loop Review", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-003", "domain": "governed_adaptive_control_loops", "question": "How does the system detect when adaptive changes degrade performance?", "why_it_matters": "Learning loops need negative feedback and stop conditions.", "validation_signal": "Monitor quality drift, cycle-time degradation, failed validations, human override rate, incident correlation, and rollback triggers after adaptive changes.", "persona_relevance": [ "CTO", "AI Governance Leader", "Platform Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "diagnose_engineering_capacity" ], "required_sources": [ "telemetry platform", "agent tool logs", "CI/CD", "incident system", "rollback records" ], "minimum_evidence": [ "post-change delta", "quality drift", "override rate", "rollback trigger" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Telemetry Trust", "Agent Delegation Safety", "Upside Potential" ], "risk_flags": [ "recursive_degradation", "missing_negative_feedback" ], "recommended_report_type": "Governed Adaptive Control Loop Review", "intent": "diagnostic", "level": "cto", "tags": [ "degradation", "feedback", "adaptive" ], "related_concepts": [ "negative_feedback", "post_change_delta" ], "doctrine_answer": "Adaptive degradation is detected by comparing post-change quality, cycle time, failed validation, override, incident, and rollback signals against baselines and predefined stop conditions.", "answer_card_template": { "answer_type": "adaptive_control_answer", "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 this 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.", "recommended_report_section": "Governed Adaptive Control Loop Review", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "adaptive-004", "domain": "governed_adaptive_control_loops", "question": "Who can approve, audit, and reverse adaptive changes to the SDLC?", "why_it_matters": "Self-improving systems require explicit authority and reversibility.", "validation_signal": "Map adaptive change classes to approvers, audit logs, rollback authority, exception handling, and stop conditions.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "assess_agentic_sdlc_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "policy documentation", "approval workflow", "audit logs", "rollback records" ], "minimum_evidence": [ "approver", "audit log", "rollback authority", "stop condition" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "authority_gap", "irreversible_adaptive_change" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "approval", "audit", "adaptive" ], "related_concepts": [ "adaptive_authority", "rollback_authority" ], "doctrine_answer": "Every adaptive change class must have named approval authority, immutable audit evidence, an accountable system owner, independent rollback authority, and defined emergency stop conditions.", "answer_card_template": { "answer_type": "adaptive_control_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-001", "domain": "governance_security_failure_modes", "question": "Who owns delivery risk for externally or agent-produced work?", "why_it_matters": "Distributed and AI-assisted delivery require clear accountability.", "validation_signal": "Map work ownership to accountable leaders, review authority, approval paths, and incident responsibility.", "persona_relevance": [ "CIO", "CTO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "improve_existing_capacity_topology", "assess_agentic_sdlc_readiness" ], "required_sources": [ "ownership map", "approval workflow", "incident system", "contracts or operating agreements" ], "minimum_evidence": [ "accountable owner", "review authority", "approval path", "incident responsibility" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Topology Fit" ], "risk_flags": [ "accountability_gap", "delivery_risk" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "accountability", "risk", "external-work" ], "related_concepts": [ "delivery_risk_owner", "accountability" ], "doctrine_answer": "Delivery risk remains owned by the accountable internal leader who authorizes the work and controls acceptance, production approval, and incident response, even when execution is external or agent-assisted.", "answer_card_template": { "answer_type": "governance_failure_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-002", "domain": "governance_security_failure_modes", "question": "Which production actions require internal approval?", "why_it_matters": "Production authority must be explicit in distributed systems.", "validation_signal": "Classify deployment, rollback, data migration, configuration, and incident actions by approval requirement.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "improve_existing_capacity_topology" ], "required_sources": [ "deployment system", "approval workflow", "policy documentation", "audit logs" ], "minimum_evidence": [ "production action", "approval requirement", "approver", "audit record" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Execution Determinism" ], "risk_flags": [ "production_authority_gap", "approval_bypass" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "production", "approval", "governance" ], "related_concepts": [ "production_authority", "approval_requirement" ], "doctrine_answer": "Internal approval is required for production actions whose blast radius, data impact, customer effect, irreversibility, or regulatory significance exceeds the organization's predefined authority threshold.", "answer_card_template": { "answer_type": "governance_failure_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-003", "domain": "governance_security_failure_modes", "question": "Which systems are off-limits to external contributors or agents?", "why_it_matters": "Security boundaries must be defined before capacity is distributed.", "validation_signal": "Verify restrictions for sensitive repositories, customer data, secrets, regulated systems, production environments, and privileged tools.", "persona_relevance": [ "CIO", "AI Governance Leader", "CTO" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "security policy", "repository permissions", "identity provider", "data classification" ], "minimum_evidence": [ "restricted system", "access boundary", "data class", "privileged tool" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "security_boundary_gap", "privileged_access_overreach" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "security", "off-limits", "access" ], "related_concepts": [ "security_boundary", "restricted_system" ], "doctrine_answer": "External contributors and agents must be excluded from systems whose data sensitivity, privilege level, regulatory boundary, strategic IP, or production blast radius cannot be contained by least-privilege controls.", "answer_card_template": { "answer_type": "governance_failure_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-004", "domain": "governance_security_failure_modes", "question": "How is IP assignment and contribution provenance verified?", "why_it_matters": "External and AI-assisted work creates IP and ownership questions.", "validation_signal": "Review contracts, contributor agreements, commit provenance, PR metadata, tool usage logs, and approval records.", "persona_relevance": [ "CIO", "CTO", "AI Governance Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "assess_agentic_sdlc_readiness", "improve_existing_capacity_topology" ], "required_sources": [ "contracts or operating agreements", "repository metadata", "agent tool logs", "approval records" ], "minimum_evidence": [ "IP assignment", "commit provenance", "tool usage log", "approval record" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Agent Delegation Safety" ], "risk_flags": [ "ip_provenance_gap", "unverified_contribution" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "ip", "provenance", "contributions" ], "related_concepts": [ "ip_assignment", "contribution_provenance" ], "doctrine_answer": "IP assignment and contribution provenance are verified through enforceable agreements, authenticated contributor identity, commit and PR provenance, AI-tool disclosure, review records, and acceptance history.", "answer_card_template": { "answer_type": "governance_failure_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-005", "domain": "governance_security_failure_modes", "question": "How are policy exceptions logged and reviewed?", "why_it_matters": "Exceptions reveal where governance is weak or misaligned with reality.", "validation_signal": "Compare exception records, approval paths, recurrence, business justification, and remediation actions.", "persona_relevance": [ "CIO", "CTO", "DevOps Leader" ], "use_cases": [ "evaluate_governance_security_and_ip_risk", "diagnose_engineering_capacity" ], "required_sources": [ "policy exception logs", "approval workflow", "audit logs", "incident system" ], "minimum_evidence": [ "exception record", "approval path", "recurrence", "remediation action" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Telemetry Trust" ], "risk_flags": [ "policy_exception_drift", "governance_lag" ], "recommended_report_type": "Governance, Security, and IP Control Report", "intent": "diagnostic", "level": "cio", "tags": [ "policy-exception", "audit", "governance" ], "related_concepts": [ "policy_exception", "remediation" ], "doctrine_answer": "Policy exceptions require a timestamped request, business justification, accountable approver, bounded duration, affected assets, compensating controls, remediation owner, recurrence review, and closure evidence.", "answer_card_template": { "answer_type": "governance_failure_answer", "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 this 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.", "recommended_report_section": "Governance, Security, and IP Control Report", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } }, { "id": "gov-006", "domain": "governance_security_failure_modes", "question": "What breaks first when capacity, distribution, or automation increases?", "why_it_matters": "Failure-mode analysis turns scaling plans into testable risk hypotheses.", "validation_signal": "Inspect hidden queues, review bottlenecks, architecture latency, pipeline drift, context loss, agent rework, security access, and governance lag.", "persona_relevance": [ "CTO", "CIO", "VP Engineering", "AI Governance Leader" ], "use_cases": [ "diagnose_engineering_capacity", "determine_capacity_absorption_readiness", "evaluate_governance_security_and_ip_risk" ], "required_sources": [ "work tracker", "pull request system", "CI/CD", "incident system", "audit logs" ], "minimum_evidence": [ "hidden queue", "review bottleneck", "pipeline drift", "governance lag" ], "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.", "confidence_rubric": { "high": "90+ days of source-system evidence across the included teams, services, and delivery paths.", "medium": "30-90 days of evidence with partial source-system coverage.", "directional": "Limited sample, incomplete source coverage, or qualitative evidence that still points to a useful hypothesis.", "unknown": "No reliable evidence is available for the question." }, "score_dimensions": [ "Governance Completeness", "Capacity Reality", "Execution Determinism" ], "risk_flags": [ "failure_mode_unknown", "scaling_degradation" ], "recommended_report_type": "Engineering Capacity OS Diagnostic", "intent": "diagnostic", "level": "cto", "tags": [ "failure-mode", "scaling", "risk" ], "related_concepts": [ "failure_mode_register", "scaling_risk" ], "doctrine_answer": "The first scaling failure is the constraint whose demand grows faster than its control capacity; test this across review queues, architecture decisions, knowledge transfer, pipeline consistency, agent rework, access control, and governance latency.", "answer_card_template": { "answer_type": "governance_failure_answer", "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 this 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.", "recommended_report_section": "Engineering Capacity OS Diagnostic", "required_fields": [ "question_id", "domain", "question", "doctrine_answer", "evidence_summary", "observed_state", "confidence", "source_classes", "missing_evidence", "risk_flags", "recommended_report_section", "next_safe_action", "do_not_collect" ], "safe_answer_boundary": "Answer with aggregate, redacted, source-cited evidence only. If the evidence is missing, mark the answer unknown and recommend instrumentation." } } ], "metadata": { "total": 60, "filtered": 60, "version": "3.0" } }