Deterministic sensor-check ranking

flightops rank-checks orders only checks that the Standard-mode select_checks catalog already marks technically eligible. It does not connect to ROS, receive a message, execute a check, authorize a scope, or validate a historical strategy for the present installation.

The Python API is rank_checks(context, current_snapshot_id, knowledge=KnowledgeCatalog(...), authorize_metadata=..., authorize_source=..., problem_text='', limit=100). The two callbacks must return the literal boolean True for a current local retain decision. KnowledgeCatalog also requires the latest source-use retain policy and every upstream source to allow retain. A missing, revoked, retracted, or quarantined knowledge dependency contributes no ranking evidence.

The CLI accepts a bounded --context JSON file, an exact configuration --snapshot-id, repeated --allow-metadata KIND:ID and --allow-source SOURCE-ID, and optional --problem literal text. Its default catalog is state_home()/history/catalog.sqlite3. These flags express the current local user's selected read permission; saved historical policy cannot grant it. For a strategy linked to run-check execute, include --allow-metadata evaluator:<evaluator_digest> using the digest returned by the run, alongside the snapshot, strategy, assessment, receipt and source grants. The evaluator is part of the evidence lineage and is never implicitly allowed.

For each selected check, the result exposes three additive integer components:

The ranking sorts descending score and then check ID. A failed historical attempt remains visible in strategy_linked_historical_results and cannot ban an eligible check. not_run, unknown, snapshot-matched, and unscoped assessments remain separately visible, with denominators. Even a strategy linked to one check does not prove its assessment executed that check; unattributed_assessment_ids makes this limitation explicit. Only a verified fixed run receipt appears in bound_run_receipts and contributes outcome signal only when its exact observed topic equals the current selected topic. Another topic appears in topic_mismatch_run_ids with an observed_source_topic recheck and contributes zero. Several assessments of one run are shown separately but count once by run ID and result digest. One failure increases diagnostic relevance for that scoped check; it does not exclude any eligible check. Different or unknown physical unit, installation, driver, firmware, mounting, calibration, and other saved configuration facts appear in required_rechecks. Historical outcomes are never rewritten or promoted to check-specific outcomes without a validated result binding. Draft, self-reviewed, invalidated, or otherwise unreviewed strategies remain visible with strategy_review recheck but contribute no score. A reviewed_declared label is only a declared identity, not authenticated independent verification.

The selection object preserves every eligibility decision and its evaluator identity. ranking_digest binds the canonical result body. ranked_partial_history means the bounded strategy list had more records than inspected; it is not a claim about uninspected records. Every result reports current_validation='required' per check and execution_authorized=false. Graph and current-snapshot facts are caller supplied; ranking does not prove their measurement or isolation boundary. It compares the two overlapping current ROS configuration facts (distribution and RMW) with the selected snapshot. A difference or unknown adds explicit context/snapshot rechecks and suppresses saved-strategy relevance while preserving technical eligibility.

Each included strategy carries a digest of the exact configuration applicability comparison, both snapshot IDs, match/difference/unknown counts, and the required rechecks. The full comparison remains in KnowledgeCatalog; ranking does not copy potentially large private configuration values into its result. The API rechecks current metadata/source permissions, knowledge status, and applicability just before returning; a changed grant withholds the derived ranking.

flightops run-check plan freezes an exact check ID, topic, snapshot, run ID, catalog/spec digest, observer code digest, and planned retained-artifact: source. flightops run-check execute requires that plan digest, current graph-observe scope, current capture and retain permission for the planned source, and current snapshot and field evidence permission. The production observer runs in its own bounded child process with the selected sourced ROS environment; it cannot shut down caller ROS nodes. It captures one settled onscope graph snapshot, retains only the selected topic row and endpoint profiles in a private bounded artifact, and publishes a source-use policy, resolved SHA receipt, evaluator identity and attempt assessment. Existing retained-results projection indexes the artifact for explicit backup inventory. endpoint_presence and qos_compatibility are supported; bounded_message_delivery remains unbound until a fixed native observer is available. The child returns its own code identity, and parent output is limited while reading. Ambiguous or incomplete endpoint rows yield an inconclusive QoS result. Failed observation returns a typed failure and, while retain rights remain current, a native failed/inconclusive attempt without a receipt; it never masquerades as a completed check. Permission withdrawal before publication removes the owned payload and withholds success. An existing source-use record prevents silent regrant using the same run ID. Test-injected sessions are marked and never score.

The result proves a digest-bound run of local observer software and its selected graph view. It does not authenticate an operator, establish robot hardware identity, attribute a publisher process, prove DDS delivery, or attest that the host was uncompromised. Absence is limited to one asynchronous discovery window, and QoS compatibility covers observed endpoint profiles.