PREDICT — Predictive & Heuristic Advisory Layer (Fera)

Источник: dev/fera/project-design/context/PREDICT.md (read-only; сгенерировано scripts/sync-docs.mjs)

PREDICT — Predictive & Heuristic Advisory Layer (Fera)

Status: Draft v0.1 — design only, all §12 open questions resolved by the author (2026-10-01). Nothing implemented or measured yet. Companion docs: ADR.md (ADR-019 prefetch tiers, ADR-015 typing, ADR-016 encryption tiers), OQ.md (OQ-023 where to apply heuristics, OQ-005 metadata/content classification, OQ-006 benchmark scene, OQ-011 regex planner, OQ-022 plugin fuel), RESEARCH-OQ-003.md (sticker cache, pre-registered falsifiers style), QA.md.

Legend: [author] = stated by the author. [proposed] = suggested in discussion, not yet confirmed. Anything unmarked is a consequence of those.

---

1. Goals and non-goals

Goals

• Lower perceived latency and lower energy/bandwidth/memory use through cheap, on-device heuristics and small models. [author] wants heuristic analysis adopted actively across the project, possibly a slightly more complex but still cheap “model-based” analysis.
• One shared advisory infrastructure instead of each subsystem rolling its own ad-hoc heuristics.

Non-goals

• No telemetry leaves the device.
• No advisor may affect correctness — only speed/cost (see §4.2).
• No heavy neural networks (training or inference) on the user’s device.

---

2. Two kinds of “model” [proposed]

The author’s open question: is “model-based” learned from user data or rule-based with a formal model? Proposed answer: both, for different jobs.

Kind	Used for	Properties
A. System models — rule-based, control loops, cost models (EWMA, RTT estimators, frame-budget governor, query cost model)	decisions about the system	deterministic, explainable, testable, no training data needed
B. Behavior models — small models learned on-device from the user’s own behavior	predicting what the user does next (next chat, next sticker)	per-user, tiny, online-learned, replaceable

---

3. Decision points (where to apply)

Ordered by value/cost. Every row is a decision point that registers with the shared layer (§4); none of them owns private heuristics.

#	Decision point	Kind	Notes
1	Frame-budget governor	A	Budgets [author]: UI 24, message updates 45, stickers/animation 60–75 fps. Adapts decode-ahead ring K, sticker raster 256/512, concurrent animation count from measured frame times. A control loop, no ML.
2	Chat/media prefetch (ADR-019)	B	The next-chat pipeline in §5.
3	Sticker cache retention & warm-up	A/B	What stays hot (TinyLFU/ARC-style recency+frequency), pre-warming the recent-stickers panel. Ties to RESEARCH-OQ-003 decompress-ahead ring.
4	Network	A	Adaptive timeouts and backoff from RTT estimates, DC choice, health-check cadence.
5	Plugin fuel (OQ-022)	A	Suggested budget from observed p95 usage; the plugin’s request stays a hint, the core decides, the user sees the amounts [author].
6	Startup ordering	A	Which modules to load/warm first, which DB pages to prefault.
7	Regex search planner (OQ-011)	A	Cost model with calibrated constants; possible learned cost model later.
8	Notification batching/priority	B	Deferred: errors are user-visible; needs explainability first.

---

3.1 Relation to existing docs

• ADR-019’s Tier 1/2/3 ladder is the same ladder as in §5, made concrete. This document is proposed to refine ADR-019, not contradict it.
• OQ-023 (where to apply heuristics) is answered in §3; its remaining question is the A-vs-B split in §2.

---

4. Architecture

4.1 Shared infrastructure [proposed]

actors ──events──▶ bounded event bus ──▶ PredictorActor
                     (drop on overflow)      ├─ event log → aggregates
                                              ├─ feature snapshots
                                              └─ Advisor registry
consumers ◀──Hint<T>── Advisor<Ctx, Hint> ◀───┘

• Event bus: bounded, non-blocking; on overflow events are dropped (never back-pressure the emitter).
• Log: append-only segments, compacted into aggregates (histograms, counters). Raw events are not kept forever (§9).
• PredictorActor lives under the root supervisor (ADR-006) and runs at idle priority.
• Model state is snapshotted with rkyv (ADR-007) under data/predictor/ and versioned separately from API editions (ADR-021).

4.2 Safety rule (hard requirement)

An advisor returns a hint, never a command, and never changes what is correct — only how fast or how cheaply it is obtained.

• Every consumer has a deterministic default used when the advisor is cold, abstains, errors, or is disabled.
• Advisor output is typed as Hint<T> (ADR-015) so it cannot be confused with authoritative data.
• Prefetch/advisor work is always lower priority than explicit user actions (ADR-019).

4.3 Sketch [proposed]

struct Probability(f32);            // smart constructor: 0.0..=1.0

enum Opinion<T> { Score(T), Abstain }   // experts may abstain

trait Expert<Ctx> {
    fn score(&self, ctx: &Ctx, candidates: &[Candidate]) -> Vec<Opinion<Probability>>;
    fn observe(&mut self, outcome: &Outcome);   // online update
}

trait Advisor<Ctx, H> {
    fn advise(&self, ctx: &Ctx) -> Hint<H>;
}

Advisors are candidates for hot-swappable first-party modules (ADR-001), behind an interface crate with an explicit edition (ADR-021).

---

5. Behavior pipeline: “what will the user open next”

Composition of three ideas the author liked, plus FTRL. [author] liked candidate generation + ranking, the expert ensemble, and the decision layer, wants them combined, and wants FTRL. The exact composition below is [proposed].

1. Candidate generation. Union of the top picks of all experts (~30 chats).
2. Experts score each candidate (each may abstain when data is thin):
   • frequency/recency at several scales (EWMA: hour/day/week);
   • Markov-style transition from the current chat (one feature, not the whole model);
   • time-of-day × day-of-week histogram;
   • decaying contribution of incoming messages (Hawkes-like, O(1) update; a fresh incoming message is an event, the strongest signal);
   • “they wrote last, unanswered”;
   • FTRL expert (§6), a personal logistic model over rich behavioral features;
   • optionally a streaming Hoeffding tree as one more expert, or as a gating function for context-dependent expert weights (mixture-of-experts).
3. Combiner: Hedge (multiplicative weights). Weights per expert, global or contextual (e.g. by time bucket). Hedge protects against a not-yet- trained FTRL: its weight starts small and grows as it proves itself. Relation to trees: Hedge weights ready-made predictors; a decision tree is one predictor. AdaBoost grew out of Hedge; with contextual weights this becomes a mixture of experts.
4. Calibration. One-dimensional (isotonic or Platt) on the combined score so that it behaves like a probability. A weighted sum of scores is not one.
5. Decision layer. Prefetch item i iff p_i × benefit_i > cost_i (bytes, battery, metered connection), selected greedily by p·benefit/cost under a global budget. Prediction and energy policy stay separate: the predictor reports probabilities, the policy lives in the decision layer.

Do not stack a second learned combiner over Hedge — two learned combiners in a row compete. Use either Hedge, or FTRL-stacking over expert scores, or (proposed) FTRL as one expert inside Hedge.

Later, only if needed: contextual bandits for the prefetch budget (ADR-019 Tier 3); chat embeddings from co-occurrence (item2vec-style). A small sequence neural net is deferred — on-device training and inference cost more than the expected gain.

Inside a chat (scroll/media prefetch) this is mostly kinematics: scroll direction and speed plus distance to viewport. No learning needed.

---

6. FTRL expert — features

FTRL-Proximal: online logistic regression with L1 sparsity and per-coordinate learning rates; update is O(non-zero features); features are hashed (2^18–2^20 buckets), so the model is kilobytes.

Behavioral features [proposed]:

• last 1–3 opened chats (n-gram context); time since the candidate was last opened;
• dwell time in the previous chat (skimmed vs read) and whether the user reached the bottom;
• draft present / currently typing;
• session type: just launched, burst of fast opens, idle;
• how the chat was opened: by notification or by the user;
• the user’s habitual reply latency in this specific chat;
• crosses: time-of-day × day-of-week; unread-count bucket; who wrote last; chat type; pinned/muted.

---

7. Labels and the training loop

• Hit definition (default, unconfirmed): the chat is opened within 5 minutes. Alternative: the first chat opened next. To be settled before the first evaluation.
• Labels arrive late. At prediction time, log the feature snapshot together with the prediction; attach the label when the window closes. Computing features at label time leaks the future.
• Cold start: FTRL abstains until it has enough examples; Hedge leans on the simple experts.

---

8. Evaluation

• Shadow mode first. The predictor predicts and logs, but does not act. Compare with reality before enabling.
• Metrics: recall@k for the hit definition; bytes prefetched but never used; latency saved on open; CPU/energy cost of the predictor itself.
• Replay harness: run models against recorded event logs offline (deterministic, seedable) so model changes are testable without live use.
• Pre-register falsifiers (style of RESEARCH-OQ-003.md) before the first bench: e.g. “if recall@k of the full stack does not beat the frequency-only expert by X, the added complexity is removed.”
• Advisors are stubbed out in contract tests (ADR-014); correctness tests must pass with every advisor disabled (§4.2).

Benchmark scene parameters are owned by OQ-006.

---

9. Privacy and storage

• Behavior logs (who, when) are sensitive. Place them in the strong encryption tier (ADR-016); the classification itself is OQ-005.
• Keep aggregates, not raw events, long-term; define retention/decay.
• The user can view, reset and disable prediction. [proposed]
• Stored at data/predictor/ (irreplaceable-tier per ADR-025 layout principles is debatable: model state is rebuildable, the raw log is not — decide which belongs where).

---

10. Energy

• The predictor must not wake the CPU when the app is idle.
• Prefetch is more conservative on battery and on metered connections.
• Predictor CPU/energy share has an explicit cap, and is itself measured.

---

11. Typing (ADR-015)

Probability as a validated newtype; Opinion::Abstain as an explicit variant instead of a magic value; Hint<T> for advisor output; separate types for logged-at-prediction features and labeled examples so the leakage in §7 is unrepresentable.

---

12. Open questions

1. Hit definition: 5-minute window or next-open? (§7) [resolved 2026-10-01, author] — next-open is primary, exactly because a 5-minute window is nearly unpredictable (“хер предскажешь”) and would burn effort. 5-min remains only as a secondary/loose background signal, not the trained target.
2. A vs B split accepted as stated in §2? (OQ-023) [resolved 2026-10-01, author] — accepted.
3. Which decision points are instrumented first? Proposed order: frame governor → prefetch → sticker retention. [resolved 2026-10-01, author] — agreed with the proposed order.
4. Where does model state vs raw log live (data/ vs cache/)? (§9) [resolved 2026-10-01, author] — raw log is irreplaceable → data/; model state is rebuildable from the log → cache/.
5. Is the A/B classification of each decision point in §3 right? [resolved 2026-10-01, author] — yes, accepted.
6. Is FTRL-as-expert-inside-Hedge the final composition, or test FTRL-stacking against it in the replay harness? [resolved 2026-10-01, author] — FTRL-as-expert-inside-Hedge is the final composition; FTRL-stacking is only an experiment inside the replay harness, not a default alternative.
7. Retention/decay policy and user-facing controls for the behavior log. [resolved 2026-10-01, author] — raw log kept 30 days, then only aggregates. User controls: view / reset / disable.
8. Contextual Hedge weights: which context (time bucket only, or device/power state too)? [resolved 2026-10-01, author] — time bucket + power state (the energy-saving mode exists, OQ-024).

---

13. Suggested sequencing [proposed]

1. Event bus + log + aggregates + Advisor trait (no models yet).
2. Frame-budget governor (type A; immediate value; measurable).
3. Shadow-mode next-chat predictor with simple experts + Hedge.
4. FTRL expert, then calibration and the decision layer.
5. Enable prefetch behind the safety rule (§4.2); compare against the pre-registered falsifiers.
6. Remaining decision points (§3) one by one.