Spark: health factors and liquidations
Spark runs the Aave V3 contracts, so the same replayer, index math and oracle handling apply. The pipeline is pointed at its own Pool, configurator and oracle, each verified against the chain rather than copied from a list, and the health panel is the same build as Aave's against Spark's own reserves.
No health-factor cross-section for Spark yet
The panel job builds one cross-section per run against Spark's own pool, reserves and oracle. Until the first completes there is nothing to show, and nothing here is estimated.
No coverage record has been persisted yet. The statement is written by the job that builds the data, at the end of its first complete run, so it describes a run that happened rather than a recount.
Spark prices 18 of its 18 priced assets through custom adapters we have not replicated; only 0 use a Chainlink proxy or a capped stable feed. Any account holding an adapter-priced asset is stored as adapter oracle rather than given an approximate health factor, so the computed set is smaller than Aave's by construction. Coverage follows the oracles, not the lending logic.
Spark data isn't available right now
The warehouse didn't answer. Nothing here is estimated, so the page waits rather than guessing.
The same replayer as Aave's panel, pointed at Spark's Pool, configurator and oracle. Liquidations are published because each one carries its own amounts; rows whose assets we cannot price show no USD value rather than an estimated one. Health factors need a price for every asset in a position, which is why the coverage statement above is the number to read first.