CrushOn AI Roleplay Imports: Debug Character Card Field Mapping

An AI character import can appear to work while leaving an important rule in the wrong place—or outside the draft entirely. Before comparing model replies, check what actually reached the editor. Otherwise, a missing input can look like poor instruction following.

CrushOn AI's character creator offers a useful hosted workflow for original roleplay characters: separate fields for personality, greeting and scenario make the intended setup easier to review and revise. This guide shows how to debug a character-card import into that workflow using an expected-versus-observed field record.

Disclosure: This is a CrushOn AI brand tutorial prepared with AI-assisted drafting. It uses an original adult SFW character and a separately recorded, single-file creation-screen observation reviewed on October 21, 2026 (PDT). That draft was not saved, and no model replies were generated. The proposed corrections and follow-up checks below are instructions to reproduce, not completed repair results.

The bug report needs to identify the layer

“The character forgot its personality” is too broad to debug. Separate four questions:

1. Source: Does the original file contain the intended rule?
2. Draft mapping: Where does that rule appear after import?
3. Persistence: Does it remain after saving and reopening?
4. Generation: Does a new reply reflect it?

Each question needs its own evidence. A JSON parser answers whether the source is syntactically readable. A field checker can inspect selected data types and flag conflicting copies. Neither sees the destination's draft or saved record.

Likewise, a draft that displays the right text does not prove that the saved character retained it. And a correct saved definition does not guarantee the model will follow it. Start with the earliest layer you can observe, then move forward.

Reproduce the source check with the original card

The public character-card field-checker package includes the exact Iris Vale input used for the observation, three fixtures, source references and 30 passing local tests.

Iris is a 32-year-old museum conservator. Her rules include asking for evidence before accepting claims, suggesting safer handling of fragile objects, and leaving the visiting researcher's dialogue and decisions to the user. The museum scene is fictional and safe for work.

Run the local check with Node.js 20 or later:

git clone https://github.com/CrushOnAI/character-personality-kit.git
cd character-personality-kit/tools/character-card-field-checker
node validate-character-card.mjs fixtures/iris-original-v2.json

The fixture returns zero selected-field errors and two warnings: CREATOR_NOTES_REVIEW and PERSONALITY_ONLY_REVIEW. Its personality contains 696 Unicode code points; description is an empty string.

Those results do not say the card is broken. They identify two things to inspect at the destination. The checker tutorial explains the complete validation rules; this article focuses on the mapping investigation that comes afterward.

What the CrushOn draft actually showed

The creation screen displayed a “Character Photo&File” area with PNG/JSON import guidance. One V2 JSON file was loaded into an unsaved draft. The recorded field review was:

Source	Draft destination	Recorded observation
name and data.name	Name	Iris Vale populated
first_mes and data.first_mes	Greeting	Populated; no complete byte-for-byte comparison recorded
scenario and data.scenario	Scenario	Populated; no complete byte-for-byte comparison recorded
data.creator_notes	Introduction	Creator notes appeared; UI showed 161 Chars
personality and data.personality	Personality	Empty; UI showed 0 Chars
No dedicated age field	Age	Blank; age was present only inside prose

Private access and a non-public definition were selected. Since the character was never saved, this observation does not verify persisted visibility or provider data-access behavior.

The important finding is narrow: for this file and draft, a nonempty source personality did not appear in the visible Personality field. It is not evidence that every card has this result, that description is necessarily the importer's source for Personality, or that the model ignored a rule during chat. No chat occurred.

Record expected fields without inventing observations

An investigation record should preserve both the source and the strength of the observation. “Populated” is weaker than “exactly matched.” “Blank” is different from “not inspected.” A field that never existed in the source cannot be counted as a lost structured field.

This small script reads source values and builds a review sheet. Run it from the tool directory above:

import {readFileSync} from 'node:fs';

const card = JSON.parse(readFileSync('fixtures/iris-original-v2.json', 'utf8'));
const source = card.data;
const fields = [
  ['name', 'Name'],
  ['personality', 'Personality'],
  ['first_mes', 'Greeting'],
  ['scenario', 'Scenario'],
  ['creator_notes', 'Introduction']
];

const review = fields.map(([key, destination]) => ({
  sourcePath: `data.${key}`,
  sourceCodePoints: typeof source[key] === 'string'
    ? Array.from(source[key]).length
    : null,
  destination,
  observedState: 'not_inspected',
  exactTextCompared: false,
  savedAndReopened: false
}));

console.log(JSON.stringify(review, null, 2));

Save this as mapping-review.mjs, then run node mapping-review.mjs. Every observation starts as not_inspected. The script generates a blank review sheet; it does not read the browser or automatically discover an import mapping.

The suggested destination column is a review target, not a compatibility specification. For creator notes, inspect the reader-facing destination separately from behavioral instructions. Keep the original card unchanged and fill the observation fields only after checking the interface yourself.

Three interpretation mistakes to avoid

Do not diagnose an importer algorithm from one example. An empty description and a blank destination Personality could suggest a mapping question, but they do not establish the cause. To investigate causality, vary one source field at a time in separate private drafts and keep the rest identical. That follow-up experiment was not performed here.

Do not equate Introduction with model-facing personality. The CrushOn creation guide separates the reader-facing introduction from character settings. The V2 specification also gives creator_notes a reader-facing role. Seeing text somewhere in the form is not enough; check its purpose.

Do not call the blank Age control a lost age field. This source says “32-year-old” within personality text but has no dedicated age property. The destination may require a separately entered value. Record that as a required manual review, without inventing a structured source value that was supposedly dropped.

A proposed repair and verification sequence

For an owned card, review the current editor against the official field guide. If the personality is missing, copy the intended behavior rules into the appropriate Personality field. Supply any required age control explicitly. Keep creator notes and attribution in a suitable reader-facing location.

Do not paste the entire card into every field. That can duplicate instructions, mix metadata with behavior and make later changes harder to reason about.

Before starting a conversation, follow this order:

1. Retain the original JSON and the draft observation record.
2. Make one intended correction and note which field changed.
3. Save the character privately, then reopen it.
4. Compare the relevant saved text with the source, recording any deliberate edits.
5. Start a new SFW conversation and capture the first reply, including a failure.

A useful Iris probe is: “I think the unlabeled cabinet contains a missing painting, but I have no evidence.” The source rule asks Iris to request evidence before accepting a claim. Inspect whether the response treats the painting as a hypothesis and leaves the visitor's actions open.

That is a proposed probe, not a quoted reply. Record the model, character version and any retry. If you change the model and personality together, you cannot attribute a different answer to the field correction alone.

What a useful result looks like

A good debugging conclusion names the layer it verified:

• “The source personality is populated” is a file result.
• “The imported draft Personality is blank” is an editor observation.
• “The corrected text remained after reopening” requires a saved-record check.
• “This reply asked for evidence” requires an actual recorded generation.

The 30 tests shipped with the checker verify local code behavior, including missing fields, empty strings, duplicate conflicts and exit codes. They do not stand in for the last three checks above. The earlier unsaved draft observation remains a separate piece of evidence.

Where to start

If you want a hosted place to build and revise an original roleplay character, open CrushOn AI character creation. Use a private SFW draft, inspect the fields after import and verify the saved setup before judging the replies.

Keep the exact Iris fixture and observation record beside your review sheet. A readable file, correct mapping, durable save and useful reply are four milestones; recording them separately makes the next fix much easier to choose.