Tacit — A Haptic Vocabulary for State Over Time

_OVERVIEW

Kill the premise first

Before two weeks of design, two hours to learn whether the idea was possible at all.

Everything rests on one premise: a plugin must reach the hand while the user works somewhere else. If haptic delivery were scoped to the host application — the way notifications, focus and media keys usually are — no vocabulary for background tasks could exist. So the first build was not the plugin. It was a probe designed to kill the project cheaply.

Fig. 02 — the ecosystem, every edge observed, none inferred

Where the user’s attention was · five applications, none of them the host

WindowsTerminal claude Figma chrome explorer

● two of them ship their own Logi profile, and the events fired anyway

Attention above · sensation below

The plugin ecosystem, as the SDK describes it — and the developer is inside it

Third-party developer the actor, not the audience

Marketplace never travelled

nothing here is published yet

registers an event source, HasHapticMapping declared

Logi Plugin Service loads what it is pointed at

a file anything can append to

Tacit DefaultEventSource.yaml · eventMapping.yaml

Three writers one line of text each

MX Master 4 one actuator

the thumb

the same person, in both lanes at once a .link file — written into a directory that did not exist yet · friction 09 a semantic name resolves to one of fifteen waveforms

Delivery is unscoped the pulse arrives whatever owns the screen — and an active third-party profile does not suppress it 14 ms · six runs · 31 events

Walking the developer journey

The spine of the case: the plugin exists so that these observations could exist. Every stumble was logged raw, in order, never edited — and the log owns our own mistakes in the same table.

Fig. 03.1 — the journey, drawn as a service blueprint what reaches the user sits one line above what the platform carries

Install Configure Start While it runs It needs you It ends Evidencewhat actually reaches the user a tile that names nothing it reports on one on/off switch, inside the intensity preference one pulsesharp_state_change a beat, every 15 ssubtle_collision an off-beat knockknock one pulse, or three at 450 mscompleted / angry_alert Userwhat the person does installs the plugin looks for its settings starts a long task switches application, and works comes back to answer it reads the outcome in the thumb Line of interaction Frontstagewhat the user could see or feel happening Options+ plugin managerTacit appears, and says nothing Plugin Settings dialog — manifest metadata, and the language the dialog is written in the actuator fires the actuator fires on the beat the actuator fires off the beat the actuator fires Line of visibility Backstagewhat runs where the user cannot see it Logi Plugin Service loads the plugin from a .link file settings store, encrypted and keyed, with no surface a writer appends one line to the channelRaiseEvent(taskStarted) the heartbeat, sequenced in TaskRunnerRaiseEvent(taskTick) the only state allowed to interruptRaiseEvent(taskNeedsInput) the three-pulse figure is sequenced in codeRaiseEvent(taskCompleted | taskFailed) Line of internal interaction Supportthe platform underneath, and what it does or does not carry LogiPluginTool · PluginApi.dllMarketplace, never travelled plugin settings API — ActionEditor, reachable only from a bound action DefaultEventSource.yamlfive semantic names — ours, not the platform’s HasHapticMappingdeclared in LoupedeckPackage.yaml eventMapping.yamlone semantic name to one primitive fifteen shipped primitives, none of them authorable

And below all three lines, the actor the platform depends on — the five findings, in journey order:

The developera third party, outside the company, working only from what is published

1The configuration model assumes a plugin is a collection of things you pressthe user meets it as a control that is not there 2The documentation is silent exactly where a decision depends on itit decides whether the plugin is attempted 3The tooling reports state that is not trueit decides whether the developer trusts what they built 4The first build of the first project does not compileit decides whether there is a plugin at all 5Fifteen primitives, and no way to know what any of them feels likethe user meets it as the wrong pattern for the state

The method is a friction log with three disciplines. Rows are appended at the moment of the stumble, not reconstructed later. A who column separates two friction profiles — the designer’s and the AI’s, because they stumble differently and the difference is data. And a verdict column marks our own inexperience as ours: of 39 rows, 33 are documentation or platform gaps, 5 are our gap, 1 stays unclear.

Designing the vocabulary

The instrument that walk was made with, designed in the open. Literature before design: the vocabulary encodes on time, never on texture — and the reason is a ranking, not a taste.

The decisions carry their reasons. Silence is cheap and dangerous — a run that ends in silence and a run that died look identical, which is why completed exists as a positive signal. needsInput violates the cadence on purpose: everything else lands on the beat, so the one state that needs you lands off it. The escalation for an ignored prompt contracts to a plateau rather than climbing forever — an ambient channel that grows into an alarm has changed category.

And one number was found by hand: the figure gap is 450 ms, not the 220 ms it started at. At 220 the second and third pulses of a figure never reached the actuator — the mechanical floor sits an order of magnitude above the 10 ms perceptual floor the literature offers. Nothing in the SDK documentation mentions it.

The architecture is three layers, deliberately: semantic names in code, the name→waveform mapping in configuration — so revising it after user testing is an edit, not a rebuild — and the fifteen shipped primitives underneath. A design-tokens bridge, applied to a sense that design tools cannot yet preview. The two layers we ship are small enough to read whole:

events:
  - name: taskStarted
    # fires once, and establishes what every later pulse is about
  - name: taskTick
    # the beat, not a message — its absence is what carries meaning
  - name: taskNeedsInput
    # the only state allowed to interrupt
  - name: taskCompleted
    # finished, and it worked
  - name: taskFailed
    # ended, and it did not work

haptics:
  taskStarted:    { DEFAULT: sharp_state_change }
  taskTick:       { DEFAULT: subtle_collision }
  taskNeedsInput: { DEFAULT: knock }
  taskCompleted:  { DEFAULT: completed }
  taskFailed:     { DEFAULT: angry_alert }

  # completed and mad are never the pair — they were
  # reported as the two closest patterns on the device,
  # and they are the two states that must never be confused.

Testing an ambient signal

An ambient signal cannot self-test: the author already knows which state he wrote into the channel, and discrimination is not detection. The harness has to remove the knowing.

The blind harness writes a random terminal state — completed or failed — and logs which one it was only after the guess is spoken. Twenty trials across three rounds, including at the Subtle intensity setting, the one a user in flow would actually keep: 20 of 20. And once, unarranged, the vocabulary simply got used for an afternoon of real work — which is not a result, but it is the reason the work felt finished.

Shipping it — the findings close on ourselves

Publication was not an epilogue. Preparing the plugin for the Logi Marketplace turned the field observations back on our own manifest — and fixed there what the log had reported everywhere else.

Fig. 06.1 — the loop that closes on ourselves friction observed → decision taken, on our own plugin

the log 39 rows, observed in the open

→

our own manifest decisions 37–40 — fixed here first

→

the Marketplace submitted — the working install route

→

other hands the field study, unblocked

and the field writes the next rows

The four closings, one by one

friction 25 · the build worked from one folder only → decision 37 · intermediates pinned — the scaffold’s own trap, fixed by the fix the log proposed

friction 27 · the scaffold declares devices that exclude the device haptics needs → decision 38 · the manifest declares ActionsRing — corrected the day it gained a visible consequence

friction 39 · the accepted device vocabulary exists only inside the DLL → found by reflection during submission prep — an unknown name parses to None, silently

the macOS claim · packaged, never run → decision 39 · v1 declares Windows only — withdrawn untested rather than submitted untested

Fig. 06.2 — the last change before submission a store listing is a surface too

V1 · crossbar is the rhythm cut — a row of the register now

V2 · pulse through the stem cut — a row of the register now

V3 · count beneath the mark the pick — a T over three dots

shipped the scaffold’s puzzle piece, retired — decision 40