Design Taste: Engineering Framework
Taste is a control system that converts stochastic model output into reliable user outcomes with minimal correction cost. It is not subjective preference — it has measurable proxies, diagnosable failure modes, and an engineering protocol.
Two modes:
- Audit — score an existing UI, product, or generated output against the Three Pillars
- Design — apply taste principles when building new features or interfaces
Iron law: Taste must remain subordinate to function. The moment the system's correction vector dominates the user's intent vector, the product crosses from high-fidelity to high-friction.
The Three Pillars
Every generative AI product sits in a 3-dimensional taste space. Score each pillar independently.
| Pillar |
What It Measures |
Control Knobs |
Bad Signal |
| Deterministic-Stochastic Balance |
Where entropy is injected in the pipeline — where the system is creative vs reproducible |
Entropy budgeting across phases, multi-sample + rerank, structured outputs (schema), tool calls as determinism anchors |
User says "why did it change?" or fights the AI's personality |
| Interaction Density |
Affordances per cognitive load unit — the cost-per-outcome ratio |
Progressive disclosure, correction as first-class UI, Chat-to-Canvas transition for persistent artifacts |
User manages the interface more than their task |
| Visual Cohesion |
Perceptual grammar consistency across outputs and states |
Design tokens + component grammar, semantic structure before styling, affordance protection (buttons look like buttons) |
Output looks "dropped in from another system" |
These pillars form a feedback system — adjusting one shifts the feasible region of the other two.
For detailed 1-10 scoring criteria: Read references/pillar-rubrics.md
Failure Modes
Too much taste is a system failure. Scan for all 8 modes during every audit.
| Failure Mode |
Detection Signal |
Antidote |
| Stochastic Over-Constraint |
Revision entropy increases; users fight the AI's "personality" instead of steering it |
Re-calibrate entropy injection points; let user steer creative vs deterministic |
| Density Paralysis |
Choice overload; user's mental model fragments (Hick's Law violation) |
Progressive disclosure; layer density spatially, not all at once |
| Cohesion Rigidity |
Output locked in narrow aesthetic band; system fights user when intent diverges |
Allow visual escape hatches; parameterize cohesion |
| Oracle Polish |
Users over-trust because surface coherence bleeds into perceived correctness (halo effect) |
Confidence-aware UI; expose uncertainty; never smooth caveats |
| Affordance Collapse |
Users miss actions; can't tell content from controls (flat design trap) |
Buttons must look like buttons; test discoverability with real users |
| Interaction Ceremony |
Time-to-value inflated by forced wizards, confirmations, tone selectors |
Remove any step that doesn't reduce correction cost; measure TTV |
| Trust Distortion |
Users accept outputs because they sound right, not because they verified |
Calibrate confidence to reliability; never use persona polish to mask uncertainty |
| Metric Gaming |
Proxies improve but product quality degrades (Goodhart's Law) |
Pair every metric with a counter-metric; run periodic qualitative audits |
North Star Metrics
Taste is an unobservable latent variable. Measure these proxies instead.
| Metric |
Formula |
Plain English |
Bad Looks Like |
| Refinement Velocity |
Vr = 1 / n_prompts |
Fewer prompts to accepted final state |
User needs 5+ turns to get something usable |
| Correction Density |
Dc = manual_edits / generated_tokens |
How much cleanup is needed |
Heavy post-generation editing on every output |
| Kinetic Friction |
Fk = t_action - t_render |
Time between seeing output and first meaningful action |
Too fast (no thinking, oracle trust) or too slow (navigation overhead) |
| Time-to-Value |
Seconds to first artifact surviving >30s without modification |
How quickly users get something useful |
Slow first output; high churn in first session |
| Correction Effort |
Edit distance between generated and accepted output |
Total cleanup cost |
Output requires heavy reformatting to become usable |
| Dismissal Rate |
% of AI suggestions ignored, collapsed, or dismissed |
Relevance + intrusion control |
System is noisy; users suppress it to work |
| Clarification Burden |
Average turns before a stable artifact exists |
Interaction density tax |
Users spend turns explaining instead of building |
Moderate kinetic friction is optimal. Too low = oracle trust (users accept without thinking). Too high = navigation overhead eats productivity. Target the zone where users think, then act.
Routing: Which Reference to Read
| Situation |
Action |
| Scoring a pillar in detail |
Read references/pillar-rubrics.md for 1-10 criteria with observable evidence |
| Building something new (Design mode) |
Read references/refiner-protocol.md for the 10-step Refiner Layer |
| Want the theoretical "why" |
Read references/theory-foundations.md for information theory, neuroscience, cognitive load |
| Auditing a live URL |
Use browse daemon: $B goto <url>, $B snapshot -i -a, $B screenshot |
| Auditing code or mockups |
Read files directly, score against pillar rubrics |
Audit Mode Protocol
Use this when scoring existing work.
Step 1: Identify the Subject
What are we auditing?
- Live URL — use browse daemon for snapshots (take at mobile 375px, tablet 768px, desktop 1440px)
- Code — read the source files and rendered output
- Mockup / design file — read or screenshot the design
- Generated output — evaluate the content directly
Step 2: Score Each Pillar (1-10)
Read references/pillar-rubrics.md for detailed scoring criteria. Quick reference:
Deterministic-Stochastic Balance:
- Where is entropy injected? Is it phase-aware (exploration vs execution)?
- Are structured outputs used where reliability matters?
- Can users toggle between creative and deterministic modes?
Interaction Density:
- How many turns/clicks to reach first useful output?
- Is correction cheap (edit-in-place, diffs) or expensive (re-prompt from scratch)?
- Are advanced controls hidden by default (progressive disclosure)?
- Is state persistent (canvas/artifact) or ephemeral (chat)?
Visual Cohesion:
- Does output render through a component grammar or raw text?
- Are affordances visible (buttons, links, actions clearly distinguishable)?
- Is typography, spacing, and hierarchy consistent across all states?
- Does generated content look native to the surrounding UI?
Step 3: Scan Failure Modes
Check all 8 failure modes from the table above. For each, mark Present/Absent with evidence.
Step 4: Measure Available Metrics
Which north star metrics can you compute from observation?
- Count turns to acceptance (Refinement Velocity)
- Estimate edit distance (Correction Density)
- Time the gap between render and first action (Kinetic Friction)
Step 5: Output the Scorecard
## Taste Audit: [Subject]
**Date:** [date]
**Auditor:** [name/agent]
### Pillar Scores
| Pillar | Score | Key Finding | Recommended Fix |
|--------|:-----:|-------------|-----------------|
| Deterministic-Stochastic Balance | /10 | | |
| Interaction Density | /10 | | |
| Visual Cohesion | /10 | | |
| **Composite** | **/30** | | |
### Failure Mode Scan
| Mode | Present? | Evidence | Severity |
|------|:--------:|----------|:--------:|
| Stochastic Over-Constraint | | | |
| Density Paralysis | | | |
| Cohesion Rigidity | | | |
| Oracle Polish | | | |
| Affordance Collapse | | | |
| Interaction Ceremony | | | |
| Trust Distortion | | | |
| Metric Gaming | | | |
### Metrics (if measurable)
| Metric | Observed Value | Assessment |
|--------|:--------------:|------------|
| Refinement Velocity | | |
| Correction Density | | |
| Kinetic Friction | | |
| Time-to-Value | | |
### Prioritized Fixes
| P | Fix | Pillar | Impact |
|:-:|-----|--------|:------:|
| 0 | | | |
| 1 | | | |
| 2 | | | |
### Grade
- 25-30 = **A** (taste is a competitive asset)
- 20-24 = **B** (solid, minor gaps)
- 15-19 = **C** (functional but friction-heavy)
- 10-14 = **D** (taste is actively hurting the product)
- <10 = **F** (taste is absent or harmful)
**Overall: [Grade]**
Step 6: Prioritize Fixes
Map findings to P0 (blocking UX) / P1 (significant friction) / P2 (polish). Fix P0s before shipping.
Design Mode Protocol
Use this when building new features or interfaces.
Step 1: Define the Taste Contract
Translate quality goals into testable constraints, not adjectives:
- What must be reproducible? (deterministic zones)
- Where is creativity allowed? (stochastic zones)
- What must never happen? (hard constraints)
- Reading level, verbosity ceiling, required sections, prohibited moves
- Citation rules, formatting grammar, interaction rules
Step 2: Pre-Score Against Three Pillars
Before building, predict where you'll land on each pillar. Identify the target score band and what observable criteria you need to hit.
Step 3: Apply the Refiner Layer
Read references/refiner-protocol.md for the full 10-step protocol. Summary:
- Define taste contract as constraints, not adjectives
- Separate divergence (exploration) from convergence (refinement)
- Generate structured intent representation before drafting
- Draft into intermediate representation, not directly into final UI
- Run critic pass with explicit rubrics
- Refine via diffs, not rewrites
- Anchor truth with tools, then re-render
- Compile to UI using component grammar
- Guarantee correction affordances at the surface
- Instrument taste as feedback loops
Step 4: Pre-Mortem Failure Modes
Run through all 8 failure modes as a pre-mortem: which could this design fall into?
- If adding polish: check for Oracle Polish and Cohesion Rigidity
- If adding features: check for Density Paralysis and Interaction Ceremony
- If reducing friction: check for Agency Collapse (IKEA effect loss)
- If showing confidence: check for Trust Distortion
Step 5: Plan Metrics Instrumentation
Decide which north star metrics you will track and how:
- Log time-to-first-value
- Track edit operations per session
- Count regenerations and diff rejections
- Monitor dismissal rates
- Pair every metric with a counter-metric (Goodhart protection)
Design Checklist
Run before shipping any user-facing AI feature:
Deterministic-Stochastic Balance
Interaction Density
Visual Cohesion
Anti-Failure-Mode Gates
Common Mistakes
| Mistake |
Reality |
| "Taste is subjective, can't be scored" |
Taste has measurable proxies: correction cost, time-to-value, dismissal rate |
| "More polish = more taste" |
Oracle Polish is a failure mode. Polish that outpaces reliability destroys trust |
| "Minimize all friction" |
Selective friction (IKEA effect) builds ownership. Remove friction only where it doesn't reduce understanding |
| "The model output IS the product" |
The model is a probabilistic component. The Refiner Layer makes it feel authored |
| "Chat is good enough" |
Chat serializes multi-dimensional state into a 1D stream. Canvas externalizes memory |
| "Make it beautiful and it's tasteful" |
Cohesion Rigidity and Affordance Collapse are both beauty-caused failures |
| "Users want everything instantly" |
Optimal pacing is layered: immediate ack (0.1s), provisional structure (1s), deferred commitment (seconds) |
| "Show confidence to build trust" |
Uncalibrated confidence creates the Uncanny Valley of Agency. Transparency builds trust |
Source Material
For the full 40,000-word theoretical foundation, see:
taste/taste.md — Foundation taxonomy, North Star metric, 5-step Refinertaste/chatgpt_taste.md — Engineering framework, 10-step Refiner, proxy metricstaste/deep-research-report.md — Neuroscience, cognitive load, agency, RLDF spectaste/AI Design Taste_ A Systems Approach.md — Information theory, SDEs, style weightstaste/Engineering AI Design Taste Framework.md — Operationalization, failure modes, synthesis
1---2name: kai-taste-23description: Audit or design generative AI interfaces against three diagnostic pillars (deterministic-stochastic balance, interaction density, visual cohesion). Treats taste as a measurable control system, not subjective preference. Use when: 'taste audit', 'score this UI', 'design quality', 'interaction density', 'visual cohesion', 'refiner layer', 'correction cost', 'why does this feel off', 'polish this', 'design review', or building any user-facing AI product.4---5
6# Design Taste: Engineering Framework
7
8Taste is a control system that converts stochastic model output into reliable user outcomes with minimal correction cost. It is not subjective preference — it has measurable proxies, diagnosable failure modes, and an engineering protocol.
9
10**Two modes:**
11- **Audit** — score an existing UI, product, or generated output against the Three Pillars
12- **Design** — apply taste principles when building new features or interfaces
13
14**Iron law:** Taste must remain subordinate to function. The moment the system's correction vector dominates the user's intent vector, the product crosses from high-fidelity to high-friction.
15
16---
17
18## The Three Pillars
19
20Every generative AI product sits in a 3-dimensional taste space. Score each pillar independently.
21
22| Pillar | What It Measures | Control Knobs | Bad Signal |
23|--------|-----------------|---------------|------------|
24| **Deterministic-Stochastic Balance** | Where entropy is injected in the pipeline — where the system is creative vs reproducible | Entropy budgeting across phases, multi-sample + rerank, structured outputs (schema), tool calls as determinism anchors | User says "why did it change?" or fights the AI's personality |
25| **Interaction Density** | Affordances per cognitive load unit — the cost-per-outcome ratio | Progressive disclosure, correction as first-class UI, Chat-to-Canvas transition for persistent artifacts | User manages the interface more than their task |
26| **Visual Cohesion** | Perceptual grammar consistency across outputs and states | Design tokens + component grammar, semantic structure before styling, affordance protection (buttons look like buttons) | Output looks "dropped in from another system" |
27
28These pillars form a feedback system — adjusting one shifts the feasible region of the other two.
29
30**For detailed 1-10 scoring criteria:** Read `references/pillar-rubrics.md`
31
32---
33
34## Failure Modes
35
36Too much taste is a system failure. Scan for all 8 modes during every audit.
37
38| Failure Mode | Detection Signal | Antidote |
39|-------------|-----------------|----------|
40| **Stochastic Over-Constraint** | Revision entropy increases; users fight the AI's "personality" instead of steering it | Re-calibrate entropy injection points; let user steer creative vs deterministic |
41| **Density Paralysis** | Choice overload; user's mental model fragments (Hick's Law violation) | Progressive disclosure; layer density spatially, not all at once |
42| **Cohesion Rigidity** | Output locked in narrow aesthetic band; system fights user when intent diverges | Allow visual escape hatches; parameterize cohesion |
43| **Oracle Polish** | Users over-trust because surface coherence bleeds into perceived correctness (halo effect) | Confidence-aware UI; expose uncertainty; never smooth caveats |
44| **Affordance Collapse** | Users miss actions; can't tell content from controls (flat design trap) | Buttons must look like buttons; test discoverability with real users |
45| **Interaction Ceremony** | Time-to-value inflated by forced wizards, confirmations, tone selectors | Remove any step that doesn't reduce correction cost; measure TTV |
46| **Trust Distortion** | Users accept outputs because they *sound* right, not because they verified | Calibrate confidence to reliability; never use persona polish to mask uncertainty |
47| **Metric Gaming** | Proxies improve but product quality degrades (Goodhart's Law) | Pair every metric with a counter-metric; run periodic qualitative audits |
48
49---
50
51## North Star Metrics
52
53Taste is an unobservable latent variable. Measure these proxies instead.
54
55| Metric | Formula | Plain English | Bad Looks Like |
56|--------|---------|--------------|----------------|
57| **Refinement Velocity** | `Vr = 1 / n_prompts` | Fewer prompts to accepted final state | User needs 5+ turns to get something usable |
58| **Correction Density** | `Dc = manual_edits / generated_tokens` | How much cleanup is needed | Heavy post-generation editing on every output |
59| **Kinetic Friction** | `Fk = t_action - t_render` | Time between seeing output and first meaningful action | Too fast (no thinking, oracle trust) or too slow (navigation overhead) |
60| **Time-to-Value** | Seconds to first artifact surviving >30s without modification | How quickly users get something useful | Slow first output; high churn in first session |
61| **Correction Effort** | Edit distance between generated and accepted output | Total cleanup cost | Output requires heavy reformatting to become usable |
62| **Dismissal Rate** | % of AI suggestions ignored, collapsed, or dismissed | Relevance + intrusion control | System is noisy; users suppress it to work |
63| **Clarification Burden** | Average turns before a stable artifact exists | Interaction density tax | Users spend turns explaining instead of building |
64
65**Moderate kinetic friction is optimal.** Too low = oracle trust (users accept without thinking). Too high = navigation overhead eats productivity. Target the zone where users think, then act.
66
67---
68
69## Routing: Which Reference to Read
70
71| Situation | Action |
72|-----------|--------|
73| **Scoring a pillar in detail** | Read `references/pillar-rubrics.md` for 1-10 criteria with observable evidence |
74| **Building something new (Design mode)** | Read `references/refiner-protocol.md` for the 10-step Refiner Layer |
75| **Want the theoretical "why"** | Read `references/theory-foundations.md` for information theory, neuroscience, cognitive load |
76| **Auditing a live URL** | Use browse daemon: `$B goto <url>`, `$B snapshot -i -a`, `$B screenshot` |
77| **Auditing code or mockups** | Read files directly, score against pillar rubrics |
78
79---
80
81## Audit Mode Protocol
82
83Use this when scoring existing work.
84
85### Step 1: Identify the Subject
86
87What are we auditing?
88- **Live URL** — use browse daemon for snapshots (take at mobile 375px, tablet 768px, desktop 1440px)
89- **Code** — read the source files and rendered output
90- **Mockup / design file** — read or screenshot the design
91- **Generated output** — evaluate the content directly
92
93### Step 2: Score Each Pillar (1-10)
94
95Read `references/pillar-rubrics.md` for detailed scoring criteria. Quick reference:
96
97**Deterministic-Stochastic Balance:**
98- Where is entropy injected? Is it phase-aware (exploration vs execution)?
99- Are structured outputs used where reliability matters?
100- Can users toggle between creative and deterministic modes?
101
102**Interaction Density:**
103- How many turns/clicks to reach first useful output?
104- Is correction cheap (edit-in-place, diffs) or expensive (re-prompt from scratch)?
105- Are advanced controls hidden by default (progressive disclosure)?
106- Is state persistent (canvas/artifact) or ephemeral (chat)?
107
108**Visual Cohesion:**
109- Does output render through a component grammar or raw text?
110- Are affordances visible (buttons, links, actions clearly distinguishable)?
111- Is typography, spacing, and hierarchy consistent across all states?
112- Does generated content look native to the surrounding UI?
113
114### Step 3: Scan Failure Modes
115
116Check all 8 failure modes from the table above. For each, mark Present/Absent with evidence.
117
118### Step 4: Measure Available Metrics
119
120Which north star metrics can you compute from observation?
121- Count turns to acceptance (Refinement Velocity)
122- Estimate edit distance (Correction Density)
123- Time the gap between render and first action (Kinetic Friction)
124
125### Step 5: Output the Scorecard
126
127```markdown
128## Taste Audit: [Subject]
129**Date:** [date]
130**Auditor:** [name/agent]
131
132### Pillar Scores
133| Pillar | Score | Key Finding | Recommended Fix |
134|--------|:-----:|-------------|-----------------|
135| Deterministic-Stochastic Balance | /10 | | |
136| Interaction Density | /10 | | |
137| Visual Cohesion | /10 | | |
138| **Composite** | **/30** | | |
139
140### Failure Mode Scan
141| Mode | Present? | Evidence | Severity |
142|------|:--------:|----------|:--------:|
143| Stochastic Over-Constraint | | | |
144| Density Paralysis | | | |
145| Cohesion Rigidity | | | |
146| Oracle Polish | | | |
147| Affordance Collapse | | | |
148| Interaction Ceremony | | | |
149| Trust Distortion | | | |
150| Metric Gaming | | | |
151
152### Metrics (if measurable)
153| Metric | Observed Value | Assessment |
154|--------|:--------------:|------------|
155| Refinement Velocity | | |
156| Correction Density | | |
157| Kinetic Friction | | |
158| Time-to-Value | | |
159
160### Prioritized Fixes
161| P | Fix | Pillar | Impact |
162|:-:|-----|--------|:------:|
163| 0 | | | |
164| 1 | | | |
165| 2 | | | |
166
167### Grade
168- 25-30 = **A** (taste is a competitive asset)
169- 20-24 = **B** (solid, minor gaps)
170- 15-19 = **C** (functional but friction-heavy)
171- 10-14 = **D** (taste is actively hurting the product)
172- <10 = **F** (taste is absent or harmful)
173
174**Overall: [Grade]**
175```
176
177### Step 6: Prioritize Fixes
178
179Map findings to P0 (blocking UX) / P1 (significant friction) / P2 (polish). Fix P0s before shipping.
180
181---
182
183## Design Mode Protocol
184
185Use this when building new features or interfaces.
186
187### Step 1: Define the Taste Contract
188
189Translate quality goals into **testable constraints**, not adjectives:
190- What must be reproducible? (deterministic zones)
191- Where is creativity allowed? (stochastic zones)
192- What must never happen? (hard constraints)
193- Reading level, verbosity ceiling, required sections, prohibited moves
194- Citation rules, formatting grammar, interaction rules
195
196### Step 2: Pre-Score Against Three Pillars
197
198Before building, predict where you'll land on each pillar. Identify the target score band and what observable criteria you need to hit.
199
200### Step 3: Apply the Refiner Layer
201
202Read `references/refiner-protocol.md` for the full 10-step protocol. Summary:
2031. Define taste contract as constraints, not adjectives
2042. Separate divergence (exploration) from convergence (refinement)
2053. Generate structured intent representation before drafting
2064. Draft into intermediate representation, not directly into final UI
2075. Run critic pass with explicit rubrics
2086. Refine via diffs, not rewrites
2097. Anchor truth with tools, then re-render
2108. Compile to UI using component grammar
2119. Guarantee correction affordances at the surface
21210. Instrument taste as feedback loops
213
214### Step 4: Pre-Mortem Failure Modes
215
216Run through all 8 failure modes as a pre-mortem: which could this design fall into?
217- If adding polish: check for Oracle Polish and Cohesion Rigidity
218- If adding features: check for Density Paralysis and Interaction Ceremony
219- If reducing friction: check for Agency Collapse (IKEA effect loss)
220- If showing confidence: check for Trust Distortion
221
222### Step 5: Plan Metrics Instrumentation
223
224Decide which north star metrics you will track and how:
225- Log time-to-first-value
226- Track edit operations per session
227- Count regenerations and diff rejections
228- Monitor dismissal rates
229- Pair every metric with a counter-metric (Goodhart protection)
230
231### Design Checklist
232
233Run before shipping any user-facing AI feature:
234
235**Deterministic-Stochastic Balance**
236- [ ] Entropy injection points identified (where creative, where locked)
237- [ ] Structured outputs enforced for downstream actions
238- [ ] Tool calls used for factual queries instead of model guessing
239- [ ] Multi-sample + rerank for quality-sensitive outputs
240- [ ] User can toggle between exploration and execution modes
241
242**Interaction Density**
243- [ ] Default path is shallow (progressive disclosure)
244- [ ] Correction is cheap (edit-in-place, scoped refine, accept/reject diffs)
245- [ ] Advanced controls contextual, not upfront
246- [ ] Persistent artifacts used for multi-step work (not buried in chat)
247- [ ] State externalized as manipulable objects
248
249**Visual Cohesion**
250- [ ] Outputs compile through component grammar (not raw text to UI)
251- [ ] Semantic structure enforced before styling (headings, sections, callouts)
252- [ ] Affordance protection (buttons look like buttons, links look like links)
253- [ ] Design tokens consistent across all output states
254- [ ] Generated content indistinguishable from hand-authored content in the same UI
255
256**Anti-Failure-Mode Gates**
257- [ ] Uncertainty is signaled, not smoothed (anti-Oracle Polish)
258- [ ] User can override/escape system suggestions (anti-Cohesion Rigidity)
259- [ ] No forced steps that don't reduce correction cost (anti-Interaction Ceremony)
260- [ ] Trust calibrated to actual reliability (anti-Trust Distortion)
261- [ ] Selective friction preserves user agency (anti-Agency Collapse)
262
263---
264
265## Common Mistakes
266
267| Mistake | Reality |
268|---------|---------|
269| "Taste is subjective, can't be scored" | Taste has measurable proxies: correction cost, time-to-value, dismissal rate |
270| "More polish = more taste" | Oracle Polish is a failure mode. Polish that outpaces reliability destroys trust |
271| "Minimize all friction" | Selective friction (IKEA effect) builds ownership. Remove friction only where it doesn't reduce understanding |
272| "The model output IS the product" | The model is a probabilistic component. The Refiner Layer makes it feel authored |
273| "Chat is good enough" | Chat serializes multi-dimensional state into a 1D stream. Canvas externalizes memory |
274| "Make it beautiful and it's tasteful" | Cohesion Rigidity and Affordance Collapse are both beauty-caused failures |
275| "Users want everything instantly" | Optimal pacing is layered: immediate ack (0.1s), provisional structure (1s), deferred commitment (seconds) |
276| "Show confidence to build trust" | Uncalibrated confidence creates the Uncanny Valley of Agency. Transparency builds trust |
277
278---
279
280## Source Material
281
282For the full 40,000-word theoretical foundation, see:
283- `taste/taste.md` — Foundation taxonomy, North Star metric, 5-step Refiner
284- `taste/chatgpt_taste.md` — Engineering framework, 10-step Refiner, proxy metrics
285- `taste/deep-research-report.md` — Neuroscience, cognitive load, agency, RLDF spec
286- `taste/AI Design Taste_ A Systems Approach.md` — Information theory, SDEs, style weights
287- `taste/Engineering AI Design Taste Framework.md` — Operationalization, failure modes, synthesis
majiayu000