HCRM EVALUATION DEMONSTRATION — v0.1 Bounded examples of merging operation histories. What happens when people edit separate copies of the same record? This small demonstration combines recorded changes to a record. It shows when both changes can survive, when disagreement should remain visible, and when inconsistent inputs should be rejected. It illustrates bounded merge behavior; it does not demonstrate a complete collaborative application. Each recorded change is an operation. Each operation has an ID. A history is a collection of those operations, including information about earlier operations they depend on. An invalid history means the input operations violate one of the checks below; it is not a separate ninth example you need to find. Run Use Python 3.9 or later, from this extracted folder: python3 -I -S run_demo.py No extra Python packages, account, purchase, network access or API key is needed. Python itself must already be available. Expected result: status LOCAL_DEMO_PASS, cases_passed 8, reference_files_verified 7. A failed expectation exits with an error. cases.json contains the inputs and expected results. Reading the results Each case has a name and result. PASS means it behaved as expected, including cases that correctly reject input. For successful cases, state shows the merged values, counters and any retained conflicting alternatives. For rejected cases, rejected gives the reason; no merged state is produced for that case. The eight cases — match these names to your output 1. Disjoint concurrent edits survive One person changes owner; another changes status. The result keeps owner Alice and status review. Changes to different fields need not overwrite each other. 2. Same-field alternatives remain visible as a conflict Two edits to status disagree. review is displayed, and ready is also retained in conflicts. The displayed value gives a consistent view; it does not establish that one edit was more correct or that the disagreement has been resolved. Preserving both lets a reviewer see the disagreement instead of losing an edit. The visible choice uses this prototype's operation-ID ordering, not a claim about Automerge's internal winner selection. 3. Duplicate delivery does not double-count increments The unique increments total 5 + 2 + 3 = 10. Receiving the same operation again must not count it again. An identical operation with the same ID is recognized as a repeat, so the total stays 10. 4. Causal deletion removes an earlier value A later deletion depends on the earlier operation that set a value. The field is absent from the result. The operation record is still retained; removing a field's value is different from erasing the record of its changes. 5. Conflicting operation IDs are rejected The same ID is attached to different operations. An ID must identify one operation, so these inputs are rejected instead of silently choosing one. Compare case 3: same ID and identical contents means harmless repeat; same ID and different contents means conflicting identity. A repeated ID alone is not an error. This is one example of an invalid history. 6. Missing causal dependencies are rejected An operation refers to an earlier operation that is absent from the supplied inputs. The demo cannot establish the required relationship, so it rejects the input rather than treating that incomplete history as a valid merged state. 7. Scalar and counter mixing is rejected The same field is used for an ordinary set/delete value and for a counter. This bounded prototype does not support mixing those meanings for one field, so it rejects the input. 8. Dependency cycles are rejected The dependency chain loops back on itself: an operation would depend on itself through other operations. That cannot establish a consistent before/after relationship, so the input is rejected. Short review - Find the displayed status and the retained alternative in case 2. Explain why seeing both could matter. - Explain why the total stays 10 in case 3. - Choose one rejected-input example (cases 5–8) and explain its stated reason. For case 5, compare identical repeats with different contents under one ID. - Suggest a possible use, one limit, and one improvement. Record confusion or setup friction before asking for help. This is a review of the demonstration and its instructions; it is not a test of the reader. Scope and provenance The seven files in reference/ remain unchanged bytes from the approved public companion automerge-merge-semantics-me-candidate-v0.1-public-evaluation.zip, SHA-256 9ae5d9320609b4fd2e4a89755e1333f5ed481d1757ced6e7d18a527d40fc5f09. reference-file-hashes.json checks those identities before execution. Keep its original license, evaluation metadata, capability contract and non-claims. No paid governed archive, private entitlement or customer data is included. The prototype covers map scalar/delete and additive counters. It is not an official Automerge implementation or wire-compatible client. List/text/rich-text, storage and synchronization are outside the demonstration. Successful examples do not prove that a complete app works. Reversing merge order and repeating identical histories are checked for each successful case; regrouping is also checked where the case provides enough histories. Status This is a bounded evaluation demonstration with recorded examples and an offline reference runner. Its reference files retain their original public-companion evaluation metadata, capability contract and non-claims. This wrapper does not change their commercial catalog authorization or imply endorsement.