# Duplication check and positioning

Check date: 2026-08-21.

## Similar MoonBit projects found

- `lyjttio/moon-data-contract`: data contract validation, schema evolution audit, policy gate, migration plan and Markdown/JSON/JUnit evidence export.
- `YumeCross/schema` and `mizchi/jsonschema`: JSON Schema validation and related tooling.
- `Betterlol/moon_zod`: runtime schema validation and conversion-style APIs.
- `FidollarinLA/moon_api_guard`: public MoonBit API compatibility checking for `.mbti` surfaces rather than JSON payloads.
- `001-Elsa/moonpack`: schema-first binary serialization with schema compatibility concerns.
- `JJ-ai-nb/moonbit-submit-guard`: hackathon submission-readiness checks for repository metadata, commands and project snapshots.
- `WB-ai-nb/constraint-lens`: reviewer-feedback parsing, novelty matrices and resubmission planning.
- `NBB2006/harborcheck` and `EJJ-ai-nb/harborcheck`: README example verification, Mooncakes readiness and open-source provenance evidence.
- `SHX-ai-nb/capsuletrace-upload`: capability boundary and acceptance trace validation for project requirements.

## Risk and adjustment

The original broad phrase "data contract evolution analysis" was too close to `moon-data-contract`. EvoWitness therefore narrows its public boundary to compatibility falsification:

- generate the smallest practical JSON counterexample for a breaking semantic change;
- verify the counterexample against both contract versions;
- export witness packs and JSONL negative-test streams;
- keep validation, policy and migration helpers secondary to witness evidence.

EvoWitness deliberately does not provide a schema registry, ownership governance, JUnit evidence, external ticket automation, binary serialization format, OpenAPI/JSON Schema ingestion, or a general runtime schema DSL.

## Screenshot-driven risk review

Recent rejection examples show several high-risk patterns: generic names ending in Check/Proof/Policy/Trace, repositories associated with `*-ai-nb` batches, hidden overlap with recently published packages, and proposal text that does not explain an extension relationship.

EvoWitness was checked against those patterns:

- name risk: the public project name is `EvoWitness`, not a Check/Proof/Policy/Trace-style readiness or review tool;
- account/repository risk: the local project does not reference or depend on `*-ai-nb` repositories;
- hidden-extension risk: the project does not claim to extend HarborCheck, ReviewProof, Constraint Lens, CapsuleTrace, moonbit-submit-guard or moon-data-contract;
- functional risk: it does not parse rejection emails, inspect README snippets, verify provenance records, score repository submission readiness, maintain capability matrices, or validate Mooncakes release metadata;
- retained overlap: the package contains small helper APIs for witness scoring and compatibility policy, but those helpers operate only on generated compatibility witnesses and are secondary to the counterexample engine.

## Distinct thesis

The project is not "manage data contracts". Its thesis is:

> A compatibility claim should fail with one minimal payload that proves the old and new accepted-value sets differ.

That witness-first angle is the acceptance-facing distinction to preserve in README, proposal, demos and future feature work.