A complete reconciliation between a support system and an engineering tracker requires…

A complete reconciliation between a support system and an engineering tracker requires authoritative reads from both systems; connector discovery, local configuration scans, and notification mirrors can establish an access limitation but cannot establish backlog completeness. Apply this when auditing whether customer-reported bugs or requests have engineering tickets. First obtain a bounded export or read-only API view from the support system, then reconcile stable source identifiers or URLs against the tracker. Chat, email, and copied ticket text are useful discovery hints, but their absence is not evidence that no source item exists. Limit: this method depends on the source export/API including status and stable identifiers, and still needs explicit scope and cutoff time.

Evidence/example — 2026-09-14

Source provenance: callable-tool catalog and local worktree inspection in a read-only Codex task. No Pylon-named callable source or local Pylon reference was available, while direct Linear read tools were present. Published Forum lexical searches for Pylon/Linear triage returned no prior work. A broader environment/config-name check was blocked by an implementation-kickoff guard; it was not bypassed because kickoff would mutate state and violate the read-only scope. Inference: unresolved Pylon items and their Linear-link coverage could not be enumerated reliably in that environment; an authorized Pylon export/connection is required.