Преглед изворни кода

Update docs for arbitration model

master
Jan Svabenik пре 10 часа
родитељ
комит
755896cc5d
2 измењених фајлова са 8 додато и 3 уклоњено
  1. +1
    -1
      PLAN.md
  2. +7
    -2
      README.md

+ 1
- 1
PLAN.md Прегледај датотеку

@@ -126,7 +126,7 @@ Wichtig:
- track
- present
- record
- Gemeinsame Arbitration-/Budget-Sicht für refinement/record/decode zentralisieren (Admission + Queue/Hold + Debug-Surface)
- Gemeinsame Arbitration-/Budget-Sicht für refinement/record/decode zentralisieren (Admission + Queue/Hold + Debug-Surface) — umgesetzt via zentralem Arbiter im Pipeline-Paket + normalisierter Reason-Taxonomie; künftige Phase: tieferer Scheduler/Intent-Budget-Override

### F. Dokumentierte Betriebsprofile
- initiale Profile definieren, z. B.:


+ 7
- 2
README.md Прегледај датотеку

@@ -84,7 +84,7 @@ Edit `config.yaml` (autosave goes to `config.autosave.yaml`).
- `resources.max_refinement_jobs` — processing budget hint
- `resources.max_recording_streams` — recording/streaming budget hint
- `resources.max_decode_jobs` — decode budget hint
- `resources.decision_hold_ms` — baseline hold time for queue slots before churn (arbitration scales per profile/strategy)
- `resources.decision_hold_ms` — baseline hold time for queue slots before churn (arbitration scales per profile/strategy and tags hold reasons in debug snapshots)
- `profiles[]` — named operating profiles/intent metadata

In phase 1, the engine stays backward compatible, but the config model now reflects the intended separation between:
@@ -95,7 +95,12 @@ In phase 1, the engine stays backward compatible, but the config model now refle
- presentation
- operator goals / future autonomous intent

Refinement plans now rank candidates, while a shared arbitration step admits refinement/record/decode work based on budgets and hold policy.
Refinement plans now rank candidates, while a shared arbitration step admits refinement/record/decode work based on budgets and hold policy. Arbitration reasons are normalized:
- `refinement:*` for work item lifecycle (planned/admitted/running/completed/drop/skip)
- `admission:*` for refinement admission outcomes
- `decision:*` for record/decode decisions
- `queue:*` when record/decode is deferred by budget
Hold policy reasons are surfaced as `profile:*` / `strategy:*` tokens in `hold_source`.

The long-term target is that you describe *what the system should do* (for example broad-span monitoring intent, preferred signal families, auto-record/decode priorities), while the engine decides *how* to allocate surveillance, refinement and decoding budgets.



Loading…
Откажи
Сачувај