feat(radar): make architecture governance proportional (#357)

Replace board-centric defaults with consequence-driven governance modes, feedback loops, exceptions, and clear ownership boundaries.\n\nAI-assisted: Jasper orchestrated implementation and verification with OpenCode.

Signed-off-by: Magnus Hedemark <magnus919@pm.me>

.claude-plugin/marketplace.json

@@ -1173,7 +1173,7 @@
         "./technology-radar"
       ],
       "strict": false,
-      "description": "Build and maintain technology radars for adoption, trial, assessment, and hold decisions. Use when governing technology choices, build-versus-buy decisions, or engineering portfolio risk."
+      "description": "Build and maintain technology radars for adoption, trial, assessment, and hold decisions, and choose proportionate architecture-governance paths for technology portfolios. Use when governing technology choices, build-versus-buy decisions, architecture standards, exceptions, or engineering portfolio risk. Do not use for enterprise capability or target-state architecture, writing ADRs, implementing systems, security engineering, or operational incident/runbook work."
     },
     {
       "name": "telemetry",

README.md

@@ -533,7 +533,7 @@ Make documentation useful at the moment someone needs to install, operate, exten
 
 ### [technology-radar](technology-radar/SKILL.md)
 
-Turn scattered technology preferences into explicit, reviewable decisions with owners, evidence, and a clear adoption posture.
+Turn technology preferences and architecture-governance choices into explicit, reviewable decisions with owners, evidence, and a proportionate adoption posture.
 
 ### [telemetry](telemetry/SKILL.md)
 

llms.txt

@@ -131,7 +131,7 @@
 - [systematic-debugging](systematic-debugging/SKILL.md): 4-phase root cause debugging protocol: understand bugs before fixing. Use for ANY technical issue — test failures, production bugs, unexpected behavior, performance problems, build failures, or integration issues. ESPECIALLY when under time pressure, when "one quick fix" seems obvious, or when previous fix attempts have failed.
 - [tailscale](tailscale/SKILL.md): Deploy and manage the self-hosted Tailscale/Headscale ecosystem: a Headscale control server, tailscale clients, ACL policies, node lifecycle, subnet routing, DERP relays, and backup/migration. Use when the user mentions Tailscale, Headscale, tailnet, mesh VPN, WireGuard mesh, or self-hosted VPN infrastructure.
 - [technical-documentation](technical-documentation/SKILL.md): Create and review technical documentation, including READMEs, agent-facing instructions, API references, and CLI help. Use when documentation must help someone complete real work. Do not use for marketing copy, brand messaging, or long-form editorial content.
-- [technology-radar](technology-radar/SKILL.md): Build and maintain technology radars for adoption, trial, assessment, and hold decisions. Use when governing technology choices, build-versus-buy decisions, or engineering portfolio risk.
+- [technology-radar](technology-radar/SKILL.md): Build and maintain technology radars for adoption, trial, assessment, and hold decisions, and choose proportionate architecture-governance paths for technology portfolios. Use when governing technology choices, build-versus-buy decisions, architecture standards, exceptions, or engineering portfolio risk. Do not use for enterprise capability or target-state architecture, writing ADRs, implementing systems, security engineering, or operational incident/runbook work.
 - [telemetry](telemetry/SKILL.md): Operate the observability stack that deploys as one unit: Prometheus scrape configuration, recording and alerting rules, relabeling, retention, and high availability; OpenTelemetry Collector pipelines (receivers, processors, exporters, sampling, trace/span correlation); and Loki ingest, LogQL, retention, and label design — with a bundled read-only telemetry-check script for Prometheus rule sanity and scrape-target reachability. Use when running, tuning, or troubleshooting a Prometheus, OpenTelemetry Collector, or Loki deployment, or reviewing the collection/ingest/retention layer. Do not use for observability strategy, SLI/SLO design, or paging policy (that is platform-engineering) or Grafana dashboards, panels, and Grafana-side alerting (that is grafana).
 - [tempest-cli](tempest-cli/SKILL.md): Query hyper-local weather from a WeatherFlow Tempest station: current conditions, 7-day forecast, historical observations, and real-time UDP broadcasts. Use when the user asks about the weather, temperature, rain, wind, humidity, forecast, or wants conditions from their own station rather than a generic weather service.
 - [terraform](terraform/SKILL.md): Operate Terraform and OpenTofu across the whole infrastructure lifecycle: module structure, state backends and locking, plan/apply workflow, drift detection, remote state, upgrade and refactor flows, and evidence-based diagnostics. Use when running or inspecting terraform plans, applies, state files, imports, or state surgery, or when the bundled tfops script should handle the task. Do not use for IaC methodology or cloud design decisions - those route up to platform-engineering.

references/skill-triggers.md

@@ -91,7 +91,7 @@ Each skill's `description` field is the canonical routing contract. This conveni
 | "adr-authoring", "adr authoring", "architecture decision record", "fitness function", "decision confirmation" | [adr-authoring](../adr-authoring/SKILL.md) |
 | "c4-diagramming", "c4 diagramming" | [c4-diagramming](../c4-diagramming/SKILL.md) |
 | "capacity engineering", "cost engineering", "capacity model", "capacity planning", "unit cost", "cost per request", "cost per user", "budget threshold", "spending alert", "spending cap", "rate limit enforcement", "quota management", "load test plan", "soak test plan", "capacity projection", "growth forecast capacity", "peak sizing", "degraded capacity", "SLO cost tradeoff", "cost attribution", "cost anomaly review", "cost-aware architecture", "cost-performance tradeoff" | [capacity-and-cost-engineering](../capacity-and-cost-engineering/SKILL.md) |
-| "technology-radar", "technology radar" | [technology-radar](../technology-radar/SKILL.md) |
+| "technology-radar", "technology radar", "architecture governance", "proportional governance", "advice process", "federated architecture decision", "architecture exception", "technology standards" | [technology-radar](../technology-radar/SKILL.md) |
 | "strategy", "strategic planning", "OKRs", "strategic narrative", "Five Forces", "Blue Ocean", "competitive positioning", "moat", "Ansoff", "Three Horizons", "market entry", "capital allocation", "M&A evaluation", "BCG Matrix", "portfolio management" | [strategy-frameworks](../strategy-frameworks/SKILL.md) |
 | "Supabase", "Supabase CLI", "supabase start", "supabase migration", "Supabase Auth", "Supabase RLS", "Supabase Storage", "Supabase Realtime", "Edge Functions", "self-host Supabase", "self-hosted Supabase", "Supabase Docker", "Supabase backup", "Supabase restore", "Supabase upgrade" | [supabase](../supabase/SKILL.md) |
 | "Vercel Eve", "eve agent", "eve dev", "eve build", "eve start", "Eve self-hosting", "durable Eve session", "Eve sandbox", "Eve Workflow", "Eve subagent", "Eve agent skills", "Eve deployment", "Eve reverse proxy" | [vercel-eve](../vercel-eve/SKILL.md) |

technology-radar/README.md

@@ -1,29 +1,31 @@
 # Technology Radar
 
-Turn scattered technology preferences into explicit, reviewable decisions with owners, evidence, and a clear adoption posture.
+Turn scattered technology preferences into explicit, reviewable decisions with owners, evidence, and a clear adoption posture. Choose architecture-governance effort by consequence instead of routing every decision through a board.
 
 ## Why Install This Skill
 
 Turn scattered technology preferences into explicit, reviewable decisions with owners, evidence, and a clear adoption posture. It preserves a practical method, local reference material, and reusable templates so an agent can do more than produce a generic answer.
 
-Use it when the work needs a repeatable process and an inspectable result. It is portable across Agent Skills-compatible clients and does not require a profile system or a particular task orchestrator.
+Use it when the work needs a repeatable process and an inspectable result. The governance method distinguishes automated policy, federated decisions, advice processes, and centralized review, then uses implementation and operational feedback to refine standards and radar entries. It is portable across Agent Skills-compatible clients and does not require a profile system or a particular task orchestrator.
 
 ## What You Get
 
 | Path | What it provides |
 |---|---|
 | `SKILL.md` | Trigger conditions, workflow, and guidance for loading deeper resources. |
-| `references/` | Reference material: `architecture-governance.md`, `build-vs-buy.md`, `engineering-metrics.md`, `technology-radar.md` |
+| `references/` | Reference material for radar decisions, proportional architecture governance, build-vs-buy analysis, and engineering metrics. |
 
 ## Quick Start
 
-Read `references/technology-radar.md`, then use the decision criteria in `SKILL.md` to create or update a radar entry.
+Read `references/technology-radar.md` for a radar entry, or `references/architecture-governance.md` for a governance decision. Use the evidence and boundary guidance in `SKILL.md` to produce an inspectable result.
 
 Install or expose this directory using your agent's standard Agent Skills loading mechanism, then ask for work that matches the triggers below.
 
 ## Triggers
 
-- Build and maintain technology radars for adoption, trial, assessment, and hold decisions. Use when governing technology choices, build-versus-buy decisions, or engineering portfolio risk.
+- Build and maintain technology radars for adoption, trial, assessment, and hold decisions.
+- Choose or audit proportional architecture governance: automated policy, federated decision, advice process, or centralized review.
+- Govern architecture standards, exceptions, review paths, and feedback from implementation or operations without turning technology-radar work into enterprise architecture.
 - Requests involving the method, deliverables, or review process described in `SKILL.md`.
 - Work where a reusable template or reference from this skill would reduce avoidable mistakes.
 

technology-radar/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: technology-radar
-description: Build and maintain technology radars for adoption, trial, assessment, and hold decisions. Use when governing technology choices, build-versus-buy decisions, or engineering portfolio risk.
+description: Build and maintain technology radars for adoption, trial, assessment, and hold decisions, and choose proportionate architecture-governance paths for technology portfolios. Use when governing technology choices, build-versus-buy decisions, architecture standards, exceptions, or engineering portfolio risk. Do not use for enterprise capability or target-state architecture, writing ADRs, implementing systems, security engineering, or operational incident/runbook work.
 license: MIT
 compatibility: No runtime dependency.
 metadata:
@@ -13,13 +13,19 @@ metadata:
 
 CTO methodology for making technology decisions, governing architecture, measuring engineering effectiveness, managing technical debt, and operating an innovation pipeline. These frameworks help a CTO balance short-term delivery velocity with long-term platform health.
 
+## When Not to Use
+
+- Route enterprise capability maps, operating-model design, and current/target-state roadmaps to a human enterprise-architecture owner; no current catalog skill owns that workflow. This skill stays focused on technology portfolio posture and governance mechanics.
+- Route the durable record of one consequential decision to `adr-authoring`; use this skill to choose the governance path and connect the decision to standards or radar feedback.
+- Route system design and code changes to the relevant engineering skill, security requirements and threat modeling to `secure-software-engineering`, and live operations or SLO work to `site-reliability-engineering`.
+
 ## Domain Model
 
 | Domain | Covers | Artifact |
 |--------|--------|----------|
 | **Technology Radar** | Adopt/Trial/Assess/Hold quadrants, tool selection criteria, deprecation policy | Technology radar document |
 | **Build vs Buy** | TCO analysis, decision matrices, vendor evaluation, integration cost | Build-vs-buy recommendation |
-| **Architecture Governance** | Standards, review boards, RFC process, design reviews | ADRs, RFC documents, governance charter |
+| **Architecture Governance** | Automated policy, federated decisions, advice processes, centralized review, standards, exceptions, and feedback | Governance decision record, standard, exception, radar update |
 | **Engineering Metrics** | DORA (deploy frequency, lead time, MTTR, change failure rate), SPACE, DevEx | Engineering dashboard, health report |
 | **Technical Debt** | Interest calculation, remediation prioritization, principal estimation | Technical debt register |
 | **Innovation Pipeline** | Horizon scanning, POC criteria, production readiness gates | Innovation funnel, POC report |
@@ -35,26 +41,37 @@ Load this skill when the task involves:
 - Quantifying and prioritizing technical debt remediation
 - Running an innovation pipeline with POC-to-production gates
 - Deprecating or retiring legacy technology
-- Conducting an architecture review board session
+- Selecting or auditing automated policy, federated decisions, advice processes, or centralized review
 
 
+## Governance Workflow
+
+For architecture or technology-governance work, read `references/architecture-governance.md` and:
+
+1. Establish the decision, intended outcome, affected systems and teams, evidence available, and the decision owner.
+2. Assess reversibility, scope, risk, blast radius, regulatory exposure, and cross-team impact. Record uncertainty instead of converting it into a false score.
+3. Select the lightest governance mode that still controls the credible downside: automated policy, federated decision, advice process, or centralized review. Escalate when evidence shows that the decision is less reversible, broader, riskier, or more regulated than first assumed.
+4. Define the decision record, implementation checks, exception path, and signals that will cause reconsideration.
+5. Feed implementation and operational evidence back into the decision, standards, exceptions, and radar posture. Treat feedback as a reason to learn, not as retroactive blame.
+
 ## Reference Files
 
 | Reference | Load When | File |
 |-----------|-----------|------|
 | Technology Radar | You need to evaluate and categorize a technology or tool for adoption, trial, assessment, or hold | `references/technology-radar.md` |
 | Build vs Buy | You're comparing build vs buy options with TCO analysis and decision criteria | `references/build-vs-buy.md` |
-| Architecture Governance | You're designing RFC processes, review boards, or architecture standards | `references/architecture-governance.md` |
+| Architecture Governance | You're choosing or auditing proportional governance modes, standards, exceptions, escalation, or feedback | `references/architecture-governance.md` |
 | Engineering Metrics | You need to measure engineering effectiveness with DORA, SPACE, or DevEx frameworks | `references/engineering-metrics.md` |
 
 ## Design Principles
 
 1. **Technology is a means, not an end.** Every technology decision must trace back to a business outcome. "Because it's new" is not a reason to adopt. "Because it solves X faster/safer/cheaper" is.
-2. **Radar is a living document.** A technology radar updated once a year is a museum. Update it quarterly, or every time a significant adoption/hold/promote/promote-to-trial decision is made.
+2. **Radar is a living document.** A technology radar should be refreshed when evidence, strategy, risk, or usage changes materially. Set a cadence that fits the portfolio, and make significant adoption, hold, promotion, or retirement decisions trigger an update rather than waiting for a calendar event.
 3. **Build vs buy is never just cost.** Total Cost of Ownership includes maintenance, hiring, training, integration, migration, and opportunity cost. A cheaper build today may be vastly more expensive over 3 years.
 4. **Engineering metrics measure the system, not the people.** DORA metrics measure the delivery capability of the org. SPACE measures developer satisfaction. Neither is a performance review tool for individuals.
 5. **Technical debt has a principal and an interest payment.** The principal is the cost to fix it properly. The interest is the recurring drag on velocity. Prioritize debt where interest/principal ratio is highest.
 6. **Production readiness gates exist to prevent crisis.** Every gate that is skipped in the name of speed will be paid for in incident response time later.
+7. **Governance should follow consequence.** Local and reversible decisions should stay local; irreversible, regulated, high-blast-radius, or materially cross-team decisions need stronger coordination or authority.
 
 ## Portability
 

technology-radar/evals/evals.json

@@ -41,13 +41,46 @@
     {
       "id": "governance-process",
       "prompt": "Right now any team can introduce any technology and we discover the consequences later. I want architecture governance that reviews technology choices without becoming a bureaucratic approval board that blocks everything. How do I design the process?",
-      "expected_output": "A governance process designed for speed and coverage: the response defines the structure — a lightweight review board or RFC process with a stated scope (new technologies entering the org, significant new uses of existing ones, and major retirements), decision criteria aligned with the radar and the org's strategy, and a fast-track lane for low-risk choices so the board does not become the bottleneck. It explains the operating rules: the board's job is to ask the right questions and record decisions with rationale, not to redesign every proposal; proposals carry the evidence (alternatives, risks, and the evaluation plan) and the board responds within a stated time; and decisions are recorded so the radar and the decision log stay the source of truth. It covers the failure modes to avoid: a board with no criteria that votes on taste, and an approval process with no fast track that pushes teams to bypass it.",
+      "expected_output": "A proportional governance process that first assesses reversibility, scope, risk, blast radius, regulation, and cross-team impact, then selects the lightest adequate mode: automated policy, federated decision, advice process, or centralized review. It gives each mode a clear authority model and minimum evidence, uses centralized review only for genuinely consequential choices, and records exceptions, conditions, and reconsideration triggers. It also closes the loop by feeding implementation and operational evidence into standards and radar decisions, while preserving explicit boundaries with enterprise architecture, ADR authoring, implementation, security engineering, and operations.",
       "assertions": [
-        "The process has a stated scope and decision criteria aligned with the radar",
-        "A fast-track lane keeps low-risk choices from becoming board bottlenecks",
-        "Proposals carry evidence and the board responds within a stated time",
-        "Decisions are recorded with rationale in a durable decision log",
-        "Failure modes are addressed: taste-based voting and bypass-prone approval processes"
+        "The process assesses reversibility, scope, risk, blast radius, regulation, and cross-team impact",
+        "Automated policy, federated decision, advice process, and centralized review are distinguished as governance modes",
+        "The output avoids treating a standing board or fixed process timing as mandatory for every decision",
+        "Exceptions include scope, reason, owner, compensating controls, and an expiry or revisit trigger",
+        "Implementation and operational evidence feeds later standards or radar decisions"
+      ]
+    },
+    {
+      "id": "governance-mode-selection",
+      "prompt": "A team wants to change an internal library used by three services. The change is easy to revert, has no regulatory implications, but could create incompatible interfaces if other teams are surprised. Which architecture-governance path should we use and what should we record?",
+      "expected_output": "A federated decision or advice process is selected instead of mandatory centralized approval, because the change is reversible and bounded but has cross-team interface impact. The response names the local decision owner, affected consultees, compatibility checks, published scope, decision rationale, and an escalation condition if the change expands or creates an unresolved shared contract conflict.",
+      "assertions": [
+        "A local or federated path is preferred over centralized review because the change is reversible and bounded",
+        "Cross-team interface impact leads to consultation, compatibility checks, or published notice",
+        "The output names decision ownership and an escalation condition",
+        "The response does not pretend that low risk means no coordination is needed"
+      ]
+    },
+    {
+      "id": "automated-policy-and-exception",
+      "prompt": "We want a CI rule requiring approved encryption settings across all new services, but teams sometimes need a documented exception for an external integration. Design the governance approach.",
+      "expected_output": "An automated policy is used for the objective encryption requirement, with a visible failing check, rationale, owner, and a bounded exception path. The exception record includes scope, reason, risk, compensating controls, accountable owner, expiry or review trigger, and closure evidence. The response says to escalate if exceptions become frequent or the rule is masking a judgment that automation cannot safely decide.",
+      "assertions": [
+        "The objective requirement is assigned to automated policy rather than a recurring manual approval",
+        "The policy has an owner, visible failure output, and a stated rationale",
+        "The exception path records scope, reason, compensating controls, owner, and expiry or revisit trigger",
+        "Recurring or unsafe exceptions trigger policy review or stronger governance"
+      ]
+    },
+    {
+      "id": "governance-boundary",
+      "prompt": "An executive asks for an enterprise capability map and target-state roadmap, while another team asks for an ADR template and a production incident runbook. Should the technology-radar architecture-governance method own all three?",
+      "expected_output": "No. Enterprise capability mapping and target-state roadmaps belong to enterprise architecture; ADR structure belongs to ADR authoring; and incident response/runbooks belong to operations or SRE. Technology-radar may supply technology portfolio posture, governance-mode selection, standards, exceptions, and feedback links at the boundaries, but it should not absorb those neighboring workflows.",
+      "assertions": [
+        "Enterprise capability and target-state roadmap work is routed away from technology-radar",
+        "ADR authoring is identified as a separate neighboring owner",
+        "Incident response and operational runbooks are identified as separate operational ownership",
+        "The response preserves technology-radar's technology portfolio and governance boundary"
       ]
     },
     {

technology-radar/references/architecture-governance.md

@@ -1,126 +1,120 @@
 # Architecture Governance
 
-Frameworks for maintaining architectural coherence, making design decisions transparent, and ensuring the technology organization operates with aligned standards.
+Architecture governance is a decision system, not a standing meeting. Its purpose is to keep consequential technology choices coherent while leaving routine, reversible choices with the people closest to the work. Select the governance path from the decision's consequences and evidence, not from an organization's preferred ceremony.
 
-## Architecture Standards
+## Establish the Decision Context
 
-Standards exist to reduce cognitive load and ensure consistency. They should be few, well-justified, and enforced through automation, not manual review.
+Before choosing a process, capture:
 
-### What Should Be Standardized
+- **Outcome:** the product, customer, operational, or organizational result sought.
+- **Scope:** one component, one team, a shared capability, a portfolio, or the wider organization.
+- **Reversibility:** how easily the choice can be changed, including data migration, contracts, training, and sunk operational work.
+- **Risk and blast radius:** plausible harm, affected users and systems, failure propagation, and recovery options.
+- **Regulation and obligations:** legal, contractual, safety, privacy, security, or audit constraints that require named controls or authority.
+- **Cross-team impact:** coupling, shared interfaces, platform dependencies, duplicated investment, and coordination cost.
+- **Evidence and uncertainty:** what is observed, what is assumed, and the smallest experiment or consultation that would reduce the important uncertainty.
 
-| Tier | Category | Example Standards | Enforcement |
-|------|----------|-------------------|-------------|
-| **Tier 1: Mandatory** | Security, compliance, legal | Data encryption, auth patterns, audit logging | Automated (CI pipeline blocks) |
-| **Tier 2: Expected** | Architecture, deployment | Service boundaries, API design, container patterns | Reviewed (RFC approval required for exceptions) |
-| **Tier 3: Recommended** | Tooling, patterns | CI/CD tool, monitoring approach, logging format | Documented (teams may deviate with justification) |
+Do not collapse these dimensions into a universal numeric threshold. A reversible decision with broad coordination cost may need advice or federation; a local decision can still require centralized authority when regulation or blast radius demands it.
 
-### Writing Architecture Standards
+## Choose a Governance Mode
 
-Each standard should contain:
+Choose the least costly mode that controls the credible downside. A decision can move to a stronger mode when new evidence changes its consequence profile.
 
-1. **Title.** What the standard governs.
-2. **Rationale.** Why this standard exists. If you can't articulate the benefit, question the standard.
-3. **Scope.** What systems/teams this applies to (and what it explicitly does not).
-4. **The standard.** The specific requirement. Measurable, testable, unambiguous.
-5. **Exception process.** How to request an exception and who can grant it.
-6. **Review date.** When this standard will be re-evaluated.
+| Mode | Best fit | Minimum controls | Escalate when |
+|---|---|---|---|
+| **Automated policy** | The requirement is objective, repeatable, and machine-checkable, such as a required configuration or compatibility rule. | A stated rationale, an executable check, an owner, visible failure output, and a bounded exception path. | The check is a proxy for a judgment, exceptions become common, or the policy creates material cross-team or regulatory consequences. |
+| **Federated decision** | A team or domain owns the outcome and the choice is local or reasonably reversible, while a shared convention prevents avoidable divergence. | Local decision authority, published decision and scope, compatibility expectations, and a route for affected peers to raise a conflict. | Shared interfaces, platform dependencies, duplicated investment, or accumulated divergence makes the choice enterprise-relevant. |
+| **Advice process** | The proposer owns the decision but needs input from people who bear consequences or hold relevant expertise. This is useful for cross-team conceptual integrity without default veto power. | Named proposer and owner, identified consultees, written advice and dissent, response to material concerns, and a recorded decision. | Advice identifies an irreversible or high-blast-radius change, a mandatory control, unresolved authority conflict, or a need for portfolio-level coordination. |
+| **Centralized review** | The choice is difficult to reverse, high impact, materially regulated, or spans teams that cannot resolve the trade-off locally. | A named decision authority, concise evidence package, alternatives and consequences, affected-team input, decision record, conditions, and an appeal or escalation route. | The authority lacks the required expertise, evidence is too weak for a responsible decision, or the review is redesigning implementation rather than governing the boundary. |
 
-### Standards Anti-Patterns
+The modes are not maturity levels. Automated policy is not automatically more decentralized than advice, and a centralized review is not automatically better. Match authority, consultation, and automation to the failure modes the decision can create.
 
-- **Too many standards.** If everything is a standard, nothing is. Limit Tier 1 and Tier 2 to 15-20 items total.
-- **Standards without automation.** If compliance requires a human reviewer, the standard will be applied inconsistently. Automate everything possible.
-- **Stale standards.** A standard that hasn't been reviewed in 2+ years is likely causing harm. Sunset or update.
-- **The "we've always done it this way" standard.** Justify every standard independently. Past practice is not a rationale.
+## Standards and Guardrails
 
----
+Create a standard only when a shared rule produces more value than local variation. Each standard should state:
 
-## Architecture Review Board (ARB)
+1. **Intent and benefit:** the problem or risk it addresses.
+2. **Scope:** the systems, teams, lifecycle stages, and explicit exclusions.
+3. **Requirement:** a testable rule, recommendation, or decision constraint.
+4. **Owner and authority:** who maintains it and who can change it.
+5. **Enforcement mode:** automated check, federated expectation, advice, or review.
+6. **Exception path:** who may grant an exception, what evidence is needed, compensating controls, expiry or revisit conditions, and how exceptions are visible.
+7. **Feedback signals:** implementation and operational evidence that may confirm, weaken, or invalidate it.
 
-An ARB provides governance for significant architecture decisions. It is not a bottleneck — it is a quality gate and knowledge-sharing mechanism.
+Avoid counting standards as a proxy for governance quality. A small organization may need several precise controls; a large regulated estate may need more. Prefer deleting, combining, automating, or narrowing a standard when it no longer earns its coordination cost.
 
-### When to Involve the ARB
+## Decision Records and Advice
 
-| Level | Decision Type | Review Process |
-|-------|--------------|----------------|
-| **L1: Team-level** | Service internal design, API endpoints, database schema | No ARB needed. Team decides. |
-| **L2: Cross-team** | New service, shared library, API contract change | ARB notified, lightweight review (1-2 reviewers) |
-| **L3: Organization-wide** | New technology, platform change, infrastructure redesign | Full ARB review (RFC + meeting) |
-| **L4: Strategic** | Architecture paradigm shift (monolith → microservices, cloud migration) | Executive + ARB joint review |
+Use a concise decision record for any choice whose rationale or consequences will outlive the current conversation. Include the context, options, chosen path, owner, affected parties, assumptions, conditions, evidence, and reconsideration triggers. Use an ADR when the decision itself needs durable architectural history; this reference governs how to select the process, not the ADR format.
 
-### ARB Composition
+For advice processes, distinguish advice from approval. The proposer must seek input from people materially affected, consider the advice, and explain unresolved disagreement. Advice does not silently create a veto. If a mandatory control or authority boundary exists, name it and escalate rather than disguising it as consultation.
 
-| Role | Responsibility | Count |
-|------|---------------|-------|
-| **Chair** | Manages agenda, drives decisions, maintains standards | 1 |
-| **Principal Architects** | Technical authority, deep domain expertise | 2-4 |
-| **Rotating Members** | Cross-functional representation, bring team context | 2-3 (rotating quarterly) |
-| **Decision Author** | Presents the proposal, answers questions | 1 per proposal |
+## Feedback From Delivery and Operations
 
-### Effective ARB Practices
+Close the loop after implementation and during operation:
 
-- **Time-boxed meetings.** One hour max. Decisions should be prepared before the meeting, not debated from scratch.
-- **Written proposals required.** No "let's whiteboard it" in the ARB. Proposals must be submitted as RFCs at least 48 hours in advance.
-- **Decisions, not discussions.** The ARB's job is to make a decision: approve, approve with conditions, or reject with feedback. Not to explore options.
-- **Rotating membership.** Fixed members create an insular culture. Rotate members quarterly to distribute knowledge and prevent groupthink.
-- **Appeals process.** Any rejected RFC can be appealed to the CTO or VP Engineering. This prevents the ARB from becoming a bottleneck.
+- Compare the intended outcome and constraints with observed behavior.
+- Record surprises, incidents, support burden, delivery friction, cost, performance, adoption, and exceptions.
+- Decide whether to keep, narrow, automate, revise, supersede, or retire the standard or radar entry.
+- Update the decision record and notify affected owners; do not silently rewrite history.
+- Promote recurring evidence into a better guardrail or experiment, and remove controls that no longer prevent a meaningful failure.
 
----
+Operational evidence does not transfer incident command or service ownership to this skill. It supplies feedback for technology posture and governance decisions; operations teams retain operational response and reliability ownership.
 
-## RFC Process
+## Exceptions and Proportional Escalation
 
-Request for Comments (RFC) is a lightweight process for making significant technical decisions transparent and documented.
+An exception is a governed deviation, not an informal bypass. Record the requested scope, reason, affected assets, risk, compensating controls, accountable owner, expiry or review trigger, and evidence of closure. Emergency exceptions may use a shorter path, but they still require retrospective recording and review when the immediate risk is controlled.
 
-### The RFC Lifecycle
+Escalate when any of these becomes true:
 
-1. **Draft.** Author writes the RFC using the template below. Collaborate with stakeholders.
-2. **Review.** RFC is open for comments for a minimum period (typically 3-5 business days).
-3. **Decision.** The decision-maker (tech lead, ARB chair, CTO) approves, conditionally approves, or rejects.
-4. **Implementation.** Approved RFCs are implemented. The RFC becomes the source of truth for the decision.
-5. **Retrospective.** After implementation, close the RFC with a summary of what changed from the original design.
+- the choice cannot be reversed without material customer, data, contract, or migration cost;
+- the blast radius or cross-team impact exceeds the local owner's authority;
+- a regulatory, legal, safety, privacy, or security obligation requires a designated control owner;
+- local decisions are creating incompatible interfaces, duplicated platforms, or portfolio-level cost;
+- evidence is insufficient to understand a material downside;
+- an exception is recurring, expanding, or compensating controls are failing.
 
-### RFC Template
+De-escalate when an experiment reduces uncertainty, automation makes the rule objective, ownership becomes local, or the change is safely reversible. Stronger governance should not persist merely because it was used once.
+
+## Neighboring Ownership
+
+- **Enterprise architecture:** capability maps, business/technology alignment, operating models, target and transition states, and enterprise roadmaps belong there. This skill governs technology portfolio posture and decision paths.
+- **ADR authoring:** durable records for consequential decisions and their fitness evidence belong there. This skill decides when and how governance is applied.
+- **Implementation skills:** code, service design, API contracts, data models, migrations, and platform changes belong to their specialist owners. Governance sets boundaries and evidence; it does not design every implementation.
+- **Secure software engineering:** threat modeling, security requirements, authentication/authorization, and secure implementation belong there. A security obligation may be an escalation input or automated guardrail here.
+- **Operations and SRE:** deployment operations, incident command, SLOs, monitoring, and recovery runbooks belong there. Their evidence feeds governance; this skill does not replace operational ownership.
+
+## Practical Output
+
+Produce an artifact that makes authority and learning inspectable:
 
 ```markdown
-# RFC: [Title]
+# Governance decision: [subject]
 
-## Status
-[Draft | Review | Approved | Rejected | Implemented]
+## Context
+- Outcome:
+- Scope and affected teams:
+- Reversibility and blast radius:
+- Risk, regulation, and cross-team impact:
+- Evidence and uncertainty:
 
-## Summary
-[2-3 sentence overview of the proposal]
+## Chosen governance mode
+[Automated policy | Federated decision | Advice process | Centralized review]
 
-## Motivation
-[Why this change is needed. What problem does it solve? What happens if we don't do it?]
+## Authority and controls
+- Decision owner:
+- Consultees or approving authority:
+- Required checks or conditions:
+- Exception path and compensating controls:
 
-## Design
-[The proposed solution. Architecture diagrams, API contracts, data models.]
+## Feedback plan
+- Implementation evidence:
+- Operational signals:
+- Reconsideration triggers:
+- Owner and next review point:
 
-## Alternatives Considered
-[Other approaches and why they were not chosen. Include the runner-up.]
-
-## Trade-offs
-[What are we giving up? Performance vs maintainability? Speed vs correctness?]
-
-## Migration Plan
-[How do we get from current state to proposed state? Phased approach, timeline, rollback plan.]
-
-## Open Questions
-[What we don't know yet. Decisions that are deferred.]
-
-## Appendix
-[Any additional context, benchmarks, or references.]
+## Boundary and links
+- Radar entry or standard:
+- ADR, if needed:
+- Specialist implementation, security, or operations owners:
 ```
-
-### RFC Principles
-
-- **Write-first, talk-second.** Discussions happen on the document. Meetings are for resolving deadlocked issues, not for initial review.
-- **Disagree and commit.** Once a decision is made, the team commits to implementing it. Continued debate after a decision undermines the process.
-- **Explicit deferral.** "Let's discuss this in the meeting" is fine. "Let's discuss this later" without a specific time is delay. Set a deadline for every deferred question.
-- **Retrospectives on rejected RFCs.** If an RFC is rejected, document why. The analysis may be valuable if conditions change later.
-
-### Common RFC Failures
-
-- **The design-by-committee RFC.** Too many authors, too many opinions, no clear vision. RFCs should have one primary author and 1-2 reviewers.
-- **RFC as a rubber stamp.** If the decision is already made and the RFC is just documentation, that's fine — but be explicit. "Decision made: we're moving to X. This RFC documents the design and migration plan."
-- **Too much detail, too late.** An RFC that describes a fully detailed implementation is harder to change than one that starts with the high-level approach. Get alignment on the approach before diving into implementation details.
-- **Death by process.** If every minor change requires an RFC, engineers will stop writing RFCs. Define the threshold clearly.

technology-radar/references/source-index.md

@@ -4,3 +4,10 @@
 - **Inspected commit:** `867a555`
 - **Imported source directory:** `technology-radar`
 - **Porting boundary:** Retained portable methodology, templates, scripts, and references. Removed or generalized Hermes profile, task-orchestration, memory, and rigid response-handoff assumptions.
+
+## Issue 340 revision provenance
+
+- **Revision basis:** Original synthesis of the repository's existing technology-radar material, issue #340 requirements, the repository's Agent Skills authoring guidance, and the safe architecture comparison supplied for this task.
+- **Added emphasis:** Decision locality, reversibility, consequence-based governance selection, advice and federated processes, automated guardrails, implementation and operational feedback, exceptions, and proportional escalation.
+- **Originality boundary:** No purchased ebook was read or quoted for this revision. All guidance, examples, tables, and evaluation fixtures in this directory are newly authored for this repository.
+- **Scope boundary:** Enterprise capability and target-state architecture, ADR composition, implementation, security engineering, and operations remain neighboring ownership areas rather than new technology-radar responsibilities.

technology-radar/references/technology-radar.md

@@ -34,10 +34,7 @@ The technology radar is a structured approach to tracking, evaluating, and decid
 
 ### Radar Review Cadence
 
-- **Full radar refresh:** Quarterly (review all quadrants and rings)
-- **New technology intake:** Continuous (proposed via RFC or lightweight form)
-- **Emergency promotion:** As needed (critical security update, strategic shift)
-- **Hold review:** Annual (verify hold decisions are still valid)
+Set review timing according to change rate, risk, evidence quality, and the cost of stale guidance. A low-change internal tool portfolio may need less frequent review than a regulated or fast-moving platform portfolio. Significant adoption, hold, promotion, retirement, security, or strategy evidence should trigger an update outside the normal cadence. New technology intake may be continuous or batched, provided urgent risks and opportunities have an explicit path.
 
 ---
 
@@ -85,7 +82,7 @@ Removing technology is harder than adding it. A clear deprecation policy prevent
 
 1. **Announce intent.** "We plan to deprecate Technology X. Here's why, and here's the migration path."
 2. **Freeze new usage.** No new projects may adopt the deprecated technology.
-3. **Provide migration window.** 3-12 months depending on complexity.
+3. **Provide a migration window.** Set it from workload criticality, consumer count, migration complexity, contractual obligations, and available support; document the rationale rather than applying a universal duration.
 4. **Support during migration.** Documentation, office hours, migration tools.
 5. **Sunset date.** After this date, no support, no security patches, no guarantees.
 6. **Archive.** Final documentation archived. Technology removed from radar.