HTP Projective-Analysis Toy Example

v2026.07.1 reviewed by Torsten 2026-07-18, as good as this can be at this stage. Genuinely new territory; still needs real scoping with this collaborator before it's a design, and says so throughout on purpose. Tracked as sail-lspf.

This chapter doubles as the first real capture of this thread, not a synthesis of already-written material — no prior bean or draft covered it before this compendium.

Honest framing

This collaborator wasn’t part of the AIDLE proposal, but offered help back then and has now asked again about joint work. Same honesty standard as the EEG/fMRI chapter: nothing here is scoped yet, let alone running.

The toy example

The idea discussed: House-Tree-Person (HTP) data — studies, images — mined as a candidate source for grounding sail-judge’s arm design, the same way learning-science literature grounds the current arms (sail-wqs3) and Wood/Bruner/Ross grounds the discourse-driver role. The simple intuition behind it: arms informed by projective analysis (Hammer’s HTP framework), trigger and reward informed by EEG — deliberately the same physiological-grounding idea as the previous chapter, not a second, unrelated one.

What HTP actually is, said plainly

The House-Tree-Person technique (Buck’s original test, John Hammer’s later handbook) is a decades-old projective psychological assessment: a subject draws a house, a tree, and a person, and a clinician interprets features of the drawings — size, placement, line quality, omissions, distortions — as projections of personality or emotional state. Worth naming honestly, the same way this compendium names Goodhart risk in cheap reward proxies (sail-wqs3’s taxonomy) rather than presenting a method as if it were obviously sound: HTP’s psychometric validity is genuinely disputed in mainstream clinical psychology, in the same family of long-standing criticism as the Rorschach — inter-rater reliability and predictive validity have been real, recurring points of contention, not a settled matter. That matters directly here, not just as a caveat: an arm scored against an HTP-derived rubric risks encoding a contested clinical framework’s assumptions as validated ground truth, which is structurally the same failure this compendium already flags for cheap regex heuristics and LLM-judges elsewhere (bandit-arms-gat chapter) — a plausible-looking proxy standing in for a real construct nobody has actually verified it tracks. Any real design here would need to treat HTP-derived signal as another candidate proxy to validate, not a shortcut around validating.

A concrete connection to the previous chapter, not just a juxtaposition

The two neuroscience threads in this compendium aren’t only similar in spirit — there’s an actual, buildable connection between them. HTP’s own task structure (draw a house; draw a tree; draw a person) is naturally three discrete, prompted trials, which maps unusually well onto BrainWaves’ existing Custom-experiment builder (the previous chapter): named stimulus/prompt conditions, a bounded duration per trial, the same Collect → Clean → Analyze pipeline. Rather than inventing new EEG tooling for this idea, the honest first question is whether an HTP-style three-condition drawing task could just be built as another BrainWaves Custom design — reusing real, already-built infrastructure instead of starting from nothing, the same move the rest of this project makes whenever possible (2026-07-11-tech-synthesis-reusable-assets.md’s whole premise). Not attempted; a real, concrete next step if this ever gets picked up.

Before drafting further: this needs actual scoping

The raw note behind this chapter is an intuition, not yet a design. Before any of the above becomes more than a compendium chapter:

• What HTP datasets actually exist and are accessible — de-identified drawing corpora, published coding manuals, anything usable at all — hasn’t been checked. This chapter doesn’t cite one because none has been found yet, not because it wasn’t worth mentioning.
• What “mining HTP data for the SAIL judge” would concretely mean is still open: candidate framings include treating specific HTP coding categories (from Buck’s or Hammer’s manuals) as hypotheses for new arm constructs, the same way generation-effect or retrieval-practice were adopted as constructs — but nothing has been checked against real data, and given the validity concerns above, any such mapping would need real scrutiny before it went anywhere near live code.
• This hasn’t been discussed with this collaborator in any concrete form yet — the toy example is real, the design isn’t. Filing a follow-up scoping bean once there’s an actual conversation to build on is the right next step, not inventing design detail here first.

Open questions

• Does any accessible, appropriately-consented HTP dataset actually exist to check anything against?
• Is HTP’s contested validity a dealbreaker for using it as arm-design grounding at all, or is there a narrower, more defensible slice of it (e.g. purely structural/compositional features, not full clinical interpretation) worth separating out?
• If the BrainWaves-as-drawing-task connection above is real, does it need EEG at all for a first pass, or would it be worth trying the drawing-task/arm-mapping question on its own first, EEG added later?