Four Pillars of Prompting: Priming, Organized Data, Domain Knowledge, and Order of Operations

Most prompt engineering advice is a list of adjectives: be clear, be specific, give examples. Useful, but it stops where the work actually starts. This post is the opposite — a breakdown of four concrete prompting methods observed across a six-month Claude session that built the Behavioral Intelligence Lab, a set of card-based webpages grounded in real psychology, and a game NPC system. Each method removes a different kind of ambiguity before generation begins. Together they are why a 211-proposition Neoplatonist mapping, an 81-chapter Tao Te Ching deck, and a 71-principle Carnegie flashcard set all came out consistent enough to ship.

The failure mode this avoids

The single most common way a large generative task goes wrong is also the most obvious one: a single big, underspecified request forces the model to simultaneously invent structure, content, and style with no prior anchoring. That is exactly where quality degrades fastest. The model is not failing at writing — it is failing at deciding. Every decision it has to make mid-generation is a chance to drift, contradict an earlier choice, or produce the confident-but-hollow invention that shows up when a model is asked to originate a whole taxonomy on the spot.

The four pillars below are not personality traits of a good prompter. They are four distinct decision-removal operations. Each one front-loads a class of decisions that would otherwise leak into generation time, where they are expensive and error-prone.

1. Priming

Priming is the practice of establishing a template once, then invoking it by reference. After the first few card-based builds — Behavioral Science, Emotions, 48 Laws — the full interaction pattern never had to be re-specified again. A prompt like "use the same card format" or "use any other common elements we created for our other card webpages you think apply" inherited flip-cards, cross-links, modals, search, and flashcard mode without re-describing any of it. The cost of specifying the pattern was paid once; every subsequent invocation was cheap.

There are three sub-moves that make priming work, and they compound:

The Proclus example is worth pausing on. The Proclus Latent Space page maps 211 propositions from Proclus's Elements of Theology onto modern computing concepts. Instead of defining a mapping table for all 211 propositions up front, the session gave one concrete pairing — "how the concept of Angels is similar to a Kernel" — and let the model infer the intended style of every other mapping from that single instance. That is priming by example, not by exhaustive specification: one well-chosen data point did the work of a 200-row spec.

Visually, priming looks like a tree where the root is the first fully-specified build and every later build inherits a subset of its components without re-specifying them:

2. Organized Data

Organized data means specifying the schema before the content. Nearly every card-based build in the session started with a structural spec — number, name, statement, summary, category, cross-links — then a defined front/back split (e.g., "front = summary, back = Modern Translation"). This is effectively defining a data model up front. Once the schema is fixed, generation becomes a fill-in-the-structure task rather than an open-ended one, which is a much easier and more consistent problem for a model to solve well at scale: 211 Proclus propositions, 81 Tao Te Ching chapters, 71 Carnegie principles.

{
  "number":   int,          // canonical index in the source
  "name":     string,       // short title
  "statement":string,       // the proposition / law / chapter line
  "summary":  string,       // plain-language front of card
  "category": string,       // grouping for filtering
  "cross":    [string],     // links to related cards
  "back":     string        // "Modern Translation" / application
}

The NPC Persona Builder request went further than "make it structured" — it decomposed personality into discrete, addressable fields and specified how the structure should causally influence behavior:

persona = {
  mbti:        "INTJ",            // 16-type frame
  emotions:    { anger: 0.8, joy: 0.2, ... },   // Plutchik weights
  biases:      [ "anchoring", "confirmation" ], // checkbox-selected
  carnegie:    [ "smile", "remember_names" ],   // checkbox-selected
}
// causal rule supplied with the schema, not invented later:
//   if quick to anger (anger weight high),
//   behavior shifts when interactions contain angry language

That last part is the key. It was not just "make it structured"; it was "make it structured and tell me how the structure should causally influence behavior." That turned a vague trait system into an actual mechanism that could be wired into game logic.

CSV was the connective tissue that let tools interoperate without a shared codebase. Asking for CSV export/import specifically — rather than "save the data somehow" — gave both the Persona Builder and the game a shared, inspectable, portable data contract.

3. Domain Knowledge

Domain knowledge means grounding generative work in real external taxonomies rather than invented ones. Plutchik's emotion wheel, MBTI, established cognitive bias literature, Robert Greene's Laws, Carnegie's actual books, a real ethics glossary, Proclus's actual propositions, the Tao Te Ching's actual chapter structure — none of this was invented wholesale. Every "creative" system (the game NPCs, the Convergence cross-reference page) was built by recombining pre-existing, well-documented domain knowledge rather than asking the model to generate personality theory from scratch.

This matters because grounded domain knowledge is far less prone to drift, internal contradiction, or the confident-but-hollow invention that shows up when a model is asked to originate a whole taxonomy on the spot. The taxonomies used across the Lab, with their canonical sources, are:

Domain knowledge also functioned as a check, not just a seed. When the initial worry-principles content turned out not to match the actual Carnegie course material, the session did not let it slide — it supplied the correct source PDF and had the section rebuilt. That is domain knowledge verifying output against ground truth rather than assuming the first pass was faithful to the source.

4. Order of Operations

This is probably the most consequential and least obvious pattern in the whole session, so it is worth spelling out as a sequence. The build order was not arbitrary — it was a dependency graph executed in topological order.

Expressed as pseudocode, the order of operations is a dependency-respecting build loop:

# 1. Isolated systems first — each small enough to validate alone
for system in [behavioral, emotions, personality, ethics, laws, carnegie]:
    build(system)          # bounded scope, get it right
    validate(system)       # check against source taxonomy
    lock_schema(system)    # freeze the data model

# 2. Refine the interaction pattern by repetition, not by mega-spec
pattern = flip_card + modal + cross_link + search
for build_n in range(2, N):
    inherit(pattern)       # carry forward what worked
    add_one_feature(build_n)  # test one new capability on a bounded task

# 3. Synthesis only after dependencies exist
for synthesis in [game, convergence, persona_builder]:
    deps = required_systems(synthesis)   # e.g. game needs emotion+personality+bias+carnegie
    assert all(built(d) for d in deps)   # do NOT synthesize before deps exist
    build(synthesis)

# 4. Extend incrementally; never rewrite a working base
for feature in [csv_import, rumors, persistent_memory]:
    extend(thornhaven, feature)   # discrete, independently specified

# 5. Bug reports late, specific, falsifiable
for bug in stress_test(system):
    report(bug)            # "cards with the star don't flip" — not "it's broken"
    fix(bug)
    retest(bug)            # "still broken" if the fix missed → narrow the scope

The dependency graph itself is what makes the order non-obvious. Synthesis tasks sit at the top of a DAG whose leaves are the isolated taxonomies; you cannot build the root before the leaves exist.

Why this combination works

The through-line across all four pillars is that each one removes a different kind of ambiguity before generation starts. None of them is about being polite or verbose. They are four distinct constraint-injection operations:

The failure mode this avoids is the one where a single large, underspecified request forces a model to simultaneously invent structure, content, and style with no prior anchoring — which is exactly where quality degrades fastest. This approach instead front-loads every decision that can be front-loaded, and reserves open-ended judgment calls (aesthetic direction, "use elements you think apply") for the moments where creative latitude is actually the point, not a gap being papered over.

The build sequence, as it happened

Related

Caveats and limitations

Verified from source. The four pillars and their definitions are taken directly from a Claude session transcript used to build the Behavioral Intelligence Lab. The canonical sources cited in the taxonomy table are verified: Plutchik's Emotion: A Psychoevolutionary Synthesis (Harper & Row, 1980); Proclus's Elements of Theology as edited by E. R. Dodds (Oxford, 1963; 2nd ed. 1992), comprising 211 propositions; Carnegie's How to Win Friends and Influence People (Simon & Schuster, 1936); Greene's The 48 Laws of Power (Viking, 1998); the Tao Te Ching's 81-chapter received structure (Wang Bi recension), with the Guodian bamboo slips (ca. 300 BCE) as the earliest extant manuscript witness; and the MBTI, originating with Katharine Cook Briggs and Isabel Briggs Myers (1944 handbook; first published by the Educational Testing Service in 1962).

Interpretation / argument. The framing of the four pillars as "ambiguity-removal operations" and the claim that each removes a distinct class of ambiguity (register, structural, factual, scope) is this post's thesis, not a claim from the original session. The session described the methods; the ambiguity-removal taxonomy is an extrapolation offered here as a way to generalize the pattern. The pseudocode in the Order of Operations section is an illustrative reconstruction of the build sequence, not a literal script that was run.

On MBTI specifically. The MBTI is used in the Lab as a personality frame for NPC design, not as a psychometric endorsement. The MBTI has been widely criticized in the psychology literature for its adherence to type theory and perceived lack of psychometric support; it is included here because it was part of the source session's attribute vocabulary, not because it is the strongest available personality model. A production system might substitute a Big Five / OCEAN model instead.

Counts. "11 Lab pages live" reflects the pages live on lab.catgameresearch.net at the time of writing; the Lab is an active project and the count may change. "200+ Proclus propositions" refers to the 211 propositions in the received Dodds edition; the Latent Space page maps a working subset. "71 Carnegie principles" and "81 Tao Te Ching chapters" are the counts used in the source session's flashcard builds.