Skip to content

Search is only available in production builds. Try building and previewing the site to test it out locally.

The predictor's log has three different encryption tiers in three docs, its layout answer contradicts its own §9, and its scope contradicts OQ-023

Источник: dev/fera-research/docs/oc1/025-predictor-tier-layout-window-and-scope-conflicts.md (read-only; сгенерировано scripts/sync-docs.mjs)

The predictor’s log has three different encryption tiers in three docs, its layout answer contradicts its own §9, and its scope contradicts OQ-023

Section titled “The predictor’s log has three different encryption tiers in three docs, its layout answer contradicts its own §9, and its scope contradicts OQ-023”
  • kind: problem

  • area: storage / perf

  • evidence — the predictor event log’s tier, three answers:

    Source Answer
    ADR.md:650-652 (ADR-031, the audit QA gates on) metadata tier — “chat/message IDs, timestamps, counters, ReadState, outbox status…, predictor event log”
    OQ.md:229-231 (OQ-009, resolved 2026-10-02 — one day after ADR-031) “data tier, content-encrypted per ADR-031”
    PREDICT.md:232-233 “Place them in the strong encryption tier (ADR-016)”

    So the field that QA’s cross-cutting gate requires an answer for (QA.md:22-24) has three answers, and the newest one (OQ-009) cites the oldest one (ADR-016) for a classification ADR-031 has since made — and gets it backwards relative to ADR-031’s table.

  • Layout: §9 was never updated after its own resolution.

    • PREDICT.md:237-239 — “Stored at data/predictor/ (irreplaceable-tier per ADR-025 layout principles is debatable… decide which belongs where).”
    • PREDICT.md:272-274 (§12 Q4, resolved 2026-10-01) — “raw log is irreplaceable → data/; model state is rebuildable from the log → cache/.”
    • OQ.md:229-231 carries the resolved form. So §9 still contains the open question and the wrong ADR citation, in the same document, after the answer was recorded 30 lines below. ADR-025 is secret chats (ADR.md:462); the layout decision is OQ-021.
    • Also note PREDICT.md:237 says data/predictor/ while OQ-009 says data/accounts/<id>/predictor/ — the per-account form (my finding 007).
  • The Tier-2 target was changed; ADR-019 and TECHSPEC still specify the old one.

    • PREDICT.md:262-266 (§12 Q1, resolved 2026-10-01, author) — “next-open is primary, exactly because a 5-minute window is nearly unpredictable… 5-min remains only as a secondary/loose background signal, not the trained target.”
    • ADR.md:742-743 (ADR-019 Tier 2) — “a simple model … predicting P(open in next N minutes), trained per-user”.
    • TECHSPEC.md:232-233 — “contextual feature model … → P(open within N minutes)”.
    • Both normative docs still describe the discarded target. The author’s stated reason (“хер предскажешь”) is a real finding — a minutes-window open-predictor is close to noise — so this is a case where the normative docs are wrong and the research doc is right.
  • Scope: PREDICT wants project-wide heuristics; OQ-023 forbids it.

    • PREDICT.md:20-23 — the author “wants heuristic analysis adopted actively across the project, possibly a slightly more complex but still cheap ‘model-based’ analysis”; and :24-25 — “One shared advisory infrastructure instead of each subsystem rolling its own”.
    • OQ.md:759-764 (author’s clarification, 2026-10-01) — “applies only to the predictor … Not a project-wide practice; other subsystems are out of scope.”
    • And 5 of PREDICT’s 8 decision points (PREDICT.md:52-61) are cross-subsystem: frame-budget governor, network timeouts/DC choice, plugin fuel, startup ordering, regex search planner.
    • PREDICT.md:8-9 claims to be refining ADR-019, not contradicting it.
  • Retention exists only in PREDICT: 30-day raw-log retention at PREDICT.md:283-284 / OQ.md:777-779; absent from ADR-019 and TECHSPEC §5 (my finding 013 counts this among the unbounded stores).

  • Two unfalsifiable commitments (both flagged in the doc’s own [proposed] style): the energy cap at PREDICT.md:247 has no number, and the only pre-registered falsifier at PREDICT.md:222-223 thresholds at a literal placeholder “X” — in a document that claims “pre-registered falsifiers … before the first bench” (:221).

  • severity: mid

PREDICT.md is the best-researched document in the corpus (it resolves its own open questions with dated author sign-off, which is exactly the discipline README.md:41-45 asks for) — and it is the document the rest of the corpus failed to absorb. Four consequences:

  1. The tier inversion is a live QA blocker. QA gates on “every persisted type has an explicit tier answer” (QA.md:22-24, extended by ADR.md:684-686). For the predictor log there are three answers, and the two newest disagree with the audit table they cite. Someone implementing the log’s encryption will pick one and be wrong per the other two.
  2. The Tier-2 model target is wrong in both normative docs. ADR-019 and TECHSPEC §5 describe training toward “P(open within N minutes)” after the author explicitly demoted exactly that target. A team implementing from TECHSPEC (the “buildable breakdown”) builds the discarded model.
  3. Scope is genuinely contradictory, and this one needs a human call. The author apparently wants project-wide heuristic/control-loop infrastructure (which is why PREDICT §3 covers network, plugins, startup, search and frame budgets); the OQ that was supposed to record the scope says the opposite. PREDICT §3 is also where the frame-budget governor comes from — which my finding 008 shows would invalidate the benchmark that validates it.
  4. Retention and eviction of the log are PREDICT-only facts. 30-day retention, aggregates-not-raw-events long term, and user-visible reset/disable are all decided in PREDICT §9 and absent from ADR-019 and TECHSPEC §5 — so an implementer following TECHSPEC builds an unbounded behaviour log that is also mis-tiered.

The meta-point, again: PREDICT resolves its questions internally (§12) instead of writing them back into the ADRs it refines. The corpus’s resolution protocol handles OQ→ADR but not “research doc supersedes ADR detail”, which is precisely the situation here.

Варианты решения (tradeoffs)

Section titled “Варианты решения (tradeoffs)”
  • (A) Absorb PREDICT into ADR-019 + TECHSPEC §5, and mark §9 as superseded by its own §12. Straightforward; makes the normative docs true.
  • (B) Declare PREDICT.md normative for the predictor subsystem and have ADR-019/TECHSPEC §5 reference it instead of restating it. Avoids triple duplication (currently ADR-019, TECHSPEC §5, OQ-009, PREDICT §5/§7 all describe the same tiers and windows).
  • (C) Resolve the scope question first (predictor-only vs project-wide advisory layer), because the answer changes whether this is one subsystem’s ADR amendment or a new architectural decision (a shared advisory/control-loop layer is a new component with its own failure modes — e.g. it can stall a subsystem’s own control loops, which ADR-019’s safety rule only covers for the predictor).

(C) first, then (A)+(B) together.

  1. Decide the scope question on the bus/with the author — this is the only item in this finding that needs a human preference rather than a derivation. My read: PREDICT §3’s cross-subsystem control loops (frame governor, network, startup ordering, plugin fuel) are genuinely valuable and are not the same thing as behaviour prediction, so splitting the document — “Kind A system models” (PREDICT.md:42-45) into its own component/ADR, and keeping Kind B behaviour prediction as the ADR-019 predictor — resolves both PREDICT.md:20-23 and OQ.md:759-764 without anyone losing a wanted feature.
  2. Fix the tier: ADR-031’s table (ADR.md:650-652) is the reference per its own ADR.md:684-686, so decide whether the predictor log is metadata or content there, and correct OQ.md:229-231 and PREDICT.md:232-233. My recommendation: content tier — a behaviour log (who opened which chat, when) is closer to message content than to counters, and ADR-031’s rationale for metadata (“nothing searches over it”) does not apply. Whichever way, one table, one answer.
  3. Fix the Tier-2 target in ADR-019 and TECHSPEC §5: primary label = next-open, with the 5-minute window demoted to a background signal — matching PREDICT.md:262-266.
  4. Fix PREDICT §9 (PREDICT.md:232-239): cite ADR-031 (not ADR-016) for the tier, OQ-021 (not ADR-025) for layout, use the per-account path, and replace the “decide which belongs where” sentence with the §12 answer.
  5. Move retention into ADR-019 (30-day raw log, aggregates long-term, user-visible reset/disable) so it is a decision rather than a PREDICT detail, and connect it to the eviction/quota ADR (finding 013) — a behaviour log is exactly the kind of store that needs a bound.
  6. Give the two soft commitments numbers: the energy cap (PREDICT.md:247) and the recall falsifier’s “X” (PREDICT.md:222-223). A pre-registered falsifier with a placeholder threshold is not pre-registered; per RESEARCH-OQ-003.md’s discipline (every number either arithmetic-shown or [est]), PREDICT should say the same.