|
| 1 | +# RECONCILIATION_LAYER_SPEC |
| 2 | + |
| 3 | +## Objective |
| 4 | +Define a reusable, sample-safe reconciliation layer for Level 11 progression. This layer compares predicted client-side simulation state with authoritative updates and determines how corrections should be surfaced and applied. |
| 5 | + |
| 6 | +## Design Principles |
| 7 | +- Layered, not invasive |
| 8 | +- Sample-safe first |
| 9 | +- Public-boundary only |
| 10 | +- Debug-friendly by design |
| 11 | +- No direct engine-core rewrites |
| 12 | + |
| 13 | +## Core Terms |
| 14 | +### Predicted State |
| 15 | +The locally simulated state advanced by the client/sample before authoritative confirmation arrives. |
| 16 | + |
| 17 | +### Authoritative State |
| 18 | +The state accepted as source-of-truth from an approved upstream authority. |
| 19 | + |
| 20 | +### Divergence |
| 21 | +The measurable difference between predicted state and authoritative state for one entity, one frame, or one logical update. |
| 22 | + |
| 23 | +### Correction |
| 24 | +The action chosen to reduce or resolve divergence. |
| 25 | + |
| 26 | +## Responsibilities |
| 27 | +The reconciliation layer should: |
| 28 | +- accept predicted snapshots |
| 29 | +- accept authoritative snapshots or events |
| 30 | +- align comparable state units |
| 31 | +- compute deltas |
| 32 | +- choose a correction strategy |
| 33 | +- expose correction metadata to debug surfaces |
| 34 | + |
| 35 | +The reconciliation layer should not: |
| 36 | +- own rendering |
| 37 | +- directly own transport/networking |
| 38 | +- mutate engine internals through private hooks |
| 39 | +- become a hidden replacement for game scene logic |
| 40 | + |
| 41 | +## Suggested Data Flow |
| 42 | +1. Sample/game simulation advances predicted state. |
| 43 | +2. Snapshot is recorded into a bounded history buffer. |
| 44 | +3. Authoritative update arrives through an approved source boundary. |
| 45 | +4. Reconciliation layer matches update to a frame/tick/entity. |
| 46 | +5. Divergence is computed. |
| 47 | +6. Correction policy decides snap, smooth correction, or debug-hold. |
| 48 | +7. Debug contract receives normalized divergence/correction data. |
| 49 | + |
| 50 | +## Candidate Interfaces |
| 51 | +```text |
| 52 | +recordPredictedSnapshot(snapshot) |
| 53 | +receiveAuthoritativeSnapshot(snapshot) |
| 54 | +reconcileLatest() |
| 55 | +getLatestDivergenceReport() |
| 56 | +getCorrectionPlan() |
| 57 | +``` |
| 58 | + |
| 59 | +Exact naming may vary, but the functional responsibilities should remain stable. |
| 60 | + |
| 61 | +## Correction Modes |
| 62 | +### 1. Snap |
| 63 | +Use when: |
| 64 | +- divergence is severe |
| 65 | +- object count is low |
| 66 | +- clarity is more important than feel |
| 67 | +- debug mode explicitly requests hard truth |
| 68 | + |
| 69 | +### 2. Smooth Settle / Lerp |
| 70 | +Use when: |
| 71 | +- divergence is modest |
| 72 | +- visual continuity matters |
| 73 | +- the sample is teaching correction behavior |
| 74 | + |
| 75 | +### 3. Hold + Annotate |
| 76 | +Use when: |
| 77 | +- goal is observability |
| 78 | +- immediate correction would hide the problem |
| 79 | +- the sample/debug overlay needs to show the mismatch clearly |
| 80 | + |
| 81 | +## Normalized Divergence Fields |
| 82 | +Recommended normalized fields for debug/reporting: |
| 83 | +- `entityId` |
| 84 | +- `predictedFrame` |
| 85 | +- `authoritativeFrame` |
| 86 | +- `positionDelta` |
| 87 | +- `velocityDelta` |
| 88 | +- `stateFlagsDelta` |
| 89 | +- `correctionMode` |
| 90 | +- `severity` |
| 91 | + |
| 92 | +## Severity Guidance |
| 93 | +Suggested severity bands: |
| 94 | +- low: informational |
| 95 | +- medium: visible mismatch, correction recommended |
| 96 | +- high: state invalidation or obvious desync |
| 97 | + |
| 98 | +## Boundary Rules |
| 99 | +- No new engine-core dependency from shared engine code into sample code. |
| 100 | +- No private scene mutation shortcuts. |
| 101 | +- No transport assumptions baked into reconciliation interfaces. |
| 102 | +- Shared logic should remain consumable by multiple future samples. |
| 103 | + |
| 104 | +## Migration Guidance from Sample C |
| 105 | +Sample C should remain: |
| 106 | +- a teaching sample |
| 107 | +- a divergence visualization surface |
| 108 | +- an early consumer of the contract |
| 109 | + |
| 110 | +Sample C should not become: |
| 111 | +- the shared reconciliation implementation itself |
| 112 | +- a dumping ground for generic runtime logic |
| 113 | + |
| 114 | +## Future Expansion |
| 115 | +This spec should later support: |
| 116 | +- rollback/resimulation experiments |
| 117 | +- server trace visualization |
| 118 | +- deterministic replay comparison |
| 119 | +- multi-entity correction batching |
0 commit comments