From “I Know It When I See It” to Programming with Learned Semantic Primitives

An origin story, related research, and an exploratory specification.

Collaboration note: I developed this article collaboratively with GPT, using it as a research and writing partner. The argument and final editorial decisions are my own. If you want to save some reading see the simplified version here ELI5.

This is not a claim of inventing a new field.

It is a record of a line of thought.

Intent Palettes began as a discussion about helping ordinary people communicate design preferences to AI systems. They subsequently became a way of constraining the solution spaces explored by agents. Then they began to resemble domain grammars. Finally, encountering TypeSafe’s Jev suggested that the semantic distinctions defined by a palette might themselves become directly computable by learned primitives.

At that point the original interface idea had unexpectedly arrived in the neighbourhood of neurosymbolic programming, concept-based machine learning, probabilistic logic and domain-specific languages.

Much of that territory has been explored before.

What follows records how I got there, what appears to exist already, and the current form of the hypothesis.

---

Part I — Where Intent Palettes Came From

1. “I know it when I see it”

The starting problem was mundane.

People frequently know what they want when they see it while lacking the specialist vocabulary necessary to describe it.

The discussion arose from Ben Tossell’s Design Words idea.

Rather than expecting someone to know terms such as:

neo-grotesk
hard side lighting
high information density
editorial serif
slow spring easing

show them alternatives.

The interaction becomes:

show concrete alternatives
        ↓
human recognises what they prefer
        ↓
human selects / combines / adjusts
        ↓
system attaches semantic descriptions
        ↓
structured specification
        ↓
agent builds the result

The important observation was:

When humans possess perceptual judgment but lack domain vocabulary, let them specify intent by manipulating examples and compile their choices into an explicit semantic representation for the agent.

The problem was not really prompting.

It was turning tacit human judgement into machine-operable specification.

---

2. Why the name “Intent Palette”?

Several possible names were considered.

“Preference elicitation interface” was technically accurate but sounded like a survey.

“Example-based specification” described the mechanism.

“Visual specification” was too narrow because the same interaction could apply to sound, movement, typography, haptics, 3D form and many other things.

“Perceptual specification” seemed useful for the general process:

an interface where a person specifies intent by recognising, selecting, comparing and composing perceptible alternatives.

But the object itself needed a name.

The analogy that worked was a colour palette.

A colour palette presents meaningful things that can be selected and combined.

An Intent Palette would contain selectable pieces of intent:

lighting       [A B C D]
composition    [A B C D]
texture        [A B C D]
motion         [A B C D]

Hence the name:

Intent Palette — a palette whose selectable units are pieces of intent.

The interface through which they were assembled could be an Intent Composer.

That origin remains useful because the word palette still carries something important that terms such as ontology, schema or DSL do not.

A palette implies a bounded but composable space of meaningful alternatives.

---

3. The first abstraction: compile intent

The next step was to realise that the result should not merely be turned into a better prose prompt.

Instead:

human examples / selections
          ↓
 structured intent representation
          ↓
       compiler
     ↙    ↓     ↘
 prompt  API   tool parameters

The person is expressing intent in a representation convenient for humans.

The system compiles it into a representation convenient for whatever executes it.

That mattered because it stopped the idea being tied to prompting.

A person’s design choice could remain stable while the executor changed from:

LLM
→ image generator
→ Figma agent
→ web coding agent
→ some future system

The human interface had become an abstraction boundary between intent and implementation.

---

4. From one palette to a Palette Factory

The next change was to stop thinking about creating a new interface for every task.

Palettes could themselves become reusable knowledge artifacts.

That produced:

Palette Factory
      ↓
Palette Library
      ↓
Spec Composer
      ↓
Build Agents
      ↓
artifact

A mature palette entry might contain:

perceptual examples
semantic identity
applicability
trade-offs
constraints
incompatibilities
executable implementation
verification

A typography choice, for example, would not merely be a picture of some type.

It might encode:

identity:
    editorial-serif

appropriate-for:
    long-form
    magazines
    premium publishing

avoid:
    dense operational dashboards

implementation:
    font family
    line height
    tracking

Now the human sees the specimen.

The agent sees meaning and constraints.

The renderer sees implementation.

The palette is no longer just a preset collection. It has become a small piece of domain knowledge.

---

5. The second major shift: palettes for agents

Initially palettes existed because humans lacked vocabulary.

Then the complementary problem became obvious.

Agents possess too much possible vocabulary.

Tell a generative model:

Make this website look good.

and it has an enormous solution space.

Instead I can provide:

available layout vocabulary
available typography vocabulary
available spacing vocabulary
available motion vocabulary

The Intent Palette now serves a second function.

For humans:

“I know it when I see it.”

For agents:

“Here is the space of solutions worth considering.”

The palette becomes a bounded design search space with meaningful alternatives.

This connected the idea to a separate observation about AI-generated software: unconstrained generation tends toward statistically average solutions. Better results can come from first identifying legitimate solution families, their trade-offs and the constraints of the actual problem, then allowing the model to work inside that reduced space.

The palette therefore became not merely a communication device but a prior over useful solutions.

---

6. Beyond visual design

Once understood that way, nothing required Intent Palettes to remain visual.

Software engineering already contains palette-like knowledge:

design patterns
reference architectures
language idioms
testing matrices
security patterns
framework recipes
refactoring catalogues
standards

Existing knowledge is usually fragmented.

A book explains a pattern.

A framework documents an API.

A template gives one implementation.

A linter enforces a rule.

An ADR records one decision.

An Intent Palette could instead package alternatives as composable decision objects containing their applicability, constraints, trade-offs, implementation and verification.

The idea therefore shifted from perceptual selection toward:

structured solution-space selection.

---

7. Palettes begin to resemble grammars

Reusable choices naturally form hierarchies.

primitive
    ↓
composition
    ↓
pattern
    ↓
higher-level system

For example:

warm-side-light
        ↓
warm editorial portrait
        ↓
founder-profile photography
        ↓
publication visual language

I noticed at the time that this was beginning to resemble a design grammar.

That is an important step in hindsight.

A palette was ceasing to be simply a set of alternatives.

It was beginning to define which concepts existed and how they could combine.

---

8. LEAP 71 and layered palettes

A later discussion about LEAP 71 pushed this one step further.

LEAP 71’s broader engineering argument is that conventional CAD still largely asks computers to help humans draw geometry. Their approach instead begins further upstream: describe the engineering intent, constraints and physics, then let computation derive the resulting geometry.

Thinking about that process suggested that an Intent Palette need not be one flat menu of alternatives.

Palettes could form layers of progressively narrower semantic constraint:

mission intent
      ↓
system intent
      ↓
subsystem intent
      ↓
engineering constraints
      ↓
physics
      ↓
manufacturing constraints
      ↓
geometry

Each layer creates the legitimate decision space for the layer beneath it.

A propulsion system, for example, should not begin by exploring every geometry it is capable of generating. Higher-level choices may already have established:

mission:
    reusable orbital vehicle

propulsion objective:
    high efficiency

propellant:
    methane / oxygen

manufacturing:
    additive

thermal constraints:
    ...

material constraints:
    ...

Only then does a lower-level palette expose the design choices that still make sense.

This suggested a more powerful structure:

Palette A
defines intent and constraints
        ↓
Palette B
operates inside A's remaining space
        ↓
Palette C
further constrains B
        ↓
...
        ↓
implementation

The important idea is not merely hierarchy.

It is constraint propagation through layers of semantic decision spaces.

A choice made at a higher level changes which choices are valid or useful below it.

This is how a collection of palettes starts to become an engineering stack rather than a set of independent menus.

It also clarified why palettes could be useful to autonomous agents.

Instead of asking an agent to search an enormous undifferentiated possibility space, higher-level palettes progressively starve out irrelevant solution classes:

all possible solutions
        ↓
solutions compatible with mission
        ↓
solutions compatible with architecture
        ↓
solutions compatible with physics
        ↓
solutions compatible with manufacture
        ↓
small meaningful design space

The agent gains freedom inside progressively established boundaries, rather than freedom to reinterpret the entire problem at every step.

That layered-constraint model became an important precursor to the later idea of Intent Palettes as semantic boundaries.

---

9. The shared semantic layer

Another clue came from thinking about computer-use agents.

A computer-use system commonly performs something like:

pixels / DOM / accessibility tree
              ↓
       infer semantics
              ↓
       identify controls
              ↓
          take action

An Intent Palette seemed to perform almost the inverse transformation:

human-facing representation
          ↓
explicit semantics
          ↓
machine-operable intent

That suggested a more general architecture:

human-facing projection
          ↕
 shared semantic representation
          ↕
agent-facing capabilities

Humans and machines do not necessarily need the same representation.

They need different projections of the same underlying meaning.

At this point Intent Palettes had moved substantially beyond UI widgets.

They were becoming a candidate semantic interface layer.

---

Part II — This Idea Did Not Emerge in a Vacuum

Once I searched using the terminology of neighbouring research fields rather than the phrase “Intent Palette,” a substantial intellectual lineage appeared.

This materially changes how the idea should be presented.

10. Morphological charts: structured possibility spaces

One ancestor predates machine learning entirely.

Fritz Zwicky’s morphological analysis decomposes a design problem into important dimensions, lists possible alternatives for each dimension, and explores combinations of those alternatives.

Modern engineering descriptions still characterise morphological charts as a way of mapping the design space rather than directly solving the problem. They formalise available domain knowledge and expose combinations that might otherwise not be considered. (cambridge.org)

That is recognisably palette-like:

dimension A   [a1 a2 a3]
dimension B   [b1 b2 b3]
dimension C   [c1 c2 c3]

followed by composition.

Intent Palettes did not invent bounded combinatorial design spaces.

---

11. Design Galleries: “I know it when I see it” in 1997

An even closer HCI ancestor is the 1997 SIGGRAPH paper Design Galleries.

Marks and colleagues were dealing with multidimensional parameter spaces where people might easily recognise a desirable output but find it difficult to specify the parameters that produce it.

Their system automatically generated a broad selection of perceptually different results and arranged them so users could browse the space visually. (vcg.seas.harvard.edu)

That is extraordinarily close to the original perceptual-specification motivation behind Intent Palettes.

The important later difference is that I wanted the selected item to become portable semantic knowledge, not merely a parameter setting inside one application.

---

12. Neural Module Networks: learned primitives

In 2015–2016, Neural Module Networks explored another piece.

Instead of using one monolithic neural network, the system dynamically composed reusable learned modules corresponding to meaningful subtasks.

The authors explicitly described their goal as finding a small collection of modules capable of being assembled into the configurations needed by the task; the paper even refers to these as composable vision primitives. (openaccess.thecvf.com)

That is extremely close to my later intuition that machine learning might supply computational primitives rather than own the whole program.

---

13. DeepProbLog: neural predicates

DeepProbLog gets closer still.

It extends probabilistic logic programming with neural predicates.

A neural model can determine a probability associated with a symbolic predicate, while ordinary logical reasoning operates on the resulting probabilistic facts. (sciencedirect.com)

Conceptually:

neural perception
      ↓
probabilistic predicate
      ↓
ordinary symbolic program

This is already an implementation of something very much like:

semantic predicate
      ↓
probability
      ↓
deterministic composition

So the idea of an “ML if-statement” absolutely has serious precedent.

---

14. Concept Bottleneck Models: human concepts as an interface

Concept Bottleneck Models, introduced in 2020, force prediction through a layer of human-understandable concepts.

Instead of:

raw input
   ↓
black-box model
   ↓
answer

they construct:

raw input
   ↓
human concepts
   ↓
answer

Humans can inspect and even intervene on those intermediate concepts. (microsoft.com)

Later work has made those interventions interactive and uncertainty-aware. (ojs.aaai.org)

That is closely related to my notion of an explicit semantic layer shared between human understanding and machine computation.

The difference is orientation.

Concept Bottleneck Models primarily ask:

Can a model make its internal reasoning pass through human-understandable concepts?

Intent Palettes began by asking:

Can humans and machines agree on the domain concepts first and then perform computation through that interface?

Those are neighbouring directions toward a similar boundary.

---

15. DomiKnowS: perhaps the closest existing architectural relative

DomiKnowS deserves particular attention.

Its authors describe a framework in which users declaratively define domain knowledge as concepts, relations and logical constraints, then associate learning components with that symbolic structure. (aclanthology.org)

The project explicitly seeks abstractions for programs that learn from data while allowing domain knowledge to be formulated separately from the underlying learning algorithms. (hlr.github.io)

That is remarkably close to:

define domain concepts
define relationships
define constraints
        ↓
attach learned implementation
        ↓
reason / infer

DomiKnowS therefore already demonstrates a major part of the architecture I have been circling.

My path differs in several ways.

Intent Palettes began with human recognition and specification rather than model training.

They evolved toward reusable domain choice surfaces for both humans and agents.

They treat learned implementations as potentially replaceable runtime providers behind semantic contracts.

And they explicitly separate semantic judgement from permission and side effects in an agentic system.

But those are differences of emphasis and synthesis, not grounds for pretending the surrounding architecture is unprecedented.

---

16. Neurosymbolic programming and Scallop

There is an established field called neurosymbolic programming.

A major survey describes it as learning or constructing programs that contain neural modules alongside symbolic primitives. (bishtref.com)

Scallop turns this into an actual programming language.

It combines machine-learning components with a Datalog-derived declarative language capable of logical, probabilistic and differentiable reasoning. More recent descriptions state the separation explicitly: a Scallop program decomposes AI computation into learning modules and reasoning modules. (doi.org)

Again:

learned component
       +
symbolic program

is established territory.

---

17. DreamCoder: languages can themselves evolve

Another interesting relative is DreamCoder.

DreamCoder learns not only programs but reusable abstractions that effectively enlarge its domain-specific language over time.

Its authors describe expertise as acquiring languages for thinking about problems, with concepts built compositionally from earlier concepts. (arxiv.org)

This has an obvious connection to my earlier idea that a Palette Factory might notice useful recurring combinations and promote them:

primitive palettes
       ↓
compositions
       ↓
patterns
       ↓
higher-level vocabulary

The palette library itself could evolve.

Again, not an unprecedented idea.

But I arrived at it independently by thinking about reusable design knowledge rather than program synthesis.

---

18. TalkToModel: human intent compiled into a DSL

TalkToModel provides another striking parallel.

Its conversational interface translates user utterances into logical forms expressed in a structured programming language, which is then executed by the system. (nature.com)

That resembles the original Intent Composer:

human expression
      ↓
structured semantic representation
      ↓
execution

The difference is that Intent Palettes originally sought to help humans construct that semantic expression through recognition and bounded choice, rather than requiring language alone.

---

19. DSPy and LMQL: programming model calls rather than prompts

LLM engineering has independently moved toward similar abstractions.

DSPy replaces manually engineered prompt strings with declarative signatures describing input/output behaviour and reusable modules that determine how the operation is implemented. (arxiv.org)

That is close to my notion of:

semantic operation contract
        ↓
replaceable implementation

LMQL similarly provides a programming language in which model output can be constrained by types and finite choice sets, with the runtime enforcing those constraints during generation. (lmql.ai)

Neither is an Intent Palette.

But both demonstrate the general movement away from:

“write a clever string and hope”

toward:

“declare the computation and its contract.”

---

20. Vehicle: specifications in the meaningful problem space

Vehicle is particularly relevant to the semantic-boundary idea.

Its authors propose a typed DSL in which specifications for neural components are written in the semantically meaningful problem and result spaces, then compiled into representations suitable for training and formal verification.

Their stated advantage is that domain experts can read and check specifications without needing to understand the neural representation underneath. (drops.dagstuhl.de)

That is very close to the abstraction boundary I want:

domain meaning
      ↓
semantic specification
      ↓
implementation-specific representation

---

21. What appears to be the synthesis

After this search, it would be unreasonable to claim novelty for most individual pieces.

The following all have substantial precedent:

bounded design spaces
example-driven preference selection
human-readable concept layers
learned composable modules
neural predicates
probabilistic logic
neurosymbolic DSLs
typed model outputs
declarative model signatures
learned domain languages

What I have not yet found as one coherent architecture is the path I arrived at:

human perceptual specification
             ↓
explicit reusable domain semantics
             ↓
layered semantic constraints
             ↓
shared human-machine representation
             ↓
bounded solution/action spaces for agents
             ↓
typed learned semantic operations
             ↓
replaceable implementations
             ↓
deterministic composition and authority

That may exist under terminology I still have not found.

This document should therefore be understood as a synthesis and exploratory architecture, not a priority claim.

---

Part III — Jev Changes the Shape of the Idea

22. A missing computational primitive appears

TypeSafe’s September 2026 introduction of Jev supplied a piece that my earlier palette work lacked.

TypeSafe describes Jev as:

a “frontier-intelligence function call”: unstructured state in, typed probabilistic decisions out.

Jev exposes three primitive question forms:

Choice
Score
Noul

and recommends asking atomic questions and composing their answers in ordinary code. (typesafe.ai)

TypeSafe explicitly describes the intended use as “smart if-statements”: fuzzy decisions such as classifying, routing, scoring and branching embedded inside conventional software. (typesafe.ai)

Their architectural documentation goes further:

TypeSafe is designed to sit within a larger system, powering decisions with AI.

and describes complex behaviour as compositions of discrete atomic decisions. (docs.typesafe.ai)

That immediately connected to Intent Palettes.

---

23. Semantic boundaries and semantic primitives

The clean separation became:

Intent Palette
    defines semantic boundaries

Learned Primitive
    computes fuzzy meaning within them

Harness
    determines consequences

For example, a palette may establish:

NextAction =
    inspect
    test
    edit
    explain
    escalate
    stop

That is the semantic type of the decision.

A learned primitive can then calculate:

Choice<NextAction>(current_state)

inspect     .04
test        .71
edit        .12
explain     .05
escalate    .07
stop        .01

The model did not invent test.

It did not decide that delete_repository should exist.

It did not determine what executing test means.

The semantic environment already established those things.

The learned system performed one fuzzy judgement inside the permitted semantic space.

---

24. The stronger formulation

At this point the Intent Palette starts looking less like a menu and more like a semantic type/interface system.

The mapping becomes:

Programming concept	Intent Palette analogue
data types	semantic entities and states
enums	bounded intents or actions
functions	semantic operations
signatures	contracts with semantic primitives
predicates	learned semantic tests
return values	probabilities, scores, choices
grammar	valid composition of concepts
control flow	deterministic harness
runtime	ordinary software plus learned implementations

For example:

Message
Customer
Risk
Intent
Action

with operations:

classify_intent(Message)
    -> Distribution<Intent>

assess_risk(Message, Customer)
    -> Score<Risk>

requires_review(Message)
    -> Probability

choose_action(Message, AllowedActions)
    -> Distribution<Action>

The implementation of assess_risk might be Jev today, another classifier tomorrow, or deterministic software where appropriate.

The contract is more fundamental than the model implementing it.

---

Part IV — Exploratory Specification

25. Thesis

An Intent Palette is a typed semantic interface that defines the concepts, distinctions, permissible operations and possible outcomes relevant to a bounded problem domain.

Learned computational primitives operate within those semantic boundaries.

Deterministic software remains responsible for composition, control flow, permissions, side effects and consequences.

In compact form:

Intent Palette
    defines the semantic world

Learned Primitive
    resolves fuzzy meaning within that world

Harness
    determines what happens as a consequence

The central claim is:

Machine learning should not necessarily be the program. It can instead supply semantic computational primitives to programs.

---

26. Core model

                 DOMAIN
                   │
                   ▼
          ┌──────────────────┐
          │  INTENT PALETTE  │
          │                  │
          │ semantic types   │
          │ legal concepts   │
          │ operations       │
          │ output spaces    │
          │ constraints      │
          └────────┬─────────┘
                   │
          semantic contracts
                   │
        ┌──────────┼───────────┐
        ▼          ▼           ▼
    Predicate    Choice       Score
        │          │           │
        └──────────┼───────────┘
                   ▼
          typed semantic result
                   │
                   ▼
             deterministic
                 harness
                   │
                   ▼
                 action

The palette does not need to know which machine-learning system implements an operation.

Possible implementations include deterministic rules, Jev, specialist classifiers, embedding models, rankers, frontier language models, humans, or systems that do not yet exist.

---

27. Semantic types

An Intent Palette defines domain-relevant types.

Examples:

Message
Customer
CustomerIntent
Urgency
Risk
NextAction
Evidence
InvestmentThesis

A bounded semantic type might be:

CustomerIntent =
    BUY
    OBJECT
    REQUEST_INFORMATION
    CANCEL
    UNKNOWN

A scale might be:

Urgency =
    LOW
    MEDIUM
    HIGH
    CRITICAL

An action space might be:

NextAction =
    INSPECT
    TEST
    EDIT
    EXPLAIN
    ESCALATE
    STOP

An action outside that set does not exist within that palette.

---

28. Learned computational primitives

The useful initial family appears small.

Predicate

Predicate<T> -> Probability

Example:

requires_human_review(Message) -> 0.92

Intuition:

semantic IF

Choice

Choice<T> -> Distribution<T>

Example:

classify_intent(Message)

BUY                  .06
OBJECT               .72
REQUEST_INFORMATION  .18
CANCEL               .01
UNKNOWN              .03

Intuition:

semantic SWITCH

Score

Score<T, S> -> S

Example:

assess_risk(Action) -> .81

Intuition:

semantic MEASURE

Rank

Rank<T> -> Ordered<T>

Example:

rank(
    [inspect_logs, rerun_test, edit_source, ask_human],
    by="most useful diagnostic action"
)

Intuition:

semantic COMPARATOR

Retrieve

Retrieve<Q, T> -> Set<T>

Example:

retrieve(
    current_problem,
    prior_conversations
)

Intuition:

semantic LOOKUP

Other possible primitives include similarity, anomaly detection, policy selection, state-transition prediction and generation.

They should earn their place rather than becoming an excuse to label every AI operation a primitive.

---

29. Composition remains ordinary computation

Semantic primitives should not replace precise computation.

For example:

urgent =
    assess_urgency(message)

refund =
    is_refund_request(message)

if refund > .95
   AND urgent > HIGH
then
    route_to(REFUND_ESCALATION)

AND, OR, arithmetic, thresholds, state machines, loops and permissions remain deterministic where their semantics are already known.

The principle is:

Use learned computation where meaning is fuzzy. Use deterministic computation where the operation is already precise.

---

30. Semantic contracts

A palette operation is a contract.

assess_risk(
    action: Action,
    context: CurrentState
) -> Score<Risk>

The caller should not care whether the implementation uses:

Jev
specialist model
LLM
rule system
human judgement
ensemble

This produces an abstraction boundary around intelligence:

application
     │
     ▼
semantic contract
     │
 ┌───┼───────────────┐
 ▼   ▼               ▼
Jev  rules       frontier model

Implementations can improve without requiring the domain model to be rewritten.

DSPy’s signatures point toward a similar separation for LLM pipelines, while DomiKnowS already separates domain declarations from learning algorithms. Intent Palettes would extend that style of separation to a reusable domain-facing semantic interface. (dspy.ai)

---

31. Uncertainty is a first-class value

Instead of:

intent = OBJECT

prefer:

OBJECT               .63
REQUEST_INFORMATION  .31
UNKNOWN              .06

The surrounding system can then decide:

high confidence
    automatic action

medium confidence
    verification

low confidence
    gather evidence / better model / human

The thresholds are domain decisions.

The semantic primitive supplies judgement.

It does not decide how much risk the system is permitted to tolerate.

This is especially compatible with TypeSafe’s emphasis on calibrated probabilities and confidence. (typesafe.ai)

---

32. Judgement is not authority

Learned primitives should preferably be pure semantic operations.

They answer questions.

They should not automatically possess authority to produce consequences.

Bad boundary:

model:
    decides payment is suspicious
    blocks account
    emails customer

Preferred boundary:

model:
    suspicious(payment) -> .93

policy:
    if probability > threshold
       AND account policy permits action
    then request review

The harness owns authority.

The primitive supplies judgement.

---

33. The invariants

A serious implementation should preserve several principles.

Semantic boundaries should be explicit.

Output spaces should be bounded where the domain permits them to be bounded.

The semantic contract should remain conceptually distinct from the model implementing it.

Uncertainty should not silently become certainty.

Learned judgement should not automatically confer permission to act.

Operations whose meaning is already deterministic should remain deterministic.

And the path from semantic judgement to consequence should remain inspectable:

operation invoked
implementation used
context supplied
result returned
confidence
policy applied
eventual action

---

34. What this is not

Intent Palettes are not merely prompt templates.

Prompts may implement an operation, but they are not the abstraction.

They are not merely tool schemas.

A tool schema says what an action looks like. A palette describes the semantic distinctions that make an action appropriate.

They are not agent personalities.

They are not an attempt to replace conventional software with AI.

They do not make machine learning infallible.

And they should not become universal ontologies.

The useful unit is probably a bounded domain.

---

35. Is this a programming language?

Not necessarily.

At the current level an Intent Palette looks more like:

domain vocabulary
+
type system
+
interface definition
+
semantic operation set

than like Python or Lisp.

But add:

composition
binding
branching
sequencing
reuse
modules
execution semantics

and it begins to become a genuine domain-specific language.

For example:

WHEN
    requires_review(message) > .90

AND
    urgency(message) >= HIGH

THEN
    CHOOSE next_action
    FROM ReviewActions

At that point the distinction between palette and semantic DSL becomes increasingly thin.

---

36. Where Lisp fits

The architecture is language-independent.

Lisp is nevertheless an unusually attractive laboratory because Lisp makes it cheap to invent little languages.

Code and symbolic data share the same structural representation.

Macros let new constructs be added without first building a complete compiler and parser.

A possible surface syntax might look like:

(defpalette customer-service

  (type intent
    buy
    object
    request-info
    cancel
    unknown)

  (semantic-predicate refund-request?
    (message)
    :returns probability)

  (semantic-choice classify-intent
    (message)
    :returns intent)

  (semantic-score urgency
    (message)
    :scale '(low medium high critical))

  (action next-action
    inspect
    respond
    escalate
    stop))

The implementation behind:

(classify-intent message)

could be Jev, an LLM, a conventional classifier or something else.

Lisp is therefore potentially a good prototyping environment for the language-design question.

It is not part of the definition.

---

37. A repository-agent example

A repository palette might define:

FailureType =
    AUTH
    NETWORK
    DEPENDENCY
    TEST
    SOURCE
    UNKNOWN

NextAction =
    INSPECT
    TEST
    EDIT
    EXPLAIN
    ESCALATE
    STOP

Operations:

classify_failure(logs)
    -> Distribution<FailureType>

requires_human_review(state)
    -> Probability

rank_diagnostics(actions, state)
    -> Ordered<Action>

assess_change_risk(diff)
    -> Score<Risk>

Execution:

logs
  ↓
classify_failure
  ↓
AUTH .91
  ↓
deterministic policy
  ↓
AUTH failures cannot trigger source edits
  ↓
allowed palette narrows to:
    inspect_credentials
    explain
    escalate
  ↓
rank permitted actions
  ↓
harness executes permitted action

The model never possessed an unlimited action space.

---

38. What remains genuinely difficult

The difficult part is no longer seeing that the pieces can be assembled.

It is deciding where to cut the semantic world into primitives.

Too broad:

decide_what_to_do()

and I have recreated the unconstrained agent.

Too narrow:

is_the_third_word_negative()

and the abstraction becomes unusable.

Semantic granularity may therefore be one of the central design problems.

Several other questions should remain deliberately unresolved.

Does explicit semantic typing genuinely improve reliability, or merely add ceremony?

Are semantic primitives reusable enough to justify the abstraction?

Can implementations really be swapped without changing the meaning of the operation?

Are their probability estimates calibrated well enough to govern consequential actions?

What belongs in the palette and what belongs in the harness?

Can useful complex behaviour actually emerge from composition of bounded operations without simply recreating a giant reasoning loop one layer higher?

---

39. Falsifiable claims

The idea is useful only if it can fail.

A bounded semantic operation should be easier to test than an open-ended agent prompt.

Explicit output types should eliminate classes of structural failure.

Small semantic operations should sometimes permit cheaper specialised models to replace frontier models.

Separating judgement from authority should reduce the blast radius of model errors.

A well-designed semantic contract should allow implementations to change without rewriting domain logic.

And sufficiently complex intelligent behaviour should be composable from bounded semantic operations in at least some useful domains.

If those claims fail in practice, the concept should change with the evidence.

---

40. Current working definition

The present formulation is:

An Intent Palette is a typed semantic interface that defines the meaningful concepts, distinctions and permissible operations of a bounded problem domain, allowing humans, deterministic software and learned computational primitives to operate on a shared semantic representation.

The shorter form is:

Intent Palettes are typed interfaces for programming with learned computation.

But that definition should be understood as the end of the journey so far, not its starting point.

The actual evolution was:

“I know it when I see it”
        ↓
example-based specification
        ↓
Intent Palette
        ↓
portable structured intent
        ↓
Palette Factory / Library
        ↓
bounded search space for agents
        ↓
domain decision grammar
        ↓
layered semantic constraints
        ↓
shared human-machine semantic layer
        ↓
typed semantic interface
        ↓
learned computation inside the boundary

That history is part of the idea.

---

ELI5 (the simple version)

Normal computers are very good when instructions have exact meanings.

You can write:

if temperature > 30
    turn fan on

because the computer knows exactly what 30 and > mean.

But many important decisions are more like:

if this customer sounds genuinely upset
    get a human involved

What exactly does genuinely upset mean?

Machine-learning systems are increasingly good at answering questions like that.

Today the problem is often solved by giving one giant AI everything:

Read the message.
Understand what is happening.
Work out the possible choices.
Decide what to do.
Do it.

Intent Palettes propose splitting those responsibilities apart.

First define the little semantic world:

CustomerMood =
    calm
    confused
    annoyed
    angry

Then let a learned primitive answer one small fuzzy question:

Which mood best matches this message?

calm       2%
confused   8%
annoyed   25%
angry     65%

Then ordinary software decides what happens:

if angry > 90%
    request human review

The AI decides what the message means within the defined space.

The software decides what that judgement is allowed to cause.

The palette might contain nouns:

Customer
Message
Risk
Action

and operations:

classify
score
rank
retrieve

Some of those operations could be powered by machine learning.

Others might be ordinary software.

The program should not care unnecessarily which implementation sits underneath them.

And the palettes themselves can be layered.

A high-level palette might establish the mission.

That constrains the architectural palette beneath it.

That constrains the engineering palette.

That constrains the manufacturing palette.

Eventually:

big possibility space
        ↓
mission constraints
        ↓
architecture constraints
        ↓
engineering constraints
        ↓
physical constraints
        ↓
small meaningful possibility space

Each palette does not need to solve the whole problem.

It only needs to define the meaningful possibilities at its level and pass a narrower problem to the next.

So the idea is not:

replace software with AI.

It is closer to:

software
 ├── arithmetic
 ├── databases
 ├── files
 ├── networking
 ├── semantic predicate
 ├── semantic choice
 ├── semantic score
 ├── semantic ranking
 └── generation

Machine learning becomes another kind of computation available to software.

The Intent Palette defines the bounded language in which that semantic computation is allowed to occur.

And oddly enough, that idea started because somebody wanted an easier way to say:

“Make it look like that one.”