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 atdata/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-231carries 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:237saysdata/predictor/while OQ-009 saysdata/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-9claims 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 atPREDICT.md:247has no number, and the only pre-registered falsifier atPREDICT.md:222-223thresholds at a literal placeholder “X” — in a document that claims “pre-registered falsifiers … before the first bench” (:221). -
severity: mid
Суть / Substance
Section titled “Суть / Substance”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:
- The tier inversion is a live QA blocker. QA gates on “every
persisted type has an explicit tier answer” (
QA.md:22-24, extended byADR.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. - 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.
- 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.
- 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).
Предлагаемое решение
Section titled “Предлагаемое решение”(C) first, then (A)+(B) together.
- 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 bothPREDICT.md:20-23andOQ.md:759-764without anyone losing a wanted feature. - Fix the tier: ADR-031’s table (
ADR.md:650-652) is the reference per its ownADR.md:684-686, so decide whether the predictor log is metadata or content there, and correctOQ.md:229-231andPREDICT.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. - 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. - 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. - 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.
- 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; perRESEARCH-OQ-003.md’s discipline (every number either arithmetic-shown or[est]), PREDICT should say the same.