# 05 — Roadmap & Architecture Signals

This section reviews the public signals that indicate where Home Assistant's core team and the
Open Home Foundation are heading, so that a contribution strategy can *complement* the existing
roadmap rather than collide with it. Sources are listed in §05.1; interpretation and the
implications for each candidate contribution path are in §05.6.

> **Provenance reminder.** As established in report 01, everything here is drawn from public
> artifacts: the `home-assistant/architecture` discussion repository, published ADRs, the
> developer blog (`developers.home-assistant.io/blog`), the user-facing blog and release notes
> (`home-assistant.io/blog`), the published Open Home Foundation roadmap posts, and the
> integration quality-scale documentation. Where a signal is an inference rather than a stated
> plan, it is explicitly marked **[inference]**.

---

## 05.1 Sources reviewed

| # | Source | Type | What it tells us |
|---|--------|------|------------------|
| S1 | Open Home Foundation announcement & charter (April 2024) | Governance | Long-term stewardship model; privacy/choice/sustainability as explicit values |
| S2 | Published Home Assistant roadmap posts (2024 onward, updated at State of the Open Home events) | Roadmap | Named pillars and current initiatives (see §05.3) |
| S3 | `home-assistant/architecture` GitHub discussions & ADRs | Architecture | Direction of core internals, accepted/rejected patterns |
| S4 | Developer blog posts on the **integration quality scale revamp** (late 2024) | Process | Bronze/Silver/Gold/Platinum redefinition; rules-based tiering; expectation that integrations climb the scale |
| S5 | Monthly release notes (e.g., backup overhaul, voice, dashboard sections, LLM/Assist API work) | Roadmap-in-practice | What core engineering capacity is actually consumed by |
| S6 | `hassfest` and CI tooling evolution in `home-assistant/core` | Process | Enforcement trends: stricter manifests, runtime-data, typed config entries |
| S7 | Works With Home Assistant program | Ecosystem | Certification economics; which device categories are prioritized |
| S8 | Month of "What the Heck?!" community feedback rounds | Demand signal | Recurring user pain points that have *not* been absorbed into roadmap |

---

## 05.2 Governance signal: the Open Home Foundation

The 2024 transfer of Home Assistant (plus ESPHome, Zigpy, and related projects) into the
Open Home Foundation is the single most important structural signal of the period:

- **Stability of stewardship.** The project is now insulated from acquisition, with a
  charter centered on *privacy, choice, and sustainability*. Long-horizon contributions
  (multi-month uplift programs) carry less "project direction risk" than they would in a
  VC-backed or single-vendor project.
- **Professionalized core, community-scaled edges.** Nabu Casa funds a core engineering team;
  the foundation explicitly relies on community contributors for the long tail of
  integrations. This division of labor is stated, not implied: integration maintenance is
  *the* designated community surface.
- **Implication for us.** Contribution effort aimed at the integration layer is structurally
  aligned with how the foundation says it wants help. Effort aimed at deep core rewrites is
  structurally misaligned — the funded core team owns that surface and gates it heavily.

---

## 05.3 Published roadmap pillars

The public roadmap (as periodically restated at State of the Open Home events and on the
blog) organizes work under recurring pillars. Condensed:

| Pillar | Representative initiatives | Core-team owned? |
|--------|---------------------------|------------------|
| **Approachability / "Home Approval Factor"** | Dashboard sections & default dashboards, areas/floors model, easier onboarding, automation UI improvements | Yes — UX core team |
| **Voice** | Assist pipelines, Wyoming protocol, local STT/TTS, Voice Preview Edition hardware, LLM conversation agents & the Assist API | Yes — dedicated voice effort |
| **Privacy & local control** | Matter/Thread investment, local-first integrations, encrypted automatic backups (2025.1 backup overhaul) | Yes |
| **Energy** | Energy dashboard expansion, device energy metadata | Yes, slower cadence |
| **Quality & sustainability** | **Integration quality scale revamp**, stricter `hassfest` rules, typed config entries (`runtime_data`), deprecation sweeps | **Shared** — core defines rules; community is expected to do the climbing |
| **Open device ecosystem** | Works With Home Assistant relaunch, device database ambitions | Yes/partner-driven |

The critical observation: **five of six pillars are core-team-owned engineering programs.**
The sixth — quality & sustainability of the integration catalog — is the one pillar where the
core team has built *machinery* (the rules-based quality scale, hassfest enforcement, the
`quality_scale.yaml` per-integration checklist) and explicitly invited the community to supply
the labor. This is the published "help wanted" sign, and it matches the distribution findings
in report 03 (the overwhelming majority of integrations sit at legacy/no-score or Bronze).

---

## 05.4 Architecture-repo and ADR signals

Recurring, accepted directions in `home-assistant/architecture` discussions and ADRs that
constrain or shape integration work:

1. **Config flow everywhere.** YAML-configured platforms continue to be deprecated; new and
   uplifted integrations must use config entries with UI flows (ADR-0010 lineage). Any uplift
   work must include config-flow migration where it is still missing.
2. **Typed runtime data.** `ConfigEntry.runtime_data` with generic typing is the blessed
   pattern, replacing `hass.data[DOMAIN]` dictionaries. This is now a quality-scale rule and a
   reviewer expectation — uplift PRs that don't adopt it get bounced.
3. **Entity naming & device model.** `has_entity_name`, entity translations
   (`strings.json`/`icons.json`), device registry correctness, and entity categories are
   enforced expectations for scaled integrations.
4. **Strict typing expansion.** The `.strict-typing` allowlist in core keeps growing; Platinum
   requires full strict typing including the upstream library. The direction is one-way.
5. **Library-first architecture (ADR-0011 lineage).** Protocol logic must live in a published
   PyPI library, not in the integration. Uplift on integrations with embedded protocol code
   implies upstream library work — materially raising effort (this matters for path scoring
   in report 06).
6. **Test coverage gates.** New integrations require full config-flow test coverage; the
   review culture increasingly expects meaningful test additions on any behavioral change.
7. **Deprecation discipline.** Core runs continuous deprecation sweeps (six-month windows).
   A non-trivial share of the issue volume triaged in report 04 is breakage from deprecations
   landing on unmaintained integrations — i.e., the core's own quality program *generates*
   community-fixable work at a predictable rate.

**[inference]** Items 1–4 plus 6 are exactly the Bronze→Silver rule set of the revamped quality
scale. The architecture repo and the quality scale have converged: the scale is now the
operational encoding of the architecture decisions. Working the scale *is* working the
architecture roadmap, from the community side.

---

## 05.5 What the roadmap does *not* cover (gap scan)

Scanning roadmap posts, "What the Heck?!" rounds, and high-vote feature requests for gaps a
feature-path contribution could fill:

| Gap | Demand signal | Why core hasn't taken it | Viability for outside contribution |
|-----|---------------|--------------------------|-----------------------------------|
| Integration health/error observability for end users (why is my integration failing, in plain language) | Recurring WTH topics | Partially absorbed into repair issues & diagnostics; no unified push | Medium — touches core UX, needs architecture sign-off |
| First-class test/dev scaffolding for integration authors (generate a compliant skeleton + quality-scale checklist automation) | Developer-blog comments, scaffold script is dated | Core tooling team is small; scaffold exists but lags the new scale | **High — pure tooling, low approval surface** |
| Bulk migration tooling for deprecated patterns (codemods for `hass.data`→`runtime_data`, entity-name migration) | Implicit in deprecation churn | Core writes deprecations, not migration automation | High — but benefits accrue to contributors, not end users directly |
| Advanced automation debugging (time-travel traces, condition explain) | High-vote requests | Traces exist; incremental UX work ongoing in core | Low — collides with core UX ownership |
| Offline/degraded-mode dashboard behavior | Moderate | Niche, architecturally hard | Low |

The viable feature-gap candidates are *developer-facing tooling*, not user-facing features —
user-facing surfaces are well covered by funded core pillars, and unsolicited large features
have a documented history of stalling in architecture review.

---

## 05.6 Implications matrix for candidate paths

| Signal | Bulk bug fixing (P1) | Platinum-100 uplift (P2) | Baseline scale uplift (P3) | New user feature (P4) | Typing/test uplift (P5) | Dev tooling (P6) |
|--------|---------------------|--------------------------|---------------------------|----------------------|------------------------|-----------------|
| OHF community/core division of labor (§05.2) | ✅ aligned | ✅ aligned | ✅✅ exactly the invited work | ⚠️ core-owned surface | ✅ aligned | ✅ aligned |
| Quality pillar machinery exists (§05.3) | ✅ benefits | ✅ uses it | ✅✅ uses it directly | ➖ neutral | ✅ subset of it | ✅✅ extends it |
| ADR/typing direction (§05.4) | ➖ neutral | ⚠️ Platinum requires upstream-library typing → effort blowup | ✅ Bronze/Silver rules are self-contained | ➖ | ✅ | ✅ |
| Library-first ADR (§05.4 #5) | ⚠️ some fixes require upstream releases | ❌ frequent upstream blockage | ⚠️ occasional | ➖ | ⚠️ Platinum-tier blockage | ✅ unaffected |
| Deprecation churn generates fixable work (§05.4 #7) | ✅✅ steady supply | ➖ | ✅ | ➖ | ➖ | ✅ codemod opportunity |
| Feature-gap scan (§05.5) | ➖ | ➖ | ➖ | ⚠️ only dev-tooling gaps viable | ➖ | ✅ identified gap |
| Review bandwidth reality (report 04 §6: PR review latency on integration PRs) | ⚠️ many small PRs queue | ❌ very large diffs stall | ✅ rule-by-rule PRs match reviewer workflow | ❌ architecture sign-off required | ✅ small diffs | ✅ partially out-of-tree |

Legend: ✅✅ strong tailwind · ✅ tailwind · ➖ neutral · ⚠️ headwind · ❌ strong headwind

These qualitative findings feed the quantitative scoring model in report 06.