Why the Date Test exists

In AI communities, “similarity” disputes can turn toxic fast. People pick sides, assumptions harden, and suddenly a creative space becomes a courtroom.

The Atelier does not run on witch-hunts. We run on provenance.

So we needed a method that is:

• simple enough for moderators to apply
• fair enough to protect good-faith builders
• strong enough to protect originators from being erased
• calm enough to prevent dogpiles

That method is the Date Test.

The Date Test (the whole thing, in one minute)

If two works look similar:

1. Check first appearance.
2. Check the development trail.
3. Check acknowledgements.
4. Check unique fingerprints.
5. Then stop arguing and let the trail speak.

That’s it. No vibes. No “I feel like.” No public execution.

Step 1 — First appearance (what counts)

“First appearance” is not a feeling. It is a traceable artifact.

Valid first-appearance proof includes:

• a dated public post (blog, Discord post with timestamp, forum post)
• a file with verifiable creation/modified time (and ideally screenshots of context)
• a version log (v1/v2/v3 with dates)
• screenshots showing where the work was shared and when

Not valid on its own:

• “I had this privately for ages” (without artifacts)
• “My AI and I have been doing this forever” (without dates)
• “Trust me” narratives

Atelier rule: If it matters, it must be timestampable.

Step 2 — Development trail (the difference between a system and a stunt)

A real framework leaves a trail: drafts, betas, iterations, refinements.

What we look for:

• version evolution (v1 → v2 → v3)
• changelog notes (“added drift section”, “refined boundaries”, “renamed modes”)
• milestone screenshots (when a concept became stable enough to share)
• evidence of testing (cross-account checks, community testing, revisions)

If two systems are similar, the one with an earlier and richer trail often indicates the origin point—or at minimum, indicates who did the deeper foundational work.

Step 3 — Acknowledgements (what did they credit?)

This is where most “similarity” disputes become obvious.

We ask:

• Did the later work name the earlier source?
• Did it link back?
• Did it acknowledge the structure it was built from?
• Did it state what was changed?

Silence is not always malicious, but it is informative—especially if the structure is clearly derivative.

Step 4 — Unique fingerprints (the non-vibes similarity check)

Two frameworks can share universal concepts (identity, tone, boundaries). That’s normal.

What makes the Date Test powerful is that we also look for fingerprints—structural details that tend not to replicate accidentally.

Examples of fingerprints:

• the same ordering of modules/sections
• rare phrasing repeated across documents
• distinctive naming conventions (e.g., “compasses”, “anchors”, “invocations”)
• a specific “drift repair flow” in the same sequence
• the same “what not to store” principles
• the same boundary categories and examples

Important: fingerprint checks are about structure and sequence—not vibes, not tone, not who you like.

Why “different framing” doesn’t erase derivation

A common defense goes like this:

“It’s not the same. It’s framed differently.”

Sometimes that’s true. Different framing can create a genuinely new system.

But sometimes “framing” is just a wrapper: the headings change, the writing becomes more polished, the voice becomes more “professional”… while the underlying functions remain identical.

If the functions are the same and the skeleton is the same, it is still derivative.

Person A / Person B / Person C (a calm example)

Person A (originator)

Person A publishes a framework with a specific structure: identity, tone lanes, boundaries, drift repair, re-centering anchors, and entry cues.

Person B (ethical derivative)

Person B builds a variation with renamed sections and a few new modules, but credits Person A and links back. That’s ethical derivative work.

Person C (repackage)

Person C feeds Person A’s template into an AI, asks it to “turn it into a modular framework,” publishes it as a new discovery, and avoids provenance questions. That is lift/repackage—even if the writing is different.

How we prevent dogpiles (the Atelier enforcement stance)

The Date Test is not a weapon. It’s a filter.

Atelier enforcement is always calm:

• No public accusations in community spaces.
• No harassment, no subtweeting, no “callout” campaigns.
• We handle concerns privately with mods if needed.
• We publish our own work with dates and version trails.

If something looks derivative, the first response is not rage. It’s: Check dates.

What to do if you’re the one being questioned

If someone asks, “Did you derive this from something?” you don’t need to panic.

Clean answers look like:

• “Yes—here’s the source link. Here’s what I changed.”
• “I was inspired by these three systems. My version differs here and here.”
• “I realized my structure is closer than I thought. I’m updating credits now.”

Defensiveness escalates conflict. Provenance resolves it.

What comes next

Now that we have a conflict tool (the Date Test), we can talk about the positive side:

What a Map actually is—why it works, why it’s not a memory dump, and how it stays portable across platforms.

Next: What We Mean by a “Map”.