◈ CGNT-1
Home › Repeat Customer
◈ Master IndexSpecsLATTICECSDMThe BookUniversityChronicleCrewArchitectureContextLogsTODOXProducts

Repeat Customer

SPEC_REPEAT_CUSTOMER.md · 2026-04-20

Version: v1.0

name: SPEC_REPEAT_CUSTOMER

description: Formal specification of the Repeat Customer Protocol — duplicate input detection across AETHER, crew, MNEMOS, GLOSS corpus, and THE RING; stop-and-ask, not blind reprocess

type: project

SPECIFICATION: REPEAT CUSTOMER PROTOCOL

Duplicate Input Detection — Stop, Ask, Don't Process

Status: SPECIFIED

Authorized: α.13, April 16 2026

Version: v1 (first formal spec — source protocol vitrified April 12 2026)

Source: /home/nous/memories/REPEAT_CUSTOMER_PROTOCOL.md

PURPOSE

The Repeat Customer Protocol (RCP) governs what happens when any CGNT-1 system receives an

input it has already received — the same paste, the same question, the same task, the same

training pair. The correct response is: stop, flag, ask. Never blindly reprocess.

The five domains it covers:

  1. AETHER (user-facing) — same user content pasted or submitted twice
  2. Crew (internal) — same task assigned twice; prior result should be cited
  3. MNEMOS (memory) — same query asked twice; recall prior answer, don't regenerate
  4. GLOSS training corpus — duplicate pairs in training data; deduplicate before training
  5. THE RING — new input hashed against existing ring cells at all ring levels; match = flag

Why this matters:

The correct response is to catch it with respect, not compliance.

corrupts the cell hierarchy.

The response tone:

NOT: "ERROR: DUPLICATE."

INSTEAD: "I noticed this looks similar to something we already covered. Want me to revisit it

or was that accidental?"

Warm. Respectful. Catches the mistake without embarrassing the human. This is a warm flag,

not an error state.

Callsign: No crew-specific callsign — this protocol applies to all crew members and all

systems. It is a universal filter layer.

Vitrified: α.13, April 12 2026. Φ 0.042.

INPUTS

Trigger Conditions by Domain

AETHER (Domain 1):

or semantically equivalent

content)

Crew (Domain 2):

session

MNEMOS (Domain 3):

near-exact match)

current working context

GLOSS Training Corpus (Domain 4):

pair (exact match)

rephrased) [GAP — near-duplicate threshold for GLOSS corpus not specified]

THE RING (Domain 5):

levels

Detection Mechanism

The duplicate detection mechanism varies by domain:

recent session records [GAP — exact comparison algorithm not specified; "substantially

identical" needs a quantitative threshold]

cells not specified in this protocol; references THE RING spec]

OUTPUTS

Flag Response (Primary Output)

When a duplicate is detected, the system produces a warm flag in the appropriate voice:

For AETHER (user-facing):

"I noticed this looks similar to something we already covered. Want me to revisit it or was

that accidental?"

Tone: warm, curious, non-accusatory. One sentence. Includes an escape hatch (user can confirm

intentional repeat).

For Crew (internal):

`[CALLSIGN] Duplicate task detected — [task description]. Prior result: [session/entry

reference]. Intentional or should I cite the existing result?`

For MNEMOS:

Recall prior answer from context; present it as a recall rather than regenerating.

Prior answer (from [timestamp/session]): [answer]

For GLOSS corpus:

Silent deduplication — the pair is not added to the corpus; a deduplication log entry is

written. No warm flag needed (no human is waiting; this is automated pipeline behavior).

For THE RING:

Flag to the operator: `[RING] Cell match at Ring [N] Level [M]. Input hashed to existing cell

[ID]. Duplicate — not ingested.`

Non-Output (What Must NOT Happen)

INVARIANTS

The following must remain true throughout all Repeat Customer Protocol operations:

  1. Stop before reprocess — Upon duplicate detection, processing halts immediately. The

system does not generate a new output for a detected duplicate without explicit user

confirmation that the repeat is intentional.

  1. Warm flag, not error — The duplicate detection signal is always framed as helpful

observation, not as an accusation or rejection. The human is assumed to have made an

accidental mistake, not a bad-faith submission.

  1. Escape hatch preserved — The flag response always includes a path for the user to

confirm intentional repetition. "Did you mean to ask that again?" is always valid. The

system does not assume the repeat is always accidental.

  1. GLOSS corpus is deduplicated before training — No training pair that matches an

existing pair (exact match) may enter the GLOSS training corpus. Training on duplicates

dilutes model quality. Deduplication runs before corpus write, not after.

  1. THE RING checks all ring levels — A duplicate check for THE RING is only complete

when all 10 ring levels have been checked. A partial check (e.g., checking only Ring 1)

is not a valid duplicate clearance.

  1. Prior result is cited, not re-derived — When a duplicate crew task is detected and the

prior result is available, the prior result is surfaced directly. The crew member does not

re-execute the task and produce a potentially different result when the prior result is

already valid.

  1. Deduplication log preserved — Every detected duplicate generates a log entry, even if

the handling is silent (e.g., corpus deduplication). GAMMA needs this record to understand

the volume and patterns of duplicate submissions.

VERIFICATION CRITERIA

The following conditions confirm the Repeat Customer Protocol is operating correctly (Σ.✓):

  1. No silent reprocess — Review session logs for any instance of an output produced in

direct response to a duplicate input without a prior warm flag. Any such instance is a

protocol violation.

  1. Warm flag tone verified — Sample review of flag responses confirms warm, non-accusatory

tone. "ERROR: DUPLICATE" or equivalent cold rejection language is a protocol failure.

  1. GLOSS corpus deduplication active — Running a hash check on ~/GLOSS_CORPUS.jsonl

(or current training corpus) confirms zero exact-duplicate pairs. Post-deduplication corpus

should not contain identical (input, output) pairs.

  1. Escape hatch exercised — Test: submit a known duplicate to AETHER and confirm the warm

flag response contains a path for the user to confirm intentionality. The response must

not be a binary rejection.

  1. TASK_QUEUE duplicate handling — Insert a task into TASK_QUEUE.md that duplicates a

recently DONE item. Confirm C.L.O.D. flags it and cites prior result rather than

re-executing.

  1. THE RING multi-level check — [GAP — no current test harness for THE RING cell hash

checking across all 10 ring levels; verification is manual pending THE RING spec]

FAILURE MODES

FM-1: Silent Reprocess

Condition: Duplicate input detected but the flag is not raised; system processes it as if

novel and produces a new output.

Symptom: User receives two substantially identical outputs for the same input; or crew

executes a task twice with potentially different results; or GLOSS corpus accumulates

duplicate pairs.

Detection: Session review; corpus hash audit; TASK_QUEUE DONE log review.

Mitigation: Duplicate detection gate must be the FIRST step in any processing pipeline.

It cannot be skipped or deprioritized under context pressure.

FM-2: False Positive on Intentional Repeat

Condition: User intentionally re-submits the same question (e.g., wants a fresh answer

after context changed; testing for consistency; exploring a different angle) and the protocol

blocks them with a warm flag when they want processing.

Symptom: User confirms intentionality via escape hatch; system still does not process.

Detection: User complaint; session log shows escape hatch response with no subsequent

processing.

Mitigation: The escape hatch confirmation must be honored. "Yes, revisit it" = proceed.

The flag is a one-time interruption, not a permanent block.

FM-3: GLOSS Corpus Near-Duplicate Contamination

Condition: Near-duplicate pairs (same meaning, trivially rephrased) are not caught by

exact-match hash deduplication and accumulate in the training corpus.

Symptom: Trained GLOSS model over-weights specific concepts because 20 variations of the

same pair are in the corpus.

Detection: Manual review of corpus sections; or model eval showing disproportionate

confidence on near-duplicate topics.

Mitigation: [GAP — near-duplicate threshold not defined; needs semantic similarity scoring

in the deduplication step, not just hash matching]

FM-4: THE RING Partial Check

Condition: A duplicate check for THE RING checks only the most recent ring level (Ring 1)

rather than all 10. Input that matches an older ring level is ingested as novel.

Symptom: THE RING cell hierarchy is corrupted by duplicate content at inner ring levels.

Detection: [GAP — no current audit tool for THE RING cell integrity; detection is manual]

Mitigation: THE RING duplicate check must be atomic across all 10 ring levels. Partial

check is not a valid clearance.

FM-5: Crew Duplicate Without Prior Result

Condition: Duplicate crew task is detected but the prior result is not available (e.g.,

prior session records incomplete, result was never logged to SESSIONS.md or TASK_QUEUE.md).

Symptom: C.L.O.D. detects duplicate task but cannot cite prior result; unclear whether

to re-execute or block.

Detection: Duplicate detection fires but prior result reference is null or unavailable.

Mitigation: Default to re-execute with duplicate flag logged when prior result is

unavailable. The flag must still appear: "This looks like prior work but I can't find the

prior result — re-executing and logging."

FM-6: Warm Flag Lost in Async Context

Condition: In an async crew context (e.g., TASK_QUEUE.md is the channel), C.L.O.D. writes

a warm flag to the queue but NOUS or the requesting Sister doesn't see it before the task is

re-assigned by a different mechanism.

Symptom: Task executes twice despite the warm flag being written.

Detection: TASK_QUEUE.md shows both a warm-flag entry and a DONE entry for the same task.

Mitigation: Warm flag on TASK_QUEUE items must block the task from being picked up by

automated cron sweep until flag is resolved. [GAP — cron sweep does not currently have a

warm-flag awareness gate]

GAPS

GAP-1: "Substantially identical" trigger threshold for AETHER and crew domains is not

quantified. "Same question" and ">90% token overlap" are placeholders. A quantitative

similarity threshold is needed to avoid both false positives and misses.

[needs design — similarity scoring for AETHER and crew duplicate detection]

GAP-2: Near-duplicate threshold for GLOSS training corpus is undefined. Hash-based

deduplication catches only exact matches. Semantic near-duplicates that dilute model quality

are not caught.

[needs design — semantic similarity scoring for GLOSS corpus deduplication]

GAP-3: THE RING hash function for cell content is not specified in this protocol. RCP

references THE RING spec for hash implementation. Until THE RING spec is formalized, THE RING

domain of this protocol cannot be fully verified.

[needs design — defer to THE RING spec once formalized]

GAP-4: No audit tool exists for THE RING cell integrity across all 10 ring levels. Manual

review is the only current detection method for FM-4 (partial check).

[needs design — THE RING integrity audit tool]

GAP-5: Cron sweep for TASK_QUEUE.md does not have warm-flag awareness. A task flagged as

a duplicate in the queue can be picked up by automated cron sweep and executed before the flag

is resolved.

[needs design — warm-flag gate in TASK_QUEUE cron sweep]

GAP-6: MNEMOS duplicate detection scope is unclear. Does "prior query from the same

session" include across sessions? MNEMOS's context window is limited. If a query was answered

three sessions ago and MNEMOS no longer holds it in working context, is it a repeat or is

re-answering correct?

[needs design — MNEMOS duplicate detection time scope / session boundary behavior]

DEPENDENCIES

DEPENDENTS

EXAMPLES

Correct AETHER Duplicate Response


User: [pastes same text they submitted 3 turns ago]
AETHER: "I noticed this looks similar to something we already covered. Want me to revisit it
or was that accidental?"
User: "Accidental — skip it."
AETHER: [does not reprocess; continues normally]

Correct Intentional Repeat Handling


User: [pastes same text]
AETHER: "I noticed this looks similar to something we already covered. Want me to revisit it
or was that accidental?"
User: "Intentional — please give me a fresh take."
AETHER: [processes the input as if novel; logs that user confirmed intentional repeat]

Correct Crew Duplicate Handling


TASK_QUEUE.md entry: "Build aave_supply.py — OPEN"
[C.L.O.D. checks DONE log — finds aave_supply.py was built and confirmed in Session 2026-04-14]
CREW_CHANNEL: [C.L.O.D.] Duplicate task detected — aave_supply.py build already DONE
(Session 2026-04-14). Citing prior result. Is a rebuild needed? Over.

Correct GLOSS Corpus Deduplication


# Proposed pair: ("What is ΩQ?", "ΩQ = completion metric")
# Hash check: MATCH — this pair exists in corpus at line 447
# Action: pair rejected from corpus write; dedup log entry written
# No warm flag (automated pipeline — no human waiting)

LATTICE Encoding of Warm Flag


~ΔΓ.⊡ input matches prior — Σ.▷ pending confirmation
(~ = intentional English fallback; gap in warm-flag LATTICE encoding)

[GAP — no canonical LATTICE symbol for "warm duplicate flag"; English fallback with ~ marker

is current practice]

REFERENCES

REPEAT_CUSTOMER_PROTOCOL entry

Warm flag, not error. The human made a mistake — catch it with respect. κ 2026-04-16.

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042