Decide runtime model refresh and aggregation after host-authoritative migration #425

Goal

Decide whether runtime model refresh, caching, and multi-provider aggregation are needed after the host-authoritative provider snapshot/projection architecture is complete.

Current Architecture

provider catalog/snapshot
  → host validation
  → immutable per-sandbox projection
  → harness-kit-owned native rendering

This model is delivered and proven by the OpenCode path.

Decision Required Before Implementation

The prior Layer 2 design assumed a guest-local writable aggregate at /var/lib/acq/models/catalog.json. That is not automatically compatible with the host-authoritative trust model. Before implementing a runtime orchestrator, record an ADR that answers:

• What freshness requirement cannot be met by release-time normalized snapshots?
• Where do cache and provenance live, and which host authority owns them?
• How do refresh failures preserve last-known-good data without trusting guest writes?
• How do provider selection, credential ownership, network allowlists, and bounded fetches compose?
• Which harness consumers need an aggregate rather than per-provider immutable inputs?

Out of Scope

• Implementing a guest-local writable models orchestrator.
• Harness-native configuration rendering.
• Provider-owned emitters.

Dependencies

• acq: host-authoritative sandbox config — migrate guest-writable state off /var/lib/acq (ADR-0030) agentic-coding-quickstart#503 host-authoritative lifecycle migration.
• Provider catalog: deterministic refresh lifecycle and drift detection #419 provider-neutral refresh lifecycle.

AI-assisted tracker re-scope (OpenCode). Human review required.