Parameter vocabulary

The mono face in this product carries five different kinds of string. Before add-param-name it carried all of them the same way, and two things followed that you could see on one screen: in a grid row reading gl / de the name and the value were the same string in the same face, and the only chipped mono string in the whole application was the drill-in's continuation token — a value. The strongest mark in the vocabulary was spent on the thing a reader can neither type nor change.

One sentence, learnable from one grid row:

Only the name wears a tag.

Treatment	Means	Example	Rendered by
Flat sunk tag, mono, radius sm, no border	A parameter you can set	gl	ParamNameComponent
Bare mono in ink	The value it holds	de	the value cell, the address, the code sample
Bare mono in accent-line	A token handed to the reader	YOUR_API_KEY	ParamTableComponent#value_classes
Ringed pill, radius lg	Literal text in a response	"organic_results"	the inline-code chip (design/library/inline-code.html)
Sans	Prose about either	Country of the search.	everything else

Why a tag, and why not the inline-code chip

The inline-code chip already exists and already chips a mono string: sunk fill, an inset ring in line-strong, radius lg. It means this is literal text — a JSON key, a header, a string you would type verbatim. A parameter name is not literal text; it is an entity in the catalog, with a type, a requiredness, a default and a page of its own. Rendering both the same way would be the mistake this rule fixes, one level up.

So the parameter tag is the flatter, tighter sibling: no ring, radius sm, 1px/6px padding. The constraint that actually decides the shape is the grid — twenty tags down the key column have to read as a column of names, not as twenty widgets, and a ring on each would be twenty extra rectangles inside a table that is already ruled on both axes.

Not a colour instead, either. The accent is already spent on handed-in tokens (the one distinction in the value column that carries meaning) and the danger role on requiredness. A third colour with a third meaning inside one row is a legend, not a design.

What is deliberately not a parameter

The rule is about parameters, not about monospace. These are all mono, none of them is a parameter, and none of them wears the tag:

• the endpoint path in the address — where the request goes, not something it carries
• engine ids on the docs index and the landing pages — values of engine
• any path into a response (shopping_results[0].product_token) — response keys belong to what came back, and the numbered JSON lines already give them their own colour role
• displayed links, answer sources and prices inside a response — result data that happens to look technical

Response keys are the closest call and the answer is still no: two chips on one screen with two meanings is the problem restated.

Requiredness is one mark, on every surface

It used to be one per surface: the grid said it with req in its gutter, the reference with a Required pill in a column of its own, a form field with the badge beside its label — and the tag drew no marker on any of them, because each had already said it another way. Three vocabularies for one property of one catalog, two of them visible in the same scroll on an engine page, and a reader who learned the grid learned nothing about the reference.

Now the mark is the tag's, wherever a name is written: the grid's key column, the reference, the rail, prose. The gutter went back to answering the one question it is for — does this parameter travel? — and a row with no choice about that shows nothing there at all. The reference's requirement column is gone, and with it the word "Optional" restated on four rows in five; absence of the mark is what says optional, on every surface equally.

A form field keeps its badge. A label above a control is not a name in a table, and the badge is doing work there the asterisk cannot: it sits beside the field a reader is about to fill, not inside a column they are scanning.

Enforced, not reviewed

test/conformance/param_name_conformance_test.rb fails on a parameter.name rendered inside a hand-written font-mono class, naming the file and the line, and on any class list that pairs the mono face with the sunk fill outside this component. It catches the shape the grid actually had, where the class and the name were nine lines apart, and the shape the translations had, where both were arguments to one tag.code call. Consistency by review does not survive twenty call sites.

The component

The same tag, on the surfaces the rule names: