# Duplication check and positioning

Check date: 2026-08-24.

## Similar MoonBit projects found

- `lyjttio/moon-data-contract`: contract model, runtime validation, schema evolution audit, registry/generation, governance, migration/rollback planning, policy gate and Markdown/JSON/JUnit/HTML evidence export.
- `YumeCross/schema`, `mizchi/jsonschema`, `prowk/MoonSchema` and `cosgammmmma/moonschema`: JSON Schema validation, typed configuration 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.
- `QinXi-ai/moonguard`: public API compatibility and semantic-versioning guard for MoonBit package surfaces rather than JSON payload models.
- `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 rollout-list helpers secondary to witness evidence.

EvoWitness deliberately does not provide a schema registry, ownership governance, approval ledger, release gate, JUnit/HTML governance evidence, external ticket automation, binary serialization format, OpenAPI/JSON Schema ingestion, generated client/server code, cross-format exports or a general runtime schema DSL.

## Explicit relation to moon-data-contract

EvoWitness does not extend, wrap or reuse `moon-data-contract`. The relationship is "adjacent but separate":

- `moon-data-contract` is a broad deterministic schema governance package.
- EvoWitness is a narrow witness generator for proving that two versioned payload models accept different JSON values.
- `moon-data-contract` starts from a richer schema/governance model and produces validation, audit, migration and policy evidence.
- EvoWitness starts from two small Evo Contract snippets and produces concrete source-valid/target-invalid payloads plus replay records.
- If a future adapter ever reads `moon-data-contract` output, it should live as a separate integration package with its own license and scope statement.

## 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 explicitly 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, replay and human rollout checklists, 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.