Parity Is Behavioral, Not Pixel-Perfect

"Parity means the same useful result, not the same pixels."

The Trap of Copying the Surface

When you set out to replace a beloved tool, the lazy definition of success is "make mine look and feel exactly like theirs." It's a trap. Copy the window layout, the menu wording, the preference tree, and you've inherited every accident of the original's history while learning nothing about why any of it works. You also drift straight into copying code, assets, and design — which is both a legal problem and a soul problem.

Ashen Reel takes the opposite stance. It may preserve useful command meanings and muscle memory, but it copies no Movist code, assets, wording, window layout, or preference structure. Parity is judged on results, and results are behavioral.

Seven Rules for "Same Result"

The parity contract writes the standard down so it can't drift into vibes. The load-bearing ones:

Muscle memory is observed, never guessed. You record Movist's actual default keys and mouse behavior before assigning your own. No inventing shortcuts from memory.
Fast and exact seek stay distinct. Continuous scrubbing may trade precision for smoothness; an exact Recall jump may not. Same word, two different guarantees.
State is acknowledged. Menus and controls project what the engine actually did, not the last command you sent.
Output is empirical. HDR, 10-bit, Dolby Vision, subtitle timing, A/V sync — every claim needs a side-by-side result on the real display path, not a spec sheet.

Empirical Means You Actually Looked

"Output is empirical" is the rule people skip. It's tempting to say "libmpv decodes HEVC Main 10, therefore HDR is fine." No. You put Ashen Reel and Movist on the same Pro Display XDR, play the same 10-bit file, and look — color, brightness, banding, dropped frames. A parity case is stored as data, not a feeling:

Write your acceptance as machine-checkable cases before you write the feature. A behavior with an id, a precondition, an oracle action, and an expected result can't quietly regress into "looks about right." The case file becomes the contract.

"It matches Movist pixel-for-pixel" is not a goal — it's a distraction. Two correct HDR pipelines can render subtly different pixels and both be right. Chasing identical output pulls you toward reverse-engineering someone else's rendering choices instead of proving yours are correct.

The payoff of behavioral parity is independence. Ashen Reel doesn't need Movist to exist to be correct — it needs Dad's media to play right. Movist is just the oracle that tells you when you've matched, and the fallback while you're still proving it.

Code

A parity behavior case — stored as data, never a vibe (redacted)·json

{
  "id": "AR-PAR-004",
  "scope": "P0",
  "precondition": "a 10-bit HEVC clip is loaded and paused",
  "oracle_action": "press the forward relative-seek key three times",
  "expected": {
    "applied_interval_each": "configured tier value",
    "overlay_shows": ["direction", "interval", "current_position"],
    "source_bytes_changed": false
  },
  "ashen_reel_result": "applied +Ns x3; overlay reported forward/N/position",
  "movist_oracle_result": "applied comparable relative movement"
}

Exercise

Take a feature you'd want to reproduce from a tool you admire — say, its 'undo' or its 'search'. Write it as a behavior case: a precondition, the action a user takes, and the observable expected result (something you could check without opening the original). Notice how writing the expected result forces you to define 'correct' in your own terms rather than 'whatever they do.'

Hint

If your expected result is 'the same as theirs,' you haven't defined it — you've deferred it. Push until the expected result is a concrete, observable fact: a value, a visible state, a file that did or didn't change.

Parity Is Behavioral, Not Pixel-Perfect

The Trap of Copying the Surface

Seven Rules for "Same Result"

Empirical Means You Actually Looked

Code

External links

Exercise

Progress

Comments 0