# Coverage, jobs, and retention ## Inspect before filling `inspect subject:bound_function` is the coverage ledger. Its `materialized` ranges describe durable data; `materializing` describes paid in-flight work; `active_jobs` identifies open jobs. `created`, a metric name, or a previous successful bind does not establish coverage. Materialize only missing blocks. With `[100, 115)` already cached, a request for `[97, 118)` has six uncovered blocks: `[97, 100)` and `[115, 118)`. Existing paid in-flight ranges also count toward the exclusion. Read the returned quote rather than pricing the full requested window yourself. ## Follow asynchronous work A paid materialize response returns `result: "materializing"` and a `job` handle. Poll `inspect subject:job` with its `job_id`. The job card describes its own paid half-open window, `blocks_done`, `blocks_total`, and diagnostic fields where present. States include `queued`, `running`, `partial`, `waiting_blocks`, `done`, and `failed`. A partial job can make a durable prefix visible; reading the full original window still requires full coverage. A future tail waits for the chain head to reach it instead of being fabricated. A Function with memory across blocks is billed and walked from its contract's creation block, even when the requested start is later. Its job can stay queued until every preceding block from creation is covered. Check the quote's actual window and lines before authorizing payment. The reviewed live 0.6.0 instructions advertise dependency-aware indexing: a Function that reads another Function cannot claim blocks its dependency has not materialized. Materialization quotes needed blocks across both and walks the dependency first; dynamically discovered dependency keys are walked from contract creation. Inspect the actual quote and jobs before paying or reading. This behavior was advertised, not executed, in the release review. Use bounded polling and a backoff appropriate to the chain. Do not repeatedly materialize a window while an active paid job already covers its holes. If a process or client restarts, inspect the durable state before resuming. ## Latest materialized is a precise request A `read` with neither block end asks for the latest materialized block. It does not promise latest chain head. For a time-sensitive decision, compare its resolved range with the chain's `head` and materialize a deliberate updated window when authorized. ## Retention and cache titles The implementation includes a 24-hour land stamp for new paid coverage; additional days are specified with `extra_cache_days` when freezing materialize work. Actual range titles and expiry are inspectable on the bound-function card. A titled range can carry `cache_expiry_time` as a Unix-seconds string; untitled ranges may omit it. Expiry belongs to each range, not one global wallet timer. Adjacent ranges may have separate titles and expiry records. Do not assume all historic values remain available forever. ## Stop a specific paid window ```json {"tool":"stop","arguments":{"bound_function_id":"","wallet":"","quote_id":""}} ``` This targets a named in-flight materialize quote. The wallet must currently hold that quote's claim-right; the original payer may no longer be its owner. When a collection is configured, ownership is checked at the chain tip. Examine each returned job, `unspent_blocks`, refund, error, and any `unstopped` row. A refund failure can leave an indicated window active and paid; reconcile against inspect and accounting before retrying. Delivered rows remain available.