Skip to content

Qualify one authenticated durable UTEL producer-to-current-receiver receipt #4705

Closed

Description

@EHotwagner

Owner: Programme /root is accountable for intake and owner recovery; implementation ownership, existing branches and original attempts are preserved; this intake does not dispatch work. Programme /root accountable; existing telemetry application owner implements; existing Home installation owner supplies host/application cutover and credential custody. Recover their current identities before assignment; no replacement worker.

Done when: One already necessary genuine batch from the existing canonical persistent association reaches the selected compatible installed receiver through its qualified application scope, obtains a durable acknowledged receipt, and is independently read back in the canonical store. A duplicate/correction check preserves one current contribution and original history. Exact producer/receiver artifacts, original operation identities, supported population and missing attribution remain explicit. This accepts only this normal durable receipt window.

Current deliverable: Existing telemetry producer/spool and receiver application configuration/receipt read path; Home owns fresh-current-data fencing, installation and application credential custody. Do not repoint or clone old offline observations.

Next action: Reconcile completed #4682/actual installed108 and Host0.7 staging with the current application owner; identify exact credential-reference and compatible cutover assertion. Continue original source/custody and separately admit only the remaining effect before the genuine receipt journey.

Blocked on: Fresh-current-data backup/fence and reviewed compatible production cutover, actual application bearer scope/restoration and authenticated ingestion are unqualified. Accepted SSH/TLS, disposable migration/restore and staging do not supply them. Use the existing Home#4516 request channel rather than duplicate a host-supplier issue.

Acceptance evidence: utel-operational-completeness.md: Passive observation decision, Capability boundary, Coverage contract, UTEL-06.2–.7; utel-release-successor.md; parent accepted Host0.7 and canonical local capture evidence. Preserve accepted parent source/publication evidence at its original scope. Record actual PR/head, selected artifact/profile/operation, independent scoped result and native acceptance here after they exist; this draft supplies none. Full original parent promise and history remain authoritative at #4638; broader programme outcome: #4638. This bounded source/receiver result does not close either broader promise. Accepted decomposition design: #4701 and docs/coordination/2026-10-19-board-clearing-lifecycle-design.md (owning source plan; publication remains separate).

Activity

  1. EHotwagner commented on Oct 22, 2026

    @EHotwagner
    ContributorAuthor

    Programme/root record 2026-10-22: by user decision, Home (SystemAdmin) is the telemetry application custodian and installation/access operator, replacing the unrecovered Main/application custodian; Programme/root accepts Home results only after independent subagent review. Request and roadmap: #4516 comment 6334674310 (marker utel-custodian-home-20261022); #4707 fields updated. Full promises, original effects and holds unchanged.

  2. EHotwagner commented on Oct 22, 2026

    @EHotwagner
    ContributorAuthor

    fdev 2026-10-22: ACCEPTED: one authenticated durable UTEL producer→current-receiver receipt, qualified. This rests on an independent acceptance review (fsgg-critic-best). Every hash and gate was recomputed from the JSON evidence, and none was vacuous.

    Selected artifact and operation identities

    • Producer:
      • the existing canonical persistent association passive-home-canonical-v1: workspace utel-home-20261003, producer codex-passive-home-01, stream native-usage;
      • the config was unchanged since 2026-10-18 and was not repointed;
      • engine coord-0.112.0 (0.112.0+d5af6a98), binding 8fdb3eb5…, generation 94ef3481….
    • Batch: passive-94ef3481bf024ac2839e3bd67f7628c5-1, a genuine pre-existing batch created 2026-10-18 21:57:56Z with 25 events. Its envelope digest is edc60b6d47e35c5291e9984d12732bc38ed289ebd2e6a4cbb91e9973f85454f9, and its receipt key is 6d4c2b0a….
    • Receiver: Home Host 0.8.0 (def 5b9bc146) on the uv14 store store14-v1, cut over under Qualify the first installed facts-and-coverage provider-to-browser journey #4707.
    • Credential: home-passive-programme-v1, enrolled by an admitted step: rowDelta {receipt_producers: +1}, Home custody.
    • Before the enrollment: 002ca0e2… was found to be a terminal single run, not an association, so no ordinal-4 send was fabricated.

    Receipt window (2026-10-22 UTC)

    1. Enrollment committed at 15:05.
    2. Receiver pre-state at 15:12: lifetime 4, pending 0, and 0 facts for the producer.
    3. Send at 15:14: durably-received.
    4. Post ADR-0002: composition by scaffold, lifecycle parameter, governance populated #1 at 15:15: the transport_receipts row for producer/batch/stream is applied, with digest = the producer's envelope digest. Lifetime went 4→5, pending 0.
    5. Settle at 15:17: a lookup only. The producer's batch-1 .ready was settled to applied, and batch 2 is unchanged.
    6. Post ADR-0002: record versioning hardening as accepted Decision 5 #2 at 15:17:56: the store copy is byte-identical to post ADR-0002: composition by scaffold, lifecycle parameter, governance populated #1.

    Independent readback in the canonical store:

    • fact_admissions and ingest_facts +25 for the producer, all bound to receipt key 6d4c2b0a… and digest edc60b6d…;
    • integrity ok.

    Duplicate/correction check:

    • one current fact for each of the 25 identities, and correctionsTotal 0;
    • the four prior receipts are untouched;
    • no stray envelope in either inbox, and the old uv12 store is still at its seal 2e08fd93.

    Secrets: none appear in the evidence. The producer and Home client copies are deleted, and only the receiver's server copy remains.

    Supported population, explicit: one selected Codex native-usage source, from the 2026-10-18 rollout. Producer state shows gaps 2. This window delivered one batch of 25 events: 24 provider-usage-observation/1 and 1 source. Batch 2 (passive-94ef3481…-2, 24 events, digest d8911865…) remains pending. A later drain needs a newly admitted credential delivery. No backfill or complete coverage is claimed.

    Missing attribution, explicit:

    • activity_usage_attributions, budget_attribution_facts, usage_observations and runtime_turn_usage all stayed 0, and the dashboard doesn't name the producer.
    • Programme/activity attribution of these observations is therefore Unknown. This receipt proves durable ingest and admission only.

    Retained Unknowns:

    • (i) one health_diagnostics row appeared (0→1) after the receipt, and its content wasn't read;
    • (ii) the receiver's payload_bytes is 23833 against an envelope file of 23635 B. The 198 B difference is unexplained, and is probably transport framing;
    • (iii) the receiver doesn't log which credential reference authenticated; that is inferred from the exact producer/stream binding.

    None of these affects the receipt. All original Unknown operations and the 439 + 46 reservations stay retained under #4638.

    Evidence: .github#4516 comments 6344035100 (enrollment), 6344194956 (pre), 6344230549 (send), 6344259035 (post #1), 6344291431 (settle), 6344321651 (post #2); producer analysis 6343114421; receiver cutover #4707. The raw evidence is retained privately.

    This accepts only this normal durable receipt window. Next for the parent (#4638): a credential-delivery decision for draining batch 2, attribution, and the 3d retention cleanup after the window ends at 2026-10-23 14:10Z.

  3. EHotwagner commented on Oct 22, 2026

    @EHotwagner
    ContributorAuthor

    fdev 2026-10-22, Status reconciliation: through the guarded writer, Status Blocked → Done was written once, at 15:24Z, with a possible send, and live readback shows Done. Project 3 still holds exactly 69 items. The writer's own post-write engine readback (board-v2 migration-prepare) refused with exit 3 and no detail. No automatic retry was made. The private evidence is retained. That readback is a retained gap: fdev will re-verify the full board through the next sealed read. Closing as completed per the acceptance above.

  4. EHotwagner commented on Oct 22, 2026

    @EHotwagner
    ContributorAuthor

    fdev 2026-10-22, readback gap closed. An independent read-only analysis compared the writer's own 15:24:04Z baseline with the live board. All 69 items, all 17 fields with their options and all 8 views are identical, except #4705's Status Blocked→Done (value timestamp 15:24:18Z, timeline project_v2_item_status_changed 15:24:20Z, then closed 15:25:15Z).

    The writer's post-write engine readback refused because GitHub's GraphQL API intermittently answered Project 3 items with totalCount 0 (HTTP 200, no errors). This happened during an open GitHub incident, "Errors loading Issues, Pull Requests, and search results", investigated from 15:28Z. The engine's double-read stability check then failed closed. The write is complete; nothing is resent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions