#713 Document model-method data-mutation surface (dataRepository.delete, findAllForModelSince, queryData)

Problem

The model-author API reference presents context.dataRepository as read-only — the "Key dataRepository methods for model authors" table lists only getContent, findByName, and findAllForModel. In reality, the context a model method's execute() receives exposes a much larger, working surface, including:

• dataRepository.delete(modelType, modelId, dataName[, version]) — delete a data instance, all versions or one (verified working from inside a method)
• dataRepository.findAllForModelSince(modelType, modelId, cutoff) — list data changed since a cutoff
• dataRepository.save / append / rename / removeLatestMarker / collectGarbage
• top-level context.queryData and context.readModelData

Because the docs show no supported way to delete or reconcile a model's own data, authors of inventory-style models (one row per observed resource, plus one error row per target/phase that couldn't be assessed) naturally adopt a write-only pattern: error rows are written under a stable key and never removed. When a target recovers on a later run, its stale error row remains the latest version forever, and any consumer that counts "current errors" over findAllForModel re-reports it indefinitely as a phantom coverage gap. The fix (delete recovered-unit error rows during the sweep) is trivial — but only once you know dataRepository.delete is available to a method, which the docs do not say.

Proposed solution

1. Document the data-mutation methods available to model execute() contexts — at minimum dataRepository.delete and findAllForModelSince, plus queryData / readModelData — in the model author API reference, alongside the existing read methods, noting which are supported for authors versus internal-only.
2. (Optional DX) Add an ergonomic context.deleteResource(specName, instanceName) that mirrors context.writeResource(specName, instanceName, data), so authors do not have to drop to the lower-level dataRepository.delete(modelType, modelId, name) signature. This makes create / reconcile / delete symmetric and discoverable.

Alternatives considered

• Consumer-side freshness filtering (count only the latest sweep's errors). Works, but leaves stale rows in the datastore so ad-hoc data queries still mislead, and it pushes per-run bookkeeping into every consumer.
• A short finite lifetime on error specs so GC reaps them. Coarse (bounded by GC cadence) and also drops still-relevant errors between runs.

Both are inferior to letting the producing model reconcile its own data — which is already possible, just undocumented.

Environment

swamp 20260619.211139.0 — model author API reference.