Name your systems as archetypes, not machinery

TL;DR

Names shape thought. In a complex system the name is the unit of reasoning: it stands in for behavior, purpose, and relationships everywhere the system is actually discussed — which is mostly in sentences, design docs, and incident channels, not in code. So name the long-lived cast of your architecture as archetypes — a Sentinel that oversees sessions, a Seer that reads signals for foresight, an Oracle that divines truth from the system’s depths — not as machinery (Rule Engine, Data Collector, Decision Service). A vivid name is a working mental model and a design constraint: it encodes what the component is for, what temperament it has, and what it would never do — and it keeps you honest, because every system must live up to its character. Scope the practice deliberately: archetypes for the durable systems with real agency, plain descriptive names for plumbing — and write the cast list down (ZFN-1) so the mythology is a shared language, not an in-group dialect.

Context

Naming is famously one of the two hard thingsTwoHardThings — martinfowler.comPhil Karlton's famous line — "There are only two hard things in Computer Science: cache invalidation and naming things" — and its variations. Naming is hard because it is design, not labelling.martinfowler.com ↗ — and it’s hard because it isn’t labelling, it’s design. A name is the compression format for everything you know about a component: say it, and the listener decompresses behavior, boundaries, and relationships. Most architectural reasoning happens at exactly that altitude — “send this through X before we ask Y” — so the quality of the names bounds the quality of the conversation.

The default drift, especially in serious domains — fraud, abuse, risk, trust — is toward bureaucratic language: Rule Engine, Data Collector, Decision Service. Those names feel safe and professional, and they flatten everything that matters. They’re interchangeable; they describe mechanism, not purpose; and they hide the human truth that these systems see, think, and judge. A Decision Service sounds like it computes a value. What it actually does is pass judgment on a person. A sterile name lets you forget that; a name with weight doesn’t.

Take a fraud-and-abuse stack as the example, with human and mythic names for its components instead of sterile technical ones. The names aren’t branding — they’re semantic shorthand for intent and behavior; each embodies a role, a temperament, and a relationship:

• A Sentinel doesn’t handle requests — it oversees sessions, maintains order, and guards continuity.
• A Seer doesn’t score inputs — it interprets signals and offers foresight through patterns.
• An Oracle doesn’t query data sources — it consults the depths of the system to divine truth from complexity.

This is the system-level version of DDD’s ubiquitous languageDomain-Driven Design — Eric EvansEvans's book introduces the 'ubiquitous language': a shared, rigorous vocabulary developed between engineers and the domain, used identically in conversation, documents, and code — because the language is the model.domainlanguage.com ↗: the words you use in conversation are the model, so choose words that carry the model’s full weight. It’s also kin to the case for cutesy project namesName your projects cutesy things — Nicole Tietz-SokolskayaA case for giving projects whimsical names instead of dry descriptive ones: a real name gives the work an identity people remember and rally around, and renaming later is cheap.ntietz.com ↗ — a real name gives work an identity — but the point here is stronger than memorability: the name is doing architectural work.

Recommendation

Give the durable cast of your architecture names with character — and hold each system to its character.

• Name the cast, not the plumbing. Archetypes are for the long-lived systems with genuine agency — the ones that see, decide, and act, and that people will discuss for years. A string formatter, a retry helper, an internal library: plain descriptive names. Mythologizing everything devalues the names that matter.
• Pick names that encode role, temperament, and boundary. The test of a good name is that it tells you what the system would never do. A Sentinel doesn’t predict; a Seer doesn’t enforce. If the name can’t draw that line, it’s a label, not a model.
• Use the name as a design constraint. When a proposed feature feels wrong for the character — asking the Seer to block traffic, asking the Sentinel to do statistics — treat that as a real architectural smell, not a poetry problem. Either the feature belongs elsewhere, or the system is quietly becoming two systems. A name with weight makes that drift visible early, and makes it harder to design carelessly (ZFN-41 — names, like choices, carry accountability).
• Design as collaboration, not wiring. Naming systems as characters in an ecosystem reframes the design question from “how do these components connect” to “how do these beings collaborate” — which is the right altitude, because it forces you to think in responsibilities, trust, and limits rather than in arrows between boxes.
• Stay in one register. Pick a mythology — or at least a coherent voice — and keep new names inside it. A cast assembled from three unrelated fandoms reads as noise; coherence is what turns names into a shared language.
• Write the cast list down. One page: name → role → temperament → what it never does. Keep it where your decision records live (ZFN-1) and hand it to every newcomer on day one. The lexicon is what separates a shared mythology from an in-group dialect.
• Rename when the character no longer fits. Systems evolve. When the Sentinel has grown a second unrelated job, either split it or rename it — a name that no longer tells the truth is worse than a sterile one, because it actively misleads.

Consequences

Easier:

• Conversations compress: one sentence of cast-language carries what would otherwise need a diagram — behavior, hierarchy, and responsibility encoded in the names themselves.
• Misfit features become visible early — “that’s not the Seer’s job” is an architectural review you can run in your head, before any code exists.
• The systems that exercise judgment are named as things that judge, which keeps design and review honest about what’s really being built.
• Over time the cast becomes shared culture — a mythology that binds the team to its values, gives the work identity, and makes the architecture genuinely memorable.

Harder — and honestly:

• Every newcomer pays an onboarding tax. “Seer” tells you nothing until someone tells you. Without the written cast list this practice degrades into an in-group dialect that excludes exactly the people you most need to bring in.
• Discoverability suffers. Nobody searching for “fraud scoring” finds the Seer. The lexicon, repo descriptions, and doc titles have to bridge archetype names to plain-language function, deliberately.
• Cuteness is a real failure mode. Names chosen to be clever rather than true are branding, not modelling. The name serves the mental model — if you’re picking names for the joke, you’ve inverted it.
• Names ossify. A character that quietly outgrew its role misleads everyone who trusts the name. Renaming is awkward and has migration cost, and you have to pay it anyway.
• Archetype names are internal shorthand. In external, legal, or customer-facing contexts you’ll still need plain descriptions of what each system does — the mythology doesn’t excuse you from explaining judgment systems in human terms.

New obligations:

• Maintain the cast list as a living document; it’s part of the architecture, not decoration.
• Treat names as reviewable interfaces: new names go through design review, and renames happen when the character changes.

References

• Name your projects cutesy thingsName your projects cutesy things — Nicole Tietz-SokolskayaA case for giving projects whimsical names instead of dry descriptive ones: a real name gives the work an identity people remember and rally around, and renaming later is cheap.ntietz.com ↗ — the adjacent case for real names over descriptive ones; this note pushes it further: the name does architectural work.
• TwoHardThingsTwoHardThings — martinfowler.comPhil Karlton's famous line — "There are only two hard things in Computer Science: cache invalidation and naming things" — and its variations. Naming is hard because it is design, not labelling.martinfowler.com ↗ — naming is hard because it’s design, not labelling.
• Domain-Driven DesignDomain-Driven Design — Eric EvansEvans's book introduces the 'ubiquitous language': a shared, rigorous vocabulary developed between engineers and the domain, used identically in conversation, documents, and code — because the language is the model.domainlanguage.com ↗ — ubiquitous language: the words you reason in are the model.
• ZFN-1 — where the cast list lives: legible, durable records the next person inherits.
• ZFN-41 — names, like technical choices, carry accountability; weight is the point.

Changelog

• 2026-06-12: First published as a Field Note.