How the Ship Name Lab Works
ShipName.net is a brainstorming and comparison tool, not an authority that decides the correct name for a couple or fictional pairing. This page documents the current generation method, scoring rules, and limits so users can judge the results instead of trusting a black box.
Current Engine
The production engine is version 2026.07.29-1. It is deterministic: the same two cleaned inputs and context produce the same ranked candidates. Core generation does not depend on an external language model, account, payment, or upstream service.
The engine accepts two names and a context setting. It normalizes the text, removes punctuation and spaces, creates candidates from multiple source boundaries, removes duplicates, scores every candidate, and returns the strongest results.
Input Handling
- Unicode text is normalized before generation.
- Spaces, punctuation, digits, and symbols are removed from candidate source text.
- Each input must contain at least two letters.
- Inputs are limited to 40 letters.
- The engine preserves material from both inputs in every candidate.
Removing punctuation makes candidate comparison consistent, but it can also remove meaningful styling from a name. Users should restore intentional punctuation after choosing a result.
Candidate Patterns
Assume the inputs are Taylor and Travis.
| Pattern | Construction | Example |
| --- | --- | --- |
| Prefix and suffix | Beginning of one name plus ending of the other | Tay + vis = Tayvis |
| Reverse prefix and suffix | Reverse the source order | Tra + lor = Tralor |
| Shared-letter overlap | Use a matching boundary letter once | Tra + aylor = Traylor |
| Full join | Preserve both complete names as a low-priority fallback | TaylorTravis |
The engine tests several cut points, including vowel-to-consonant transitions and positions near the middle of each input. Full joins receive a scoring penalty because they are usually less compact than a true blend.
Scoring
Scores are internal heuristics used to order candidates, not linguistic facts or quality ratings. The interface shows the component measurements and structural rank instead of labeling a candidate “strong” or “best.” The internal ordering uses these components:
| Component | Weight | What it measures | | --- | ---: | --- | | Source clarity | 40% | Whether a reader can recognize meaningful material from both original names | | Source balance | 20% | Whether the two source fragments contribute similar amounts | | Readability | 20% | Repeated characters, difficult consonant clusters, and excessive length | | Join quality | 5% | Whether the boundary is shared or changes cleanly between vowel and consonant | | Length | 15% | Whether the result is compact enough for a tag, handle, or nickname |
The engine also emits warnings when one input dominates, source fragments are too short, a difficult character run appears, the result is long, or non-Latin pronunciation needs human review.
Context Adjustments
Context changes ranking by a few points after the shared structural score:
| Context | Small preference | | --- | --- | | Couple | Balanced candidates between four and seven characters | | Fandom | Readable candidates no longer than six characters | | Friends | Shared-letter overlaps and playful joins | | Wedding | High source clarity and readability; long results are penalized |
These are transparent tie-break preferences, not separate AI models. They do not check community convention, event privacy, platform availability, or cultural meaning.
Custom Draft Checker
The Name Blend Checker applies a separate deterministic method to any candidate entered by the visitor. It is intended for edited generator results and candidates found or written elsewhere. The checker does not rank or recommend the draft.
It searches the candidate spelling for contiguous fragments that also occur in source A and source B. From the possible matches, it selects a pair that:
- covers as much of the candidate as possible;
- favors a meaningful fragment from the source with the shorter visible contribution;
- favors compact boundaries; and
- permits no more than one shared boundary character.
The reported candidate coverage is the percentage of draft characters covered by the selected traces. Contribution balance compares only the lengths of those two traces. Warnings identify token one-character contributions, untraced text, visible imbalance, long forms, repeated-character runs, Latin consonant clusters, and text that requires language-specific review.
This trace is one possible spelling explanation. It cannot reconstruct the writer's intent, evaluate sound, or establish recognition. A middle fragment can be structurally present while remaining opaque to a new reader.
When the checker is opened from a generated result, the two sources and candidate move once through temporary same-tab session storage and are removed after loading. The visitor may edit the candidate before checking it. After a successful check, the first-party evidence store can receive only the original anonymous run identifier, context, candidate rank, structural-score band, engine version, broad referrer category, and a checked outcome. It does not receive the sources, generated candidate, or edited draft.
Blind Name Test
The Blind Name Test turns one human-review recommendation into a fixed sequence for a visitor's own candidate. The setup records two source names and one candidate in browser memory. The next screen hides both sources while a reader records first-read clarity and guesses two names. Only after those choices does the worksheet reveal the source pair.
The exact comparison normalizes case and punctuation and accepts either source order. It deliberately does not infer nicknames, transliterations, approximate spellings, pronunciation, or intent. A human may judge a near match meaningful even when the narrow exact comparison reports no match.
Custom blind tests are not submitted to the application database and do not count toward the fixed-sample Human Review Study. Anonymous analytics, when configured, receive only the test version, entry path, clarity category, exact-match count, and keep-or-reject category—not the names, candidate, or guesses.
How to Compare Results
Do not choose only by the structural rank. Review the first candidates with four questions:
- Can both people or characters recognize their name in the blend?
- Can a new reader pronounce it without an explanation?
- Is it easy to type and recognize in lowercase?
- Does it have an unintended meaning or established use in the relevant community?
For Sofia + Mateo, Sofateo preserves recognizable material from both names. A result such as SofiaM would technically include both but represent the second name too weakly.
What the Engine Cannot Verify
The engine does not guarantee:
- pronunciation in every language;
- uniqueness on search engines or social platforms;
- trademark, domain, or account availability;
- suitability in every culture or community;
- that the people represented by the name will approve it;
- legal permission to use a person, character, or brand name.
Generated candidates are drafts. Search a public-facing candidate, inspect it in lowercase, and ask a relevant language or fandom community when context matters.
Testing and Changes
The engine has automated tests for ranking, duplicate removal, source representation, punctuation normalization, invalid input, and short-fragment penalties. The public engine regression checks run common, short, long, punctuated, accented, and non-Latin pairs through the production engine with declared software invariants. Those invariants detect code changes; they do not validate human preference or pronunciation.
Engine behavior is versioned. Material scoring changes will update the version and this page. To report a weak or offensive result, send the two inputs, context, returned candidate, and engine version to externalanswer@gmail.com. Do not include unrelated private information.
For practical guidance, see How to Make a Ship Name That Actually Sounds Good and our Editorial Policy.
Last reviewed: July 29, 2026