From 1a74bcddce3cf83c4781a93bc8bac28c07667873 Mon Sep 17 00:00:00 2001
From: Larry the Laptop Lobster <larry@651-pudding-hill.local>
Date: Wed, 11 Feb 2026 18:43:07 -0500
Subject: [PATCH] docs: append deep implementation sections to proposals 01-20
 and 51

---
 docs/proposals/01-agent-smart-routing.md      | 34 ++++++++++++++++++
 docs/proposals/02-plans-as-LLM-templates.md   | 30 ++++++++++++++++
 .../03-distributed-plan-execution.md          | 27 ++++++++++++++
 .../04-plan-explain-as-API-service.md         | 30 ++++++++++++++++
 .../05-semantic-plan-search-graph.md          | 27 ++++++++++++++
 docs/proposals/06-adopt-on-the-fly.md         | 27 ++++++++++++++
 docs/proposals/07-elo-ranking.md              | 27 ++++++++++++++
 docs/proposals/08-ui-for-editing-plan.md      | 27 ++++++++++++++
 .../11-investor-thesis-matching-engine.md     | 27 ++++++++++++++
 ...-evidence-based-founder-execution-index.md | 27 ++++++++++++++
 .../13-portfolio-aware-capital-allocation.md  | 29 ++++++++++++++-
 ...14-confidence-weighted-funding-auctions.md | 29 ++++++++++++++-
 ...5-outcome-feedback-and-model-governance.md | 29 ++++++++++++++-
 .../16-on-demand-plugin-synthesis-hub.md      | 27 ++++++++++++++
 .../17-plugin-adaptation-lifecycle.md         | 27 ++++++++++++++
 ...18-plugin-benchmarking-coverage-harness.md | 27 ++++++++++++++
 ...n-safety-governance-for-runtime-loading.md | 27 ++++++++++++++
 ...-plugin-hub-discovery-ranking-and-reuse.md | 27 ++++++++++++++
 .../51-decentralized-planexe-survivability.md | 36 +++++++++++++++++++
 19 files changed, 538 insertions(+), 3 deletions(-)

diff --git a/docs/proposals/01-agent-smart-routing.md b/docs/proposals/01-agent-smart-routing.md
index 4ccfeb2de..090472408 100644
--- a/docs/proposals/01-agent-smart-routing.md
+++ b/docs/proposals/01-agent-smart-routing.md
@@ -116,3 +116,37 @@ Store routing configuration in `llm_config.json`:
 - User satisfaction rating increases (via post-plan survey)
 
 - No increase in pipeline failure rate
+
+## Detailed Implementation Plan
+
+### Phase A — Routing Contract and Registry
+
+1. Define an explicit routing contract in `run_plan_pipeline.py` with:
+   - stage name
+   - routing signal inputs
+   - selected agent class
+   - fallback class
+2. Build an agent registry file (YAML/JSON) mapping capabilities to stages.
+3. Add deterministic routing mode for reproducible runs.
+
+### Phase B — Dynamic Selection Engine
+
+1. Implement router scoring using:
+   - stage complexity
+   - domain type
+   - latency/cost budget
+2. Add weighted scoring for each candidate agent and choose top-ranked.
+3. Add confidence threshold to trigger fallback routing when uncertain.
+
+### Phase C — Observability and Controls
+
+1. Emit route decisions as structured events.
+2. Track route success/failure by stage.
+3. Add policy overrides for forced agent selection in sensitive flows.
+
+### Validation Checklist
+
+- Deterministic routing under fixed seeds
+- Correct fallback activation under low confidence
+- Route-quality lift vs static baseline
+
diff --git a/docs/proposals/02-plans-as-LLM-templates.md b/docs/proposals/02-plans-as-LLM-templates.md
index 8b44f847c..6b1a8f63a 100644
--- a/docs/proposals/02-plans-as-LLM-templates.md
+++ b/docs/proposals/02-plans-as-LLM-templates.md
@@ -184,3 +184,33 @@ CREATE TABLE plan_templates (
 - Jinja2 documentation: https://jinja.palletsprojects.com/
 
 - Similar pattern: Terraform modules, Helm charts, AWS CloudFormation templates
+
+## Detailed Implementation Plan
+
+### Phase A — Template Spec
+
+1. Define template schema with:
+   - variables
+   - defaults
+   - required constraints
+   - output contract
+2. Add validation to reject unresolved variables at render time.
+
+### Phase B — Render Pipeline
+
+1. Convert plan sections into parameterized templates.
+2. Support profile-specific render presets (investor, technical, compliance).
+3. Add preview endpoint to inspect rendered output before execution.
+
+### Phase C — Governance
+
+1. Version templates and freeze approved revisions.
+2. Add compatibility checker between template versions and old plans.
+3. Log rendered parameter values for auditability.
+
+### Validation Checklist
+
+- No unresolved placeholders in final render
+- Backward compatibility checks pass
+- Render latency within interactive SLA
+
diff --git a/docs/proposals/03-distributed-plan-execution.md b/docs/proposals/03-distributed-plan-execution.md
index 6129eb195..86169b130 100644
--- a/docs/proposals/03-distributed-plan-execution.md
+++ b/docs/proposals/03-distributed-plan-execution.md
@@ -218,3 +218,30 @@ def execute_outline_stage(plan_id, research_results):
 - Railway multi-service deploys: https://docs.railway.app/
 
 - DAG scheduling patterns: Apache Airflow, Prefect, Temporal
+
+## Detailed Implementation Plan
+
+### Phase A — Distributed Runtime Topology
+
+1. Define coordinator + worker architecture.
+2. Partition execution graph into shardable task groups.
+3. Add worker heartbeat and lease ownership semantics.
+
+### Phase B — Queue and Retry Semantics
+
+1. Introduce queue topics by task class and priority.
+2. Implement idempotent workers with attempt counters.
+3. Add dead-letter queues and replay tooling.
+
+### Phase C — Consistency and Recovery
+
+1. Persist checkpoint snapshots per milestone.
+2. Implement coordinator failover strategy.
+3. Add exactly-once/at-least-once mode selection by task type.
+
+### Validation Checklist
+
+- Throughput scaling under worker expansion
+- Recovery time after worker/node failure
+- No duplicate side effects for idempotent tasks
+
diff --git a/docs/proposals/04-plan-explain-as-API-service.md b/docs/proposals/04-plan-explain-as-API-service.md
index b93351011..9ad3a4cb4 100644
--- a/docs/proposals/04-plan-explain-as-API-service.md
+++ b/docs/proposals/04-plan-explain-as-API-service.md
@@ -254,3 +254,33 @@ post_to_twitter(tweet)
 - Prompt engineering best practices: Anthropic prompt guide
 
 - Caching strategies: Redis best practices
+
+## Detailed Implementation Plan
+
+### Phase A — Explainability Contract
+
+1. Define explanation schema:
+   - summary
+   - rationale
+   - assumptions
+   - caveats
+2. Add response styles (executive, technical, regulator).
+
+### Phase B — API + Caching
+
+1. Implement explanation endpoint with plan version hash keying.
+2. Add cache layer with invalidation on plan updates.
+3. Add token/cost controls for explanation generation.
+
+### Phase C — Quality and Safety
+
+1. Add hallucination guards using evidence references.
+2. Add sensitivity filters for confidential sections.
+3. Include confidence labels and uncertainty notes.
+
+### Validation Checklist
+
+- Explanation consistency across reruns
+- Evidence reference coverage thresholds
+- Low hallucination rate in review samples
+
diff --git a/docs/proposals/05-semantic-plan-search-graph.md b/docs/proposals/05-semantic-plan-search-graph.md
index 6d9bae071..812ecfd1f 100644
--- a/docs/proposals/05-semantic-plan-search-graph.md
+++ b/docs/proposals/05-semantic-plan-search-graph.md
@@ -359,3 +359,30 @@ redis.setex(cache_key, 3600, json.dumps(results))  # 1h TTL
 - sentence-transformers: https://www.sbert.net/
 
 - Semantic search best practices: https://www.pinecone.io/learn/semantic-search/
+
+## Detailed Implementation Plan
+
+### Phase A — Index Foundation
+
+1. Build embedding pipeline for plan sections and metadata.
+2. Store vectors in pgvector with namespace partitioning.
+3. Define hybrid retrieval (semantic + keyword + metadata filters).
+
+### Phase B — Graph Layer
+
+1. Create plan similarity edges with confidence scores.
+2. Add relation types (similar-risk, similar-finance, similar-domain).
+3. Expose neighborhood exploration APIs.
+
+### Phase C — Ranking and Feedback
+
+1. Rank results with blended score (similarity + quality + freshness).
+2. Capture click/selection feedback to tune ranking.
+3. Add dedup and near-duplicate suppression.
+
+### Validation Checklist
+
+- Retrieval precision@k
+- Latency under index growth
+- Duplicate suppression effectiveness
+
diff --git a/docs/proposals/06-adopt-on-the-fly.md b/docs/proposals/06-adopt-on-the-fly.md
index 5c2e43978..adb451555 100644
--- a/docs/proposals/06-adopt-on-the-fly.md
+++ b/docs/proposals/06-adopt-on-the-fly.md
@@ -251,3 +251,30 @@ Phase 4 - Measure + iterate
 - Do not touch `open_dir_server` allowlist/path validation unless explicitly asked.
 
 - Do not change MCP to advertise tasks protocol ("Run as task") - tools-only stays.
+
+## Detailed Implementation Plan
+
+### Phase A — Focus Classification Runtime
+
+1. Add pre-planning classifier stage for business/software/hybrid focus.
+2. Emit confidence and missing-info flags.
+3. Support explicit user override with trace logging.
+
+### Phase B — Track-Specific Prompting and Levers
+
+1. Build track prompt packs for business and software tracks.
+2. Route lever generation using track-aware templates.
+3. Enforce mandatory lever coverage per selected track.
+
+### Phase C — Track-Specific Gates
+
+1. Define no-go gate sets by track.
+2. Add auto-fail conditions for missing critical artifacts.
+3. Add hybrid sequencing logic for mixed plans.
+
+### Validation Checklist
+
+- Classification accuracy benchmark
+- Gate relevance by plan type
+- User override frequency and satisfaction
+
diff --git a/docs/proposals/07-elo-ranking.md b/docs/proposals/07-elo-ranking.md
index 81194761e..4ce32ba63 100644
--- a/docs/proposals/07-elo-ranking.md
+++ b/docs/proposals/07-elo-ranking.md
@@ -1661,3 +1661,30 @@ Completed items for immediate usability improvements:
 **Last updated:** 2026-02-08  
 **Maintainer:** OpenClaw team  
 **Feedback:** Open issues at https://github.com/VoynichLabs/PlanExe2026/issues
+
+## Detailed Implementation Plan
+
+### Phase A — Pairwise Ranking Core
+
+1. Implement candidate sampling strategy.
+2. Run pairwise comparisons with structured KPI outputs.
+3. Apply Elo updates with configurable K-factor profiles.
+
+### Phase B — Data Products
+
+1. Store per-comparison details and reasons.
+2. Generate percentile tiers and confidence bands.
+3. Add per-user and global leaderboard views.
+
+### Phase C — Calibration and Governance
+
+1. Calibrate ranking against real outcomes (where available).
+2. Add anti-gaming heuristics and anomaly detection.
+3. Add periodic re-ranking for drift control.
+
+### Validation Checklist
+
+- Ranking stability across reruns
+- Predictive value vs downstream outcomes
+- Fairness checks across domains
+
diff --git a/docs/proposals/08-ui-for-editing-plan.md b/docs/proposals/08-ui-for-editing-plan.md
index ea9737757..4ae4a7097 100644
--- a/docs/proposals/08-ui-for-editing-plan.md
+++ b/docs/proposals/08-ui-for-editing-plan.md
@@ -81,3 +81,30 @@ Limitations:
 - As execution reveals surprises, incorporate them into the existing plan.
 
 - Maintain topological ordering so downstream parts update correctly.
+
+## Detailed Implementation Plan
+
+### Phase A — Editor Data Model
+
+1. Define editable plan document schema and version nodes.
+2. Add section-level locking and optimistic concurrency controls.
+3. Persist edit history with reversible diffs.
+
+### Phase B — Collaboration UX
+
+1. Build section editor with structured side panels (assumptions, risks, costs).
+2. Add inline validation and warning badges.
+3. Add comparison view for baseline vs edited variants.
+
+### Phase C — Workflow Integration
+
+1. Trigger downstream recalculations on critical edits.
+2. Add approval flow for high-impact changes.
+3. Sync edits to audit pack and evidence ledger references.
+
+### Validation Checklist
+
+- Conflict resolution correctness
+- Edit-to-recompute latency
+- Usability score in editor sessions
+
diff --git a/docs/proposals/11-investor-thesis-matching-engine.md b/docs/proposals/11-investor-thesis-matching-engine.md
index c332189b8..4388d6ac4 100644
--- a/docs/proposals/11-investor-thesis-matching-engine.md
+++ b/docs/proposals/11-investor-thesis-matching-engine.md
@@ -224,3 +224,30 @@ Below are three example project archetypes and the specific hypothesis checks th
 ## Why This Matters
 
 This proposal shifts fundraising from persuasion-first to evidence-first. It helps credible, high-upside plans get surfaced even when founders are not exceptional marketers, improving capital allocation efficiency for everyone.
+
+## Detailed Implementation Plan
+
+### Phase A — Thesis Schema and Intake
+
+1. Define investor thesis schema (sector, ticket size, geography, stage, constraints).
+2. Ingest and normalize investor profile records.
+3. Add confidence labels for inferred thesis signals.
+
+### Phase B — Matching Engine
+
+1. Compute thesis-plan alignment with weighted feature scoring.
+2. Add exclusion filters (hard constraints).
+3. Produce explainable match reasons and mismatch flags.
+
+### Phase C — Feedback Loop
+
+1. Capture investor response outcomes.
+2. Tune matching weights with outcome data.
+3. Add cold-start defaults by investor archetype.
+
+### Validation Checklist
+
+- Precision of top matches
+- Response-rate uplift vs baseline outreach
+- Explainability quality review
+
diff --git a/docs/proposals/12-evidence-based-founder-execution-index.md b/docs/proposals/12-evidence-based-founder-execution-index.md
index 0b98ff0c7..4f5757c0a 100644
--- a/docs/proposals/12-evidence-based-founder-execution-index.md
+++ b/docs/proposals/12-evidence-based-founder-execution-index.md
@@ -204,3 +204,30 @@ Create a **Founder Execution Index (FEI)** calculated from measurable evidence:
 ## Why This Matters
 
 A transparent execution index gives investors a stronger ROI signal and gives disciplined builders a fairer path to capital, independent of pitch theatrics.
+
+## Detailed Implementation Plan
+
+### Phase A — Signal Definition
+
+1. Define founder execution signals (delivery cadence, milestone completion, evidence quality).
+2. Add normalization across project sizes and stages.
+3. Set anti-manipulation controls for self-reported metrics.
+
+### Phase B — Index Calculation
+
+1. Compute composite index with transparent weights.
+2. Attach confidence intervals based on data completeness.
+3. Version index formulas for auditability.
+
+### Phase C — Product Surfaces
+
+1. Show index trendline over time.
+2. Expose driver-level breakdown for coaching actions.
+3. Feed index into investor matching and readiness gates.
+
+### Validation Checklist
+
+- Correlation with independent execution outcomes
+- Stability under sparse data
+- Resistance to metric gaming
+
diff --git a/docs/proposals/13-portfolio-aware-capital-allocation.md b/docs/proposals/13-portfolio-aware-capital-allocation.md
index 0477840d8..bd2b18d2a 100644
--- a/docs/proposals/13-portfolio-aware-capital-allocation.md
+++ b/docs/proposals/13-portfolio-aware-capital-allocation.md
@@ -134,4 +134,31 @@ For each investor:
 
 ## Why This Matters
 
-Investors care about total portfolio outcomes, not isolated deal quality. Portfolio-aware matching improves capital allocation quality and makes ROI predictions more actionable.
\ No newline at end of file
+Investors care about total portfolio outcomes, not isolated deal quality. Portfolio-aware matching improves capital allocation quality and makes ROI predictions more actionable.
+
+## Detailed Implementation Plan
+
+### Phase A — Portfolio Model
+
+1. Define portfolio objective functions (return, risk, diversification).
+2. Add constraint model (sector caps, stage caps, geographic limits).
+3. Ingest candidate plan opportunities as allocatable units.
+
+### Phase B — Allocation Solver
+
+1. Implement optimizer (heuristic + optional convex optimization mode).
+2. Support scenario-based allocation stress tests.
+3. Output recommended allocations with rationale and alternatives.
+
+### Phase C — Monitoring and Rebalancing
+
+1. Track realized vs expected performance.
+2. Trigger rebalance suggestions on drift.
+3. Log decision history for governance review.
+
+### Validation Checklist
+
+- Constraint satisfaction rate
+- Risk-adjusted return vs baseline policy
+- Rebalance action quality over time
+
diff --git a/docs/proposals/14-confidence-weighted-funding-auctions.md b/docs/proposals/14-confidence-weighted-funding-auctions.md
index 45cd0db9e..7da227319 100644
--- a/docs/proposals/14-confidence-weighted-funding-auctions.md
+++ b/docs/proposals/14-confidence-weighted-funding-auctions.md
@@ -133,4 +133,31 @@ Implement a **Confidence-Weighted Auction Protocol**:
 
 ## Why This Matters
 
-Structured auctions create better price discovery and better ROI alignment while reducing dependence on personal charisma and closed-door negotiation dynamics.
\ No newline at end of file
+Structured auctions create better price discovery and better ROI alignment while reducing dependence on personal charisma and closed-door negotiation dynamics.
+
+## Detailed Implementation Plan
+
+### Phase A — Auction Mechanism Design
+
+1. Define bid object with confidence and evidence support fields.
+2. Set auction rules (sealed/open, rounds, reserve conditions).
+3. Add anti-collusion and identity integrity checks.
+
+### Phase B — Confidence Weighting Engine
+
+1. Compute confidence-adjusted bid utility score.
+2. Penalize low-evidence high-claims bids.
+3. Expose explainable ranking to participants.
+
+### Phase C — Settlement and Post-Auction Analytics
+
+1. Finalize winners with compliance checks.
+2. Record auction telemetry for mechanism tuning.
+3. Add dispute workflow and audit exports.
+
+### Validation Checklist
+
+- Bid quality improvement over rounds
+- Reduction of winner’s-curse outcomes
+- Fairness and manipulation resistance tests
+
diff --git a/docs/proposals/15-outcome-feedback-and-model-governance.md b/docs/proposals/15-outcome-feedback-and-model-governance.md
index d5ee4d399..6f30e0a5e 100644
--- a/docs/proposals/15-outcome-feedback-and-model-governance.md
+++ b/docs/proposals/15-outcome-feedback-and-model-governance.md
@@ -136,4 +136,31 @@ Implement an **Outcome Intelligence Layer** that:
 
 ## Why This Matters
 
-A matching engine is only valuable if it stays correct over time. Governance plus feedback transforms it from a static ranking tool into a reliable capital allocation system that compounds ROI advantage.
\ No newline at end of file
+A matching engine is only valuable if it stays correct over time. Governance plus feedback transforms it from a static ranking tool into a reliable capital allocation system that compounds ROI advantage.
+
+## Detailed Implementation Plan
+
+### Phase A — Outcome Telemetry Contract
+
+1. Define standardized outcome schema (win/loss, cost variance, schedule variance, quality outcome).
+2. Build ingestion endpoints and integrity checks.
+3. Add outcome confidence and source provenance fields.
+
+### Phase B — Governance Evaluation Loop
+
+1. Compare model predictions vs realized outcomes.
+2. Flag drift and underperforming model components.
+3. Trigger review workflows for retraining or policy changes.
+
+### Phase C — Governance Board Outputs
+
+1. Generate periodic model health reports.
+2. Maintain change logs for model updates and rationale.
+3. Require signoff on high-impact model policy changes.
+
+### Validation Checklist
+
+- Outcome ingestion completeness
+- Drift detection sensitivity/specificity
+- Governance decision turnaround SLAs
+
diff --git a/docs/proposals/16-on-demand-plugin-synthesis-hub.md b/docs/proposals/16-on-demand-plugin-synthesis-hub.md
index 65b8a9e35..4873aa434 100644
--- a/docs/proposals/16-on-demand-plugin-synthesis-hub.md
+++ b/docs/proposals/16-on-demand-plugin-synthesis-hub.md
@@ -100,3 +100,30 @@ Create a synthesis hub that:
 - Human review gates for sensitive plugins.
 - Continual learning from production failures.
 - Automatic deprecation of low-usage plugins.
+
+## Detailed Implementation Plan
+
+### Phase A — Missing Capability Detection
+
+1. Add stage-level capability requirement declarations.
+2. Detect unresolved capability failures at runtime.
+3. Emit synthesis request objects with strict interface contracts.
+
+### Phase B — Synthesis Sandbox
+
+1. Generate plugin skeletons in isolated environment.
+2. Run contract tests, linting, and security scans.
+3. Reject non-compliant plugins automatically.
+
+### Phase C — Hub Registration and Reuse
+
+1. Register validated plugins with version + checksum.
+2. Add capability-indexed lookup for future runs.
+3. Track reuse telemetry and quality outcomes.
+
+### Validation Checklist
+
+- Recovery rate for missing-capability failures
+- Plugin quality gate pass rate
+- Reuse lift across subsequent plans
+
diff --git a/docs/proposals/17-plugin-adaptation-lifecycle.md b/docs/proposals/17-plugin-adaptation-lifecycle.md
index 71e426170..0b94b598d 100644
--- a/docs/proposals/17-plugin-adaptation-lifecycle.md
+++ b/docs/proposals/17-plugin-adaptation-lifecycle.md
@@ -96,3 +96,30 @@ Create a formal adaptation lifecycle with stages:
 - Automated adaptation suggestions.
 - Cross-plugin dependency mapping.
 - Adaptation impact scoring.
+
+## Detailed Implementation Plan
+
+### Phase A — Near-Match Retrieval
+
+1. Retrieve top-k plugins by capability similarity.
+2. Compute fit score against target contract.
+3. Select adaptation candidate above threshold.
+
+### Phase B — Adaptation Pipeline
+
+1. Branch plugin version for adaptation.
+2. Apply scoped modifications with test inheritance.
+3. Validate backward compatibility and performance.
+
+### Phase C — Promotion and Rollback
+
+1. Canary adapted versions in limited traffic.
+2. Auto-promote on success criteria.
+3. Auto-rollback on regression signals.
+
+### Validation Checklist
+
+- Adaptation success vs full re-synthesis
+- Regression incidence after promotion
+- Rollback mean time to recovery
+
diff --git a/docs/proposals/18-plugin-benchmarking-coverage-harness.md b/docs/proposals/18-plugin-benchmarking-coverage-harness.md
index b76ebd983..676e0762f 100644
--- a/docs/proposals/18-plugin-benchmarking-coverage-harness.md
+++ b/docs/proposals/18-plugin-benchmarking-coverage-harness.md
@@ -107,3 +107,30 @@ CoverageScore =
 - Continual learning from live production feedback.
 - Automated benchmark generation from new plans.
 - Plugin performance regression alerts.
+
+## Detailed Implementation Plan
+
+### Phase A — Benchmark Corpus
+
+1. Build scenario matrix by domain and complexity.
+2. Define expected contracts and golden outcomes.
+3. Add adversarial and noisy input suites.
+
+### Phase B — Runner and Scoring
+
+1. Execute plugins across benchmark suites.
+2. Score correctness, robustness, latency, and generalization.
+3. Produce composite quality grade with confidence.
+
+### Phase C — Enforcement and Reporting
+
+1. Block production promotion below minimum grade.
+2. Publish benchmark reports and trend charts.
+3. Trigger re-benchmark on plugin/version changes.
+
+### Validation Checklist
+
+- Coverage breadth across plan domains
+- Correlation between benchmark grade and prod outcomes
+- Drift detection in plugin quality over time
+
diff --git a/docs/proposals/19-plugin-safety-governance-for-runtime-loading.md b/docs/proposals/19-plugin-safety-governance-for-runtime-loading.md
index 18c29028e..86c347814 100644
--- a/docs/proposals/19-plugin-safety-governance-for-runtime-loading.md
+++ b/docs/proposals/19-plugin-safety-governance-for-runtime-loading.md
@@ -98,3 +98,30 @@ Permissions must be approved before runtime activation.
 - Automated static and dynamic code analysis.
 - Third-party certification authority.
 - Differential permissioning by plan sensitivity.
+
+## Detailed Implementation Plan
+
+### Phase A — Policy Engine
+
+1. Define trust tiers and stage-level allow policies.
+2. Enforce signature/checksum/provenance validation.
+3. Add resource limits and execution sandbox constraints.
+
+### Phase B — Runtime Gatekeeper
+
+1. Insert pre-execution gate in plugin load path.
+2. Deny execution when policy mismatch detected.
+3. Log all deny/allow decisions with reasons.
+
+### Phase C — Incident and Lifecycle Controls
+
+1. Implement kill switch per plugin/version.
+2. Add quarantine mode for newly synthesized plugins.
+3. Add security revalidation triggers on dependency updates.
+
+### Validation Checklist
+
+- Unsafe plugin load block rate
+- Incident containment response time
+- Provenance completeness in audit logs
+
diff --git a/docs/proposals/20-plugin-hub-discovery-ranking-and-reuse.md b/docs/proposals/20-plugin-hub-discovery-ranking-and-reuse.md
index fade6a7ed..7c0a5d702 100644
--- a/docs/proposals/20-plugin-hub-discovery-ranking-and-reuse.md
+++ b/docs/proposals/20-plugin-hub-discovery-ranking-and-reuse.md
@@ -107,3 +107,30 @@ RankScore =
 - Revenue sharing models.
 - Federated plugin registries.
 - Automated dependency compatibility checks.
+
+## Detailed Implementation Plan
+
+### Phase A — Retrieval Stack
+
+1. Build semantic capability index for plugins.
+2. Add feature store for rank signals (fit, reliability, recency, reuse).
+3. Implement top-k retrieval with configurable cutoffs.
+
+### Phase B — Ranking Model
+
+1. Compute blended ranking score with policy-tunable weights.
+2. Add duplicate detection and merge recommendations.
+3. Add exploration mode for discovering undervalued plugins.
+
+### Phase C — Feedback and Economy
+
+1. Capture runtime success feedback per plugin use.
+2. Adjust ranking via online updates with decay.
+3. Reward stable high-performing plugins via visibility boosts.
+
+### Validation Checklist
+
+- Top-1 retrieval success rate
+- Duplicate plugin creation reduction
+- Reuse rate growth over time
+
diff --git a/docs/proposals/51-decentralized-planexe-survivability.md b/docs/proposals/51-decentralized-planexe-survivability.md
index ebcfd208d..7377626a4 100644
--- a/docs/proposals/51-decentralized-planexe-survivability.md
+++ b/docs/proposals/51-decentralized-planexe-survivability.md
@@ -193,3 +193,39 @@ Decentralized execution requires explicit safeguards against bad actors and unre
 - Peer-to-peer plan replication and caching.
 - Federated governance council for node standards.
 - Automated multi-provider model routing.
+
+## Detailed Implementation Plan
+
+### Phase A — Survivability Threat Model
+
+1. Define failure scenarios:
+   - cloud provider outage
+   - network partition
+   - key personnel loss
+   - service-level legal/regulatory disruption
+2. Map critical capabilities and single points of failure.
+
+### Phase B — Decentralized Runtime Strategy
+
+1. Define federated node architecture with regional failover.
+2. Replicate critical state using signed append-only logs.
+3. Implement degraded-mode operations for partial outages.
+
+### Phase C — Recovery and Continuity Playbooks
+
+1. Add automated failover orchestration and health probes.
+2. Add disaster recovery drills and RTO/RPO targets.
+3. Publish continuity runbooks and command paths.
+
+### Phase D — Governance and Trust
+
+1. Define cross-node trust and key rotation policies.
+2. Add tamper-evident audit synchronization.
+3. Add survivability scorecard for quarterly reviews.
+
+### Validation Checklist
+
+- Recovery time objective achievement
+- State consistency after failover
+- Degraded-mode service availability under stress tests
+
