|
|
|
@@ -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. |
|
|
|
|
|
|
|
|