Introduction

The dominant framing of AI in design work is generative. Tools compete on how much they can produce: interface mockups from a sentence, full component libraries from a screenshot, endless “variants” on demand. The implicit theory of value is that design was bottlenecked on production, and that removing the production bottleneck removes the problem.

This paper asks a different question: can AI hold design decisions — judgments about what is good, what ships, and why — rather than merely produce candidates? And how far can such judgment be made formal? The question matters because, once generation is nearly free, two failure modes dominate that the generative framing cannot even name. The first is regression to the generic: model outputs that are technically competent — contrast passes, structure is sound — yet indistinguishable from every other model output, a phenomenon practitioners have begun calling “AI slop” [22]. A design in this state has tokens but no brand. The second is subtler: when the response is to automate evaluation as well, the automation itself can become low-value performance — checklists that check nothing, verdicts with no evidence behind them — a failure practitioners have started calling “work-slop” [22]. Both are failures of judgment, not of output.

Our thesis is that AI can hold design decisions only when it is constructed as evaluative and governance machinery rather than a generator — and that this machinery has a formalizable shell and an explicit, deliberately-open boundary. By decision-maker we mean something precise: the AI holds mandatory, gating authority over the operationalizable shell of the judgment; the full decision remains a division of labor across deterministic code, an independent adversary, and a human. The shell is a deterministic functional: we show that the operationalizable shell of “genericness sense” can be written as a bounded, reproducible, and (after a documented repair) monotone functional over typed design tokens, tuned against a separation objective (§5) — a one-sided proxy for slop-likeness, not a verdict on quality. The boundary is equally load-bearing, but it is not a proof of impossibility: the latent core — the judgment of latent-need fit — is not-yet-operationalized and deliberately not faked, marked in the machinery itself as escalating to a human (§4.5, §5.7), and the frontier between shell and core moves as more of a judgment becomes operationalizable. The answer to the title’s question, in short, is: yes, exactly to the depth that the judgment can be made deterministic and adversarially or humanly checked — and no further yet.

We argue this position from first principles (§3), state it as a requirements framework of five principles (§4), formalize its core mathematically (§5), and then validate it with deployment evidence (§6): two systems built solo by the same operator, months apart, for different products — anonymized here as System A, a design-system intelligence CLI whose central artifact is not a generator but a deterministic genericness grader, and System B, an unreleased local-first knowledge-agent system whose entire checking path deliberately contains no LLM. The two systems were not designed to resemble each other, yet under deployment pressure they converged on the same governance architecture: LLMs may propose, but deterministic code must judge; a different vendor’s model must attempt to refute work before it ships; every automated change must snapshot state and verify itself after writing, restoring on failure; and one class of judgment — “did this solve the user’s real, latent problem?” — is never automated and always escalates to a human. The systems are the evidence, not the subject: their partly-independent convergence (they share one deliberately-carried origin lesson, §6.4) corroborates — without proving, on n=1 — the generality of the requirements, in the pattern-language tradition of Alexander [1] and Gamma et al. [7], at the “intermediate level” of design knowledge that Höök and Löwgren call strong concepts [11].

We are explicit about genre. This is a systems and design-rationale paper with a first-person deployment account (n=1: one operator, one toolchain), in the lineage of research through design [19, 8] and autobiographical design [13, 12]. It is not a controlled user study, and we claim no statistical generalization. What we claim is that the deployment record — dated autonomous improvement cycles, adversarial audits with confirmed-finding counts, rolling test-suite ledgers, and one detailed case in which cross-vendor verification caught defects that thousands of assertions missed — constitutes real evidence about how the requirements behave under sustained use, of the kind that annotated portfolios are meant to carry [9].

Contributions.

1. A requirements framework of five principles for AI as design decision-maker — evaluative over generative, deterministic adjudication, anti-averaging, cross-vendor adversarial verification, and the escalation boundary — argued conceptually, each with its problem, principle, forces, and boundary (§4).
2. A mathematical formalization of the genericness judgment as a central contribution (§5): a deterministic, bounded, and — after the repair documented in §5.8 — monotone functional over typed design tokens, a separation objective for calibration, and — as its load-bearing property — an explicit statement of the judgment it refuses to encode.
3. Deployment evidence (§6): two independently built systems as an existence proof that the requirements are buildable and operable, including the verification regime that governs them (pre/post gates, deterministic checkers, adversarial fan-out, and a snapshot/verify-the-verifier meta-method), a case study — the “default-font loophole” — in which same-model self-review and a large test suite shared the same blind spots and only a different-vendor adversary found them, and audit and build ledgers with dated counts.
4. An honest first-person methodological account of what n=1 deployment evidence can and cannot support (§8).

Related Work

2.1Mixed-Initiative and Human-AI Interaction

The question of how initiative should be divided between humans and automated systems predates modern LLMs. Horvitz’s principles of mixed-initiative interfaces [10] framed the core tension: automated action is valuable exactly when the system’s inference about user goals is reliable, and costly when it is not. Parasuraman, Sheridan, and Wickens [14] offered a model of levels of automation across information acquisition, analysis, decision, and action — a decomposition our escalation-boundary principle (§4.5) effectively re-derives for design judgment: automate detection and analysis fully, automate decision only where adjudication can be made deterministic, and never automate the final fitness-to-purpose judgment.

More recent guidance for human-AI interaction [2] and human-centered AI [15a] emphasizes calibrated reliance and human control. Empirical work has shown that AI assistance often fails to produce complementary performance — humans defer to confident-but-wrong systems [3] — and that cognitive forcing functions can reduce overreliance at some cost in satisfaction [5]. The architecture we argue for can be read as pushing forcing functions from the interaction layer into the architecture: rather than nudging a human to double-check an LLM, the pipeline is constructed so that an LLM’s self-report is structurally inadmissible as evidence.

2.2Generative Design Tools and the Homogenization Problem

Yang et al. [16] identified why AI is uniquely difficult as a design material: capability uncertainty and output complexity resist standard prototyping. Zamfirescu-Pereira et al. [17] showed that non-experts systematically struggle to control LLM behavior through prompts alone — a finding that anticipates our second principle, since prompt-only control is precisely what failed in the production incident that motivated deterministic adjudication (§6.4).

A growing body of work documents that generative models, used naively, homogenize creative output: individual quality may rise while collective diversity falls [6], and LLM-assisted ideation exhibits measurable convergence effects [21]. Bender et al.’s critique of large language models [4] anticipated the structural tendency of such models toward high-probability output; that this surfaces, at the population level, as averaged, less-diverse output is what [6, 21] establish. Our anti-averaging principle (§4.3) treats this not as an aesthetic complaint but as the first-order target of evaluation: the evaluator’s primary duty is to detect regression-to-the-generic, because that is the failure mode generation-first tooling produces by default.

2.3AI Evaluation and Critique

The “LLM-as-judge” paradigm [18] uses one model to grade another’s output, and reports encouraging agreement with human preferences in some settings. But there is evidence that LLM evaluators recognize and favor their own generations [20], and our deployment record contributes a concrete field instance of the underlying problem: same-model self-analysis missed three defects in an already-deployed evaluator that a different vendor’s model found in four refutation rounds (§6.7). Our position is narrower than a rejection of LLM-as-judge: LLMs may generate critiques, questions, and candidate findings, but the adjudication — scoring, arithmetic, pass/fail — must be deterministic code, and where genuine judgment is required, it must be adversarial and independent — in practice cross-vendor, which is an imperfect proxy for independence (different vendors can still share training data, benchmarks, and blind spots), or human.

2.4Autonomous Agents and Trust

Agentic systems that modify codebases and ship changes raise trust questions that interaction guidelines alone do not answer: what happens when the agent’s self-assessment is wrong and no human is watching? Shneiderman’s framing of reliable, safe, and trustworthy AI [15b] calls for audit trails and independent oversight. The snapshot/verify-the-verifier mechanism reported in §6.5 is a concrete construction of that demand for a solo operator: every automated change records its pre-change state, verifies its own effect after writing, and restores automatically on failure — with a distinct, louder failure mode when the restore itself fails.

2.5Research Through Design and First-Person Methods

Zimmerman, Forlizzi, and Evenson [19] legitimized artifacts as carriers of research knowledge; Gaver [8] argued that research through design produces generative, provisional theory rather than falsifiable law, best conveyed through annotated portfolios [9]. First-person and autobiographical methods [13, 12] establish that sustained genuine use by the researcher — with honest reporting of failures — yields insights inaccessible to short lab studies. We adopt these framings explicitly: two artifacts, one operator, an annotated deployment record, and pattern-language codification [1, 7, 11] as the mechanism for making the knowledge transferable.

The Problem of Design Judgment

Before stating requirements, we argue from first principles why design judgment is the hard part of AI design tooling — independent of any particular system.

3.1The Inversion of Scarcity

When generation is expensive, more generation is valuable; when generation is nearly free, its marginal value inverts. Every additional generated variant adds to a review burden that nothing in a generation-first tool reduces. The binding constraint in a sustained design pipeline is therefore not production capacity but judgment: the ability to say which output is good, why, and against what standard. A tool that multiplies candidates without multiplying the capacity to adjudicate them has moved the bottleneck, not removed it.

The binding constraint in a sustained design pipeline is not production capacity but judgment.

3.2Why Design Judgment Resists Automation

A single design judgment does not split into two kinds; it decomposes, per instance, into an operationalizable shell and a latent core. The shell is what can be checked against explicit criteria — proximity to known defaults, coverage of expected states, mechanical rule violations — all properties of the artifact itself. The core is what stated requirements, by definition, fail to capture: whether the artifact solves the user’s real, latent problem. The two are not fixed buckets but the ends of a spectrum, and the mix varies by the property being judged: an accessibility judgment is mostly shell (contrast ratios, focus order, target sizes are largely operationalizable); a judgment of cultural or symbolic meaning is mostly core; craft sits in between, part measurable and part not. Because every property is a point on this shell↔core spectrum rather than a member of one of two classes, the question “is the decomposition exhaustive?” does not arise — decomposition, not partition, is the claim.

Genericness is this paper’s worked example of the decomposition: its shell is the deterministic metric G of §5, and its core — whether an on-brand, considered identity is actually present — escalates rather than being scored. The gap between shell and core is where conventional evaluation fails. A design can be technically fine — contrast and structure OK — yet generic: it has tokens but no brand, and reads like default AI output. This is not a bug that a linter can name; it is a brand judgment. Conventional evaluation criteria (contrast, spacing, validity) certify competence, not identity, and therefore systematically pass output that has lost the identity that distinguishes the product. Any account of AI-held design decisions must say precisely how far into a judgment its shell reaches, and what it does with the core it cannot reach.

3.3Failure Mode I: Regression to the Generic

The default output of a generative model is, statistically, an average — a structural tendency toward high-probability output anticipated in critiques of large language models [4] and documented as homogenization in the creativity literature: individual quality may rise while collective diversity falls [6], and LLM-assisted ideation measurably converges [21]. What those findings describe at the population level, a practitioner experiences per-artifact as “this looks like every AI-generated page.” In design, average is a specific and costly failure: the product loses the identity that distinguishes it — and, critically, the evaluation criteria most tools apply cannot see the loss, because averaged output passes them.

3.4Failure Mode II: The Automation of Evaluation Itself

The obvious response — automate the evaluation too — introduces the second failure mode. If the same class of system that produces an output also adjudicates it, adjudication inherits generation’s failure modes: fluent, confident, and unverifiable. Prompt-only control demonstrably fails to constrain model behavior [17], and stochastic judges are neither reproducible nor auditable; there is evidence they favor their own generations [20]. Pushed to its limit, automated evaluation produces verdicts on questions that resist operationalization — including the latent-need question of §3.2 — and such verdicts are confident, cheap, and hollow: a new species of low-value automation (“work-slop” [22]) generated by the very machinery meant to prevent low-value output.

3.5What Any Solution Must Provide

The two failure modes jointly constrain the solution space. Against regression-to-the-generic, evaluation must be aimed at the generator’s default failure — distance from the average — not merely at conformance to rules. Against work-slop, the evaluation machinery itself must be governable: reproducible where it claims authority, checked by an adversary that does not share its blind spots, and honest about the boundary beyond which it holds no authority at all. The five principles of §4 are these constraints made explicit; §5 shows the core of them can be made mathematical; §6 shows they can be built.

A Requirements Framework: Five Principles

We state the five principles as design patterns: each with the problem it answers, the principle itself, the forces that shape it, and its boundary. The principles are ordered from what the AI should be (P1), through how its judgments must be constructed (P2, P3), to how those judgments are themselves policed (P4, P5). They are argued here generally, on their own merits; §6 presents their concrete instantiations and deployment record as evidence that they are buildable.

Formalizing Design Judgment

We now elevate the paper’s central technical claim: the shell of design “sense” — the felt judgment that an output looks generic — can be turned into a deterministic, inspectable number, while its latent core is, by construction, not computed within that machinery — escalated to a human rather than approximated. The number is a one-sided proxy for slop-likeness (default-AI-output-likeness), not a measure of genericness in full and not a verdict on good design. This section carries the paper’s answer to its title question: the mathematics states how far, so far, AI-held design judgment has been made formal, and the honesty asymmetry of §5.7 states where the present frontier lies. We give the formal skeleton that carries the feasibility argument; the detector taxonomy, the calibration methodology and its limits, the domain-relativity of the metric, and its failure modes are developed in the companion measurement paper [companion]. The formalization below is not a post-hoc model; it is a faithful transcription of the principal operators actually deployed in System A (§6.2), with the constants as shipped (a few lower-impact detectors are named but not expanded here). Its purpose is threefold: to make the shell precise, to expose the properties that make it governable (determinism, monotonicity, boundedness), and to state honestly the latent core it deliberately does not model.

Evidence from Deployment

The framework of §4 and the formalization of §5 would remain a proposal without an existence proof. This section supplies one: two systems, built solo by the same operator, months apart, for different products, in which the requirements were built, the formalization was deployed, and the governance machinery was exercised — and audited — under real use. Neither system is offered as a reference implementation or a standard to copy; they are anonymized evidence that the requirements are buildable, and a record of how they behave when they are.

6.1Genre and Data

This section describes both our research evidence and the systems’ operating method, because in this genre they are the same thing: the first author is the sole operator, and the evidence is the deployment record the regime itself produces. Following research-through-design and autobiographical-design practice [19, 8, 13], we report the regime as designed, the ledgers as recorded, and the failures alongside the successes. Nothing in this paper is a controlled comparison; §8 details the resulting threats to validity. All numbers reported below come from the systems’ own dated ledgers: commit-anchored autonomous cycle records (System A) and audit reports plus rolling pytest counts (System B).

6.2System A: Design-System Intelligence with a Self-Improving Evaluator

System A is a command-line design-system intelligence tool (Python, standard library only). Its knowledge base spans a large reference corpus — design-system references across several categories, domain presets, component specifications, and design-intelligence entries — organized partly through a design ontology and informed by a large analyzed corpus of product screens. It generates design systems for over a dozen frontend stacks.

But System A’s distinctive artifact is evaluative, not generative (P1): it shows a founder why a product looks like generic AI output and what an on-brand direction would be. Its core thesis, stated in its own design documents, is that a design can be “technically fine (contrast and structure OK) yet generic — it has tokens but no brand, so it reads like default AI output; this is not a bug, it is a brand judgment.” The operating principle behind it is distinctiveness over averageness: preserve the small fraction of choices that make a product recognizably itself.

Operationally, this thesis is exactly the machinery formalized in §5: a deterministic genericness grader producing an integer score G ∈ [0,100] with interpretation bands (§5.3), a letter grade A–F via the fail-closed map Γ (§5.4), and named, inspectable slop-signal detectors with fixed severity weights (high = 28, medium = 14, low = 0) — no-brand-color, single-accent-monotone, ai-default-indigo (membership in a list of 7 default indigo/purple hex values), ai-default-color (membership in 13 framework-default hexes drawn from Tailwind, Bootstrap, Material, and Ant defaults), too-many-accents, and default-font (fires only when all fonts are default families such as Inter, Roboto, Arial, or Helvetica, matched by base family so that “Inter Variable” normalizes to “inter”). Color matching is deliberately deterministic (P2): notation normalization only, with no perceptual or ΔE near-matching. On input too sparse to assess (fewer than 2 colors and no fonts), the grader returns grade “?” — “cannot assess” — via a dedicated insufficient-data signal, rather than awarding a clean score to an empty design; that this required a fix at all is part of the case study in §6.7.

On the generation side, anti-averaging (P3) is engineered as six opt-in “DNA axes” — built one per autonomous improvement cycle — that inject brand character into output: color, radius, typography, zoning (per-screen accent assignment), component form (e.g., a premium character multiplies radius by 0.8 and deepens shadows, while playful multiplies radius by 1.3 and lightens them), and motion (e.g., premium = 400ms ease-out; playful = 250ms spring). Each axis is regression-tested to be non-regressing on non-DNA output: adding character for one client cannot silently alter everyone else’s defaults.

The escalation boundary (P5) is encoded in the artifact. The problem-fit axis is kept strictly separate from the visual-slop grade and is never averaged into it: a beautiful design that fails its job must not be rescued by its aesthetics, nor vice versa. Within that axis, gap detection is automated and evidence-bound: a missing-state-coverage detector flags interactive or data-driven surfaces lacking empty, loading, and error states — and declared boolean self-reports such as has_loading: true are ignored; actual state nodes are required. Above the detectors sits a signal named problem-fit-senior that always escalates the final latent-need judgment to a human, annotated in the codebase as “not automatable.” The autonomous pipeline enforces the same boundary at the process level: proposed changes are classified objective / taste / strategy / ip, and only test-gateable objective items auto-proceed — taste, strategy, and IP items escalate.

Finally, System A operates an autonomous self-improvement pipeline in which an AI project-manager agent orchestrates a design agent, a development agent, and an adversarial reviewer through a Prioritize → Implement → Verify loop; its gates are described in §6.5.

6.3System B: A Local-First Knowledge-Agent System

System B is a local-first knowledge system for a solo operator. It is verification-first: its job is to validate and reconcile a user’s source material rather than to expand model output, and it keeps that material on local hardware by default. Because the system is unreleased, we describe its user-facing surface only generically — one feature helps the operator review what has changed and which items remain open across sessions, with source evidence attached.

System B’s governance backbone is a deterministic enforcement layer (containing no LLM in its checking path): a grounding check that machine-compares every published number and claim to its source; a fact-contract verifier with statuses verified / drifted / missing; a value-conflict sweep that surfaces inter-source contradictions for human resolution; a snapshot-verified safe-write; an exact-key intent-recall gate (“don’t re-ask what is already known”) that uses no LLM; a run ledger in which a completion marker is itself evidence; and learned rules that reuse prior human refutations. A trust score is deliberately allowed to be None — “unmeasured” — rather than fabricated, and a freshness gate demotes or blocks stale snapshots. This layer was completed on 2026-07-15 with its test suite at 93/93 passing.

System B instantiates the principles across its stack. For P1, a design-critic blind-scoring rubric is a mandatory pre-ship gate for every screen, document, and agent output, with a learning loop: a rejection becomes a golden-set evaluation case, so taste debates dissolve into a shared, accumulating yardstick rather than recurring as arguments. AI is also used evaluatively upstream of building: adversarial design review of specifications before any code exists (§6.5), and an AI planning pass whose 8-phase roadmap was then approved by the human founder — the AI proposing structure, the human ratifying it. For P2, a four-gate architecture (Input → State → Output → Action) applies the invariant end-to-end — stated internally as “the LLM may generate the question, but it may never adjudicate the answer; the checker must be deterministic to the end”: question generation is LLM-allowed; answer adjudication is deterministic; LLM self-grading is forbidden; any claim without an evidence reference receives status “pending” — never “pass” — and pending items route to human review. The trust-score convention (None = unmeasured) extends determinism to meta-honesty: the system may not invent confidence any more than it may invent numbers. For P3, anti-averaging surfaces less as a visual concern and more as an honesty concern about interfaces: a dead-affordance hard rule forbids fake or no-op UI — a button that does nothing must be wired, disabled-and-labeled, or removed. The connection to averaging is direct: no-op affordances are what generic generation produces when it imitates the shape of an interface without its function. For P5, the boundary is a standing rule — the final judgment “does this actually solve the user’s real, latent problem?” is explicitly not automatable and escalates to the human — hardened by pending-status routing and by the requirement that deployment metrics be human-signed, preventing post-hoc metric-picking by any automated reporter.

6.4The Shared Origin: A Production Fabrication Incident

Both systems trace their deterministic core to the same earlier lesson. In a prior production reporting system, prompt-only rules failed to stop an LLM from fabricating weekly metrics: instructions not to invent numbers did not prevent invented numbers. The remedy was architectural, not rhetorical — the arithmetic was migrated to deterministic Python code, with the LLM restricted to narrating values injected into its context. After the migration, the fabrication did not recur across 8 subsequent re-verifications.

Both projects explicitly name this lesson as the ancestor of their governance machinery, and treat System B’s grounding checker and System A’s deterministic scorer as the same reusable pattern. This shared provenance matters for interpreting the convergence finding (§6.9): the operator carried one lesson forward, but the rest of the architecture — cross-vendor verification, snapshot self-checking, the human escalation boundary — re-emerged independently in each system under deployment pressure.

6.5The Verification Regime as Operated

The regime that builds and governs both systems instantiates P4 and the meta-level of P2 in four mechanisms.

Pre-gates: adversarial review before building. Consequential work passes a gate before implementation. For strategy-shaped work, this is a Socratic pass that surfaces assumptions as questions. For specs, it is adversarial design review by a different-vendor model under a “refute this” framing. The new-feature case (§6.8) shows the yield: 6 of 6 pre-code attacks confirmed as real flaws — each of which would have been rework after implementation. Grounding is also a pre-gate: designs must be based on reading the actual code to be extended, not on recalled assumptions about it.

Post-gates: deterministic checks plus independent refutation. After implementation, work passes a layered post-gate. In System A’s autonomous pipeline, the PM gate requires all of: an adversarial reviewer verdict of pass; tests passing; the full test suite run directly and observed green — agent self-reports of test success are distrusted by construction; and zero “forbidden targets” in the diff (secrets, proprietary data, internal documents). Upstream of the gate, a Minimum-Features check in the Prioritize phase rejects any change not strictly necessary, which keeps the verification surface small enough to verify. In System B, the equivalent is the four-gate deterministic path plus tiered adversarial review (§4.4).

Snapshot / verify-the-verifier. The regime’s most distinctive mechanism answers a recursive question: who verifies the verification? System A’s snapshot-and-restore commit wrapper wraps every automated commit in a snapshot-and-self-check protocol: it records the pre-change SHA into the commit message, runs the tests adjacent to the change, and on two consecutive failures performs a hard reset to the snapshot and logs a must-fix item. Its exit status encodes a severity ladder — commit succeeded; change restored after failure; and, most severe, the restore itself failed, which halts the pipeline and escalates. That last rung is the crucial design decision: a failed safety mechanism must be louder than a failed change, never quieter. The wrapper also blocks blanket staging commands, permitting only targeted adds — an agent cannot sweep unintended files into a commit even accidentally. The pipeline runs on a scheduled cadence; a fully unattended path exists but is deliberately left awaiting human activation, itself an instance of the escalation boundary (§4.5). System B’s counterpart is snapshot-verified safe-write in its enforcement layer, plus the run ledger: a completion marker is evidence, so “the job ran” is a checkable claim rather than an assertion. The freshness gate extends verification through time — stale snapshots are demoted or blocked rather than silently trusted — and §6.8’s “time-bomb” test failure shows why time is an adversary worth modeling.

Adversarial fan-out. For large audits, single-pass review structurally misses cross-cutting defects, so the regime uses fan-out: many independent agents, each confined to one lens (honesty, accuracy, security, integration, frontend, test), followed by per-finding adversarial refutation, with only CONFIRMED findings driving fixes. The refutation stage is what separates this from brainstorming-at-scale: raw findings from 49 agents would be work-slop; 43 confirmed findings with severity ratings are an actionable ledger (§6.8).

The human at the boundary. Everything above narrows what reaches the operator: deterministic checks absorb the mechanical, adversarial review absorbs the arguable, and what remains — taste, strategy, latent-need fit, activation of unattended autonomy — arrives as an explicit escalation with evidence attached. The regime’s promise to the solo operator is not “you will not be needed” but “you will only be needed where you are actually irreplaceable.”

6.6System A: The Evaluator Ledger

The six DNA axes and successive evaluator refinements shipped as approximately 17 dated autonomous cycles between 2026-07-02 and 2026-07-21, each passing the full PM gate of §6.5. Representative shipped results from the ledger:

• An ecommerce slop input moved from genericness 100 to 28 (grade F → C) after the automated repair pass — a re-run for this paper; the repair pass reduces genericness substantially but did not reach grade A.
• A gray fintech slop input moved from 72 to 28 (D → C).
• On a pilot golden set, the separation between distinct and generic designs — the evaluator’s core discriminative power — is currently +31.2 points (distinct mean 3.8, generic mean 35.0; earlier logs report +14.6 initially), with default-font false positives on distinct designs at 1 of 11.
• Golden-set spot checks against real product tokens behaved as the thesis predicts: most scored 0/A (including linear, vercel, notion, stripe, cursor); figma 42/D (flagged for default fonts — the sole distinct false positive).

The ledger also records a genuine evaluator failure and its repair. Early calibration produced a rank reversal: a genuinely distinct design (Figma’s tokens) scored worse (28/D) than hand-built deliberately generic mockups (14/B). An anti-averaging evaluator that ranks the distinct below the generic is failing at exactly its one job; the early reversal was addressed by calibration (lifting the generic bundles to 42/D), though Figma now ties those bundles rather than ranking below them — a residual we retain in the golden set, since a mean-separation objective does not forbid individual ties (§5.5). We report this because a deployment account that only reported the score improvements would itself violate the paper’s thesis.

6.7Case Study: The Default-Font Loophole

The paper’s central evidence for P4 concerns System A’s already-deployed evaluator. The evaluator was covered by a large test suite (see §8 on the inconsistent counts) and had passed same-model self-analysis. An independent, different-vendor model, used as an adversarial cross-checker over four refutation rounds, found three defects that both had missed:

1. The loophole itself. The default-font detector used exact string matching, so the font “Inter Variable” slipped past the check for “inter.” A design using only default fonts could thus evade the strongest single slop signal by using a variable-font name. Fix: first-word base-family matching, so “Inter Variable” normalizes to “inter” — the base(·) normalization of §5.2.
2. A false-clean on sparse input. On input below the assessment threshold, the scorer returned grade A with score 0 — reporting “clean/distinct” about a design it had essentially not seen. This is an Evidence-Lock violation in miniature: a confident verdict without evidence. Fix: fail-closed “cannot assess” (grade “?”), as formalized in §5.4.
3. A self-contradictory guard. A penalty term was guarded by if overall > 0, so a worst-case grade-F design with overall quality exactly 0 computed a genericness of 0 — the system’s worst design received its best slop score. Fix: apply the penalty unconditionally — the monotonicity repair of §5.8.

Three properties of this episode matter beyond the bug count. First, the defects were in the evaluator, not in evaluated designs — the governance layer itself was the artifact that needed governing. Second, the coverage that missed them was not thin: thousands of assertions and a same-model review shared the same blind spots, which is precisely the failure mode P4 predicts. Third, each defect struck a different property the framework requires — P3 distinctiveness detection (a signal that could be evaded), P2 evidence-bound verdicts (a verdict without evidence), and monotonicity of the scoring functional (a downward jump at the worst input, §5.8) — suggesting the principles and properties have diagnostic, not merely constructive, value.

6.8System B: Audit and Build Ledger

System B’s record shows the same regime operating on a different substrate.

Fan-out audits. The subsystem audit (49 agents, 6 lenses, per-finding refutation) confirmed 43 findings — 2 high, 25 medium, 16 low — all fixed. The representative high finding was an O(N²) index-layout denial-of-service: a first scan of N=1000 records took 13.86s. The dead-UI audit (28 agents) confirmed 17 findings: 9 label-honesty issues, 1 bug, and 7 affordances requiring backend work; consistent with the dead-affordance rule (§6.3), dead buttons were disabled and honestly labeled rather than faked. A funnel audit produced 36 findings. A security audit using two independent adversarial lenses yielded 6 material fixes and the deliberately scoped verdict “robust for the local single-user configuration” — a bounded claim, not a blanket one.

Cross-vendor yield. A different-vendor cross-verification round produced 7 follow-ups, including a store-scan redesign that took a 2000-record first scan from 52s to 0.002s — a finding of a kind (asymptotic behavior at realistic scale) that per-function unit tests are structurally unlikely to surface.

A new-feature build. The pre-code adversarial design review’s 6/6 confirmed attacks (§6.5) reshaped the specification before implementation. The implementation then shipped with 261 tests green (up from 253), a 6/6 scope-guard pass, a 4-lens same-model review with 0 findings, and a different-vendor cross-verification with 0 must-fix items. A real-HTTP test of the live output surfaced 2 flagged changes — each with source evidence spans — and 2 open follow-ups: the feature’s core behavior, exercised end-to-end rather than asserted.

The time-bomb. Building this feature also exposed a defect in the verification layer itself: a test had hard-coded a date as “fresh,” and silently went stale when the real clock crossed a 7-day freshness threshold — a test that would begin failing (or worse, begin passing vacuously) purely through the passage of time. It was fixed, bringing the suite to 268 green. Like the default-font loophole, this is the verifier needing verification; unlike it, the adversary here was the calendar. The project’s rolling pytest counts — 93 → 115 → 183 → 216 → 226 → 228 → 242 → 246 → 253 → 261 → 268 — serve as the longitudinal spine of the ledger.

6.9Convergence as Corroboration

The two systems were built solo, months apart, for different products: one grades visual design; the other governs a knowledge corpus. Only the deterministic-adjudication lesson was carried forward deliberately from the reporting-system incident (§6.4). Yet under deployment pressure, both systems independently arrived at the same four-part architecture: deterministic adjudication (LLM proposes, code judges), cross-vendor adversarial verification before ship, a snapshot/verify-the-verifier safety mechanism, and an explicit human-escalation boundary for latent-need judgment. The projects themselves recognized the convergence, naming the recurring structures as one reusable pattern — System B’s grounding checker and System A’s deterministic scorer are documented as the same pattern with different substrates. Because that adjudication organ was the one lesson deliberately carried forward, the convergence is only partly independent; its weight rests on the other three organs, which re-emerged without being ported.

Within this paper’s n=1 genre, we interpret convergence carefully. It is not evidence that the architecture is optimal, nor that other operators would converge similarly. It is evidence of a weaker but still useful kind: when one operator’s honest deployment feedback loops were allowed to reshape two unrelated systems, the reshaping was not product-specific — the same governance organs grew twice. In research-through-design terms [8, 11], this is exactly the situation pattern languages exist to capture: a solution form that recurred across contexts, annotated with the forces that produced it.

Discussion

7.1The Feasibility Verdict: A Division of Labor, Not a Demotion

The title’s question now has a two-part answer supported by both the mathematics and the record. The governance and verification half of design judgment is achievable and formal: proximity-to-generic is a deterministic, bounded, (post-repair) monotone functional with a separation objective (§5), operable as a mandatory gate under sustained deployment (§6.6). The judgment half — latent-need fit, distinctiveness as a positive property — is deliberately not-yet-automated and not faked, and the argument of §4.5 and §5.7 is that it should not be faked: automating it today would manufacture confident, hollow verdicts, the work-slop the architecture exists to prevent. The boundary is a moving frontier, not a proven wall — it lowers only as genuine operationalization advances, never because automation pressure willed it.

“Decision-maker, not generator” may therefore sound like it promotes the AI; the architecture actually disciplines it. By decision-maker we mean something precise: the AI holds mandatory, gating authority over the operationalizable shell of the judgment, while the full decision remains a division of labor across deterministic code, an independent adversary, and a human. Across both systems, the LLM’s role is generative in a precise, bounded sense — generate candidates, critiques, questions, plans — while three other parties hold the judgment: deterministic code (scoring, arithmetic, pass/fail), an independent adversary (in practice a different-vendor model, an imperfect proxy for independence; refutation before ship), and the human (latent-need fit, taste, strategy, activation of autonomy). This is recognizably a descendant of mixed-initiative principles [10] and of levels-of-automation analysis [14], with one update those frameworks did not need: when the automation is a language model, the automation’s own account of its performance is inadmissible. System A’s PM gate distrusts agent self-reports of test success as a design axiom; System B forbids LLM self-grading outright. Overreliance, which interaction-level interventions try to mitigate in the human [5, 3], is here attacked structurally rather than behaviorally: an LLM’s account of its own performance is, by construction, inadmissible as gate-passing evidence.

7.2When Does Anti-Averaging Generalize?

Anti-averaging is the most domain-flavored of the five principles, and its generalization deserves honesty in both directions. It clearly transfers wherever outputs have an identity worth defending against a strong statistical prior: brand design, writing voice, editorial products, perhaps codebase architectural style. It transfers poorly where convergence to convention is the goal — regulated form design, safety-critical interfaces — although even there, a detector for “this looks like the model’s default rather than a considered choice” retains diagnostic value; the response to the signal changes, not the signal.

The deeper transferable insight is structural: the evaluator must be aimed at the specific failure mode the generator produces by default. For generative models, that failure mode is high-probability output [4] whose population-level effect is homogenization toward an average [6]. Generic evaluation criteria (contrast, spacing, validity) systematically pass averaged output — the founding observation behind System A — so an evaluator worth gating on must measure the delta from the default, not just conformance to rules.

7.3The Cost of Deterministic Scaffolding

The regime is not free, and we resist presenting it as such. The relevant trade is often mis-stated as determinism versus recall; it is not. System A matches colors by exact value rather than by perceptual ΔE distance — but a ΔE near-matcher would be equally deterministic, so the real trade is between a narrow exact rule and a broader deterministic detector. System A took the narrow rule, so a hex value one imperceptible step away from a framework default escapes the ai-default-color signal — a recall cost, not a determinism dividend. The default-font loophole was this trade collecting its fee — and the repair (base-family normalization) widened the deterministic net rather than reaching for a model, which we read as the pattern’s intended failure-and-repair cycle: when a deterministic check is evaded, broaden or strengthen the deterministic check; do not fall back to asking the model.

Cross-vendor verification costs money and latency, which is why both systems tier it (§4.4). Fan-out audits cost more still — 49 agents for one subsystem — and are reserved for milestones. And the scaffolding itself becomes a maintenance surface with its own defects: the false-clean sparse-input bug, the if overall > 0 guard, the time-bomb test. Our ledger suggests the honest conclusion is not that scaffolding eliminates defects, but that it relocates them into a smaller, more inspectable layer — and that this layer, too, needs an adversary (§6.7, §6.8). For a solo operator, the record indicates the trade is worth it: the regime is precisely what let one person ship autonomous evaluator changes on a daily cadence with no fabrication incident recorded across the deployment period. Whether the trade scales down to hobbyists or up to teams is an open question we cannot answer from n=1.

7.4Implications for Design-Tool Builders

Three implications follow for builders of AI design tooling. First, ship the grader, not just the generator: a tool that can explain why an output is generic, with named signals and a fail-closed “cannot assess,” changes the user’s relationship with generation more than another variant button does. Second, make evidence a type: System B’s verified/drifted/missing statuses and System A’s evidence-bound state-coverage checks both work because “claimed” and “shown” are different types in the system, and only one of them can pass a gate. Third, design the escalation boundary as UI: the human’s residual judgments (taste, strategy, latent fit) should arrive as explicit, evidence-attached escalations — the boundary is a feature to be designed, not a gap to be papered over.

Limitations and Threats to Validity

n = 1, first-person, self-reported. One operator built, operated, and is now reporting on both systems. This is disclosed as genre (§1, §6.1) [19, 13, 12], but its consequences bear listing plainly: selection effects in which episodes were ledgered; interpretation effects in how findings were classified; and the absence of any inter-rater check on judgments such as “confirmed finding” or “must-fix.” The convergence finding (§6.9) is especially exposed: two systems sharing one operator share that operator’s habits of mind, and convergence may reflect the operator as much as the problem. We mitigated where the regime allowed — different-vendor models produced or refuted many of the reported findings, and human sign-off rules exist precisely to check self-reporting — but the mitigations were designed by the same person they check.

No controlled comparison. We present no baseline in which the same work proceeded without the regime. Score improvements (e.g., 100→28 and 72→28 on slop inputs; separation currently +31.2) are before/after measurements on the systems’ own instruments, not comparisons against alternatives, and the instruments themselves changed across the period (that was the point). Claims of the form “deterministic adjudication eliminated recurrence” rest on 8 re-verifications in one production context.

Single toolchain and period. Both systems share a stack, a vendor pair, and a compressed time window (the dated ledgers cited here span July 2026 cycles). Patterns may behave differently with other model vendors, other stacks, or team settings.

Metric-count inconsistencies. The projects’ own documents report System A’s test-suite size in more than one way (a module count and a much larger assertion/subtest count that do not cleanly reconcile), and its design-system reference total appears as a range rather than a fixed figure. We have generalized these counts throughout rather than pick a favorable number, and we flag the underlying inconsistency here once: that a paper about evidence discipline inherited counting inconsistencies in its own provenance is an irony we prefer to disclose rather than smooth over.

The formalization models only the shell. The functional of §5 is a claim about proximity-to-generic (a one-sided proxy for slop-likeness), not about design quality: by its own honesty asymmetry (§5.7), a low score certifies only the absence of detected slop. Nothing in this paper formalizes — or claims to formalize — the latent core H; the framework’s answer to that core is escalation, not computation. That boundary can move as the shell grows (§5.7), but the framework does not pretend to have crossed it, and its value therefore rests partly on a component (human judgment) that is outside its formal guarantees by design.

Generality of the framework. Pattern languages are provisional, generative theory [8, 11]. We offer the five principles as candidates for others to instantiate and refute — the same epistemic status our systems grant any single reviewer’s verdict.

Conclusion

Can AI be trusted with design decisions, and how far can design judgment be made formal? The answer this paper defends is exact in its scope: AI as design decision-maker is feasible precisely to the depth that the judgment can be made deterministic and adversarially or humanly checked — and no further yet. The formalizable shell is real: the operationalizable shell of the “genericness sense” is a deterministic, bounded, (post-repair) monotone one-sided proxy for slop-likeness over typed design tokens, calibrated by a separation objective, and operable as a mandatory ship-gate. The boundary is equally real: the latent core — whether the work solves a real, latent need — is one-sidedly indicated but not-yet-computed and deliberately not faked, a frontier that moves as the shell grows rather than a proven wall, and a system honest about design judgment marks that refusal in its own code. Five requirements make the position buildable — an evaluative core with deterministic adjudication, an anti-averaging mandate, a different-vendor adversary, a snapshot mechanism that verifies the verifier, and a human standing at an explicitly marked boundary — and two systems, built solo and months apart for different products, grew the same governance organs — though from one shared origin lesson (§6.4), so only partly independently — which we read, on this n=1 record, less as proof that the architecture is optimal than as a suggestion that the problem rewards it. The generative capacity of current models is not in question. What our ledgers suggest is that the useful frontier for design tooling lies elsewhere — in machinery that can say no, say why, say cannot assess, and know which judgments were never its to make.

References

1. [1] Christopher Alexander, Sara Ishikawa, and Murray Silverstein. 1977. A Pattern Language: Towns, Buildings, Construction. Oxford University Press.
2. [2] Saleema Amershi, Dan Weld, Mihaela Vorvoreanu, Adam Fourney, Besmira Nushi, Penny Collisson, Jina Suh, Shamsi Iqbal, Paul N. Bennett, Kori Inkpen, Jaime Teevan, Ruth Kikin-Gil, and Eric Horvitz. 2019. Guidelines for Human-AI Interaction. In Proceedings of the CHI Conference on Human Factors in Computing Systems (CHI '19). ACM.
3. [3] Gagan Bansal, Tongshuang Wu, Joyce Zhou, Raymond Fok, Besmira Nushi, Ece Kamar, Marco Tulio Ribeiro, and Daniel S. Weld. 2021. Does the Whole Exceed its Parts? The Effect of AI Explanations on Complementary Team Performance. In Proceedings of the CHI Conference on Human Factors in Computing Systems (CHI '21). ACM.
4. [4] Emily M. Bender, Timnit Gebru, Angelina McMillan-Major, and Shmargaret Shmitchell. 2021. On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? In Proceedings of the ACM Conference on Fairness, Accountability, and Transparency (FAccT '21). ACM.
5. [5] Zana Buçinca, Maja Barbara Malaya, and Krzysztof Z. Gajos. 2021. To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making. Proceedings of the ACM on Human-Computer Interaction 5 (CSCW1). ACM.
6. [6] Anil R. Doshi and Oliver P. Hauser. 2024. Generative AI enhances individual creativity but reduces the collective diversity of novel content. Science Advances.
7. [7] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 1994. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
8. [8] William Gaver. 2012. What Should We Expect from Research Through Design? In Proceedings of the CHI Conference on Human Factors in Computing Systems (CHI '12). ACM.
9. [9] Bill Gaver and John Bowers. 2012. Annotated Portfolios. interactions 19, 4. ACM.
10. [10] Eric Horvitz. 1999. Principles of Mixed-Initiative User Interfaces. In Proceedings of the CHI Conference on Human Factors in Computing Systems (CHI '99). ACM.
11. [11] Kristina Höök and Jonas Löwgren. 2012. Strong Concepts: Intermediate-Level Knowledge in Interaction Design Research. ACM Transactions on Computer-Human Interaction 19, 3.
12. [12] Andrés Lucero, Audrey Desjardins, Carman Neustaedter, Kristina Höök, Marc Hassenzahl, and Marta E. Cecchinato. 2019. A Sample of One: First-Person Research Methods in HCI. In Companion Publication of the ACM Conference on Designing Interactive Systems (DIS '19). ACM.
13. [13] Carman Neustaedter and Phoebe Sengers. 2012. Autobiographical Design in HCI Research: Designing and Learning through Use-It-Yourself. In Proceedings of the ACM Conference on Designing Interactive Systems (DIS '12). ACM.
14. [14] Raja Parasuraman, Thomas B. Sheridan, and Christopher D. Wickens. 2000. A Model for Types and Levels of Human Interaction with Automation. IEEE Transactions on Systems, Man, and Cybernetics — Part A 30, 3.
15. [15a] Ben Shneiderman. 2022. Human-Centered AI. Oxford University Press.   [15b] Ben Shneiderman. 2020. Human-Centered Artificial Intelligence: Reliable, Safe & Trustworthy. International Journal of Human–Computer Interaction 36, 6.
16. [16] Qian Yang, Aaron Steinfeld, Carolyn Rosé, and John Zimmerman. 2020. Re-examining Whether, Why, and How Human-AI Interaction Is Uniquely Difficult to Design. In Proceedings of the CHI Conference on Human Factors in Computing Systems (CHI '20). ACM.
17. [17] J.D. Zamfirescu-Pereira, Richmond Y. Wong, Bjoern Hartmann, and Qian Yang. 2023. Why Johnny Can't Prompt: How Non-AI Experts Try (and Fail) to Design LLM Prompts. In Proceedings of the CHI Conference on Human Factors in Computing Systems (CHI '23). ACM.
18. [18] Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, Hao Zhang, Joseph E. Gonzalez, and Ion Stoica. 2023. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. In Advances in Neural Information Processing Systems (NeurIPS '23).
19. [19] John Zimmerman, Jodi Forlizzi, and Shelley Evenson. 2007. Research Through Design as a Method for Interaction Design Research in HCI. In Proceedings of the CHI Conference on Human Factors in Computing Systems (CHI '07). ACM.
20. [20] Arjun Panickssery, Samuel R. Bowman, and Shi Feng. 2024. LLM Evaluators Recognize and Favor Their Own Generations. In Advances in Neural Information Processing Systems (NeurIPS '24). arXiv:2404.13076.
21. [21] Barrett R. Anderson, Jash Hemant Shah, and Max Kreminski. 2024. Homogenization Effects of Large Language Models on Human Creative Ideation. In Proceedings of the ACM Conference on Creativity & Cognition (C&C '24). ACM.
22. [22] Terminology sources. “Workslop”: BetterUp Labs and Stanford Social Media Lab, “AI-Generated ‘Workslop’ Is Destroying Productivity,” Harvard Business Review, September 2025. “AI slop”: popularized by Simon Willison, May 2024.