KN-Deckline — Future Concepts & Parking Lot

A running parking lot for KN-xx Deckline catalog concepts (KN-86, Toneline, Statline, Gridline, and future models) not yet scoped into a sprint. Ideas here are evaluated, not committed. Promote to a gameplay spec, ADR, or Notion task when ready to advance.

Last updated: 2026-04-25

1. Morse Code Capability Module

Status: Concept — 5 pitches generated by Gameplay Design agent. KEYTAP recommended as lead.

Why it fits: The YM2149 PSG is already a communication instrument, and the 30-key layout supports a clean dit/dah mapping (Q/A for dit, W/S for dah) via the existing hold-detection input system. Morse honors the 1986 operator fiction and opens an entire communication layer in the capability model that’s missing from current launch titles.

Pitch Summaries

KEYTAP — Espionage Comms Officer (recommended lead)

You’re a handler running field operatives from a NOC. Receive Morse bursts from agents, verify they aren’t HUNTER traps, tap back instructions under trace-window pressure. Strong phase-chain fit: briefing input for ICE BREAKER, BLACK LEDGER, PATHFINDER.

DEADMAN — Dead-Letter Box

Solo tradecraft. Plant deck at a drop, decode a slow encoded transmission against a 4-minute heat timer, verify sender via handshake, tap back a 6-char confirmation. Paranoid, meditative. Thematic counterweight to KEYTAP (isolation vs. command).

SIGNAL — Linguistic Eavesdropping

Don’t break the cipher — read its metadata. Infer message type, length, urgency, and relationships from statistical rhythm of encrypted Morse. Most cerebral; works as a recon phase feeding other modules.

IRONBOX — Real-Time Morse Duel

Adversarial challenge/response against an NPC operator. Tight timing, escalating difficulty, win 3 cycles to claim the channel. Gates higher-threat contracts. Most arcade-like.

GHOSTWRITER — Forensic Reconstruction

Posthumous analysis of a burned agent’s corrupted final transmission. Reconstruct from context, identify the sender by their unique Morse “fist.” Narrative and melancholic.

Recommendation

Lead with KEYTAP (cleanest fantasy, best input mapping, strongest cross-module chain connectivity, teaches real Morse fluency through encoding). Pair with DEADMAN as thematic diptych to establish Morse as a first-class citizen in the capability model.

Next Steps (when advanced)

Full gameplay spec for KEYTAP in docs/gameplay-specs/
Lisp paradigm revision pass to confirm key semantics (Q/A, W/S) don’t collide with existing module conventions
Audio design review: dit/dah pitch, spacing, and feedback model on the YM2149
Prototype the Morse input event model in the emulator before committing to hardware constraints

2. Signed Universal Deck State (Anti-Tamper for Credits & Reputation)

Status: Concept — evaluated as an alternative to a blockchain-based ledger. The Deck State struct itself is canonical (see KN-86-Capability-Model-Spec.md §Universal Deck State); the signing / hashchain layer described below is the novel parking-lot proposal.

Problem: Credits and reputation in the Universal Deck State need to be tamper-resistant. Players shouldn’t be able to hand-edit save files to give themselves 50,000¤ or max reputation.

Blockchain evaluation: Rejected for KN-86 infrastructure.

Production target (Pico 2, 520KB SRAM, 4MB flash, no network stack in current spec) cannot run a chain node.
Breaks 1986 period fiction — blockchain is a 2009+ technology.
Operational burden: key custody on a $4 MCU, transaction latency, fees, permanent infrastructure dependency for a product meant to still work in 10 years.
Solves a much bigger problem than we actually have.

Recommended approach: Signed local state + append-only audit log

Device key: Derived from the Pico 2 unique chip ID (factory-burned). Firmware signs the Universal Deck State on every write.
Append-only event log: Every credit earn/spend and reputation change is a signed event appended to a log. Hash each entry with the previous entry’s hash (Merkle-style chain). Tampering with any entry invalidates everything after it.
Validation on load: Firmware verifies the signature and hashchain on boot. A mismatch surfaces as a corrupted-deck message; operator is prompted to restore from the last valid state or reset.
Optional sync: When online (emulator, future networked hardware), sync the signed log to a server-authoritative ledger for cross-device continuity and cheat detection.

Bonus — diegetic opportunity:

Expose the hashchain as UI fiction. A “credit ledger” screen showing the audit log with hash prefixes gives the immutable-ledger aesthetic without the infrastructure cost. Operators love this stuff; it reinforces the cyberpunk tradecraft vibe.

Separate idea worth keeping:

A gameplay capability module built around a fictional 1986 “distributed reputation network” — operators signing attestations for each other over modem, simulated locally. Blockchain as narrative, not plumbing. Possible companion to KEYTAP/DEADMAN.

Next Steps (when advanced)

Write an ADR documenting the rejection of blockchain and the signed-state approach
Embedded Systems agent: sketch the signing + hashchain implementation for Pico 2 (key derivation, flash write patterns, verification cost)
Decide whether server-side sync is in scope for v1 or deferred
UI mock: operator-facing ledger screen with hash-prefix display

3. 8-Digit 7-Segment LCD on Prototype Keyboard Plate

Status: Subsumed by CIPHER-LINE (2026-04-25) — see ADR-0015 and KN-86-CIPHER-LINE-Grammar-Framework.md. The CIPHER-LINE auxiliary OLED’s Row 4 contextual surface (seed capture / gameplay timer / mission meta) renders entropy displays, reputation tickers, and cartridge signatures at higher fidelity than a 7-segment add-on, and the SSD1322 is already in the canonical hardware spec. A separate 7-segment component would be redundant hardware. Original concept retained below for design history.

Resolved: What follows is the original parking-lot pitch from 2026-04-17. The functional intent (a perpetually-cycling diegetic numeric surface visible at rest) is delivered by CIPHER-LINE Row 4. Cartridge authors should target the CIPHER-LINE NoshAPI primitives, not a discrete 7-segment LCD.

Original concept hardware: TM1637 or HT16K33-driven 8-digit 7-segment LCD (alarm-clock style), mounted on the keyboard plate of the prototype (Pi Zero 2 W build). Driven by the Arduino Pro Micro keyboard controller (I²C, 2–4 pins). Always on.

Why it was attractive: The bigger prototype case has unused surface area on the keyboard plate. A perpetually cycling numeric display reinforces the 1988 cyberpunk terminal fiction — the device looks like a real cryptographic entropy generator, not a game console. Picks up the cipher_seed LFSR that already exists in Universal Deck State and makes it physically visible.

Original Display Modes (now CIPHER-LINE Row 4 patterns)

Mode 1: Entropy Roll (Default/Idle) — bottom 8 digits of cipher_seed[4] LFSR state, updating continuously.

Mode 2: Reputation Ticker — REP045 style, updating only on rep change.

Mode 3: Active Cartridge Signature — module class code + load count.

Optional Interaction: Entropy Capture

During Entropy Roll mode, mission templates can define “entropy capture windows” where pressing ENT captures the displayed value and injects it into gameplay (XOR’d with cipher_seed, used to seed procedural generation, applied as bonus/penalty). The mechanic is opt-in per cartridge — most of the time the display is passive. This mechanic is still viable, just delivered via CIPHER-LINE Row 4 rather than a discrete 7-segment.

Cross-Module Strength

ICE Breaker: Strongest fit. Visible cipher key during network intrusion. Capture windows work as cipher-cracking or evasion sequences.
NeonGrid: Good fit. Surveillance pattern entropy, movement prediction seed.
Black Ledger: Moderate. Account obfuscation entropy, audit trail randomization.
DepthCharge: Lighter but thematic. Sonar seed, ballast randomization.

Shelved Sub-Idea: Countdown Timer Mode

The display switching from rolling entropy to a hard countdown during high-pressure missions was explored. The transition itself (rolling numbers snap to clean countdown digits) creates strong tension. Shelved because: a mysterious homemade device with a ticking countdown display looks too much like a bomb. Not the vibe for something you carry around or show people. The gameplay value of temporal pressure can be delivered through the main 80×25 display instead.

Resolution Notes (2026-04-25)

Entropy capture windows, reputation tickers, and cartridge signatures all map cleanly onto CIPHER-LINE Row 4 contextual rendering.
The CIPHER-LINE Grammar Framework (mode selector, coherence stack, NoshAPI primitives) already exposes the surface needed.
No new hardware procurement, GPIO budgeting, or driver work required.
If a “7-segment alarm-clock font” is desirable as a stylistic choice, that’s a font-rendering decision against the existing OLED, not a separate component.

4. “Decline” / “Deckline” Retro Ad Campaign

Status: Concept — not yet developed. Brand voice and positioning are already established in KN-86-Marketing-Plan.md; this campaign concept layers on top of that voice.

Core hook: A retro ad campaign (late-80s aesthetic) built around the phonetic overlap between “decline” and “Deckline.” The wordplay opens multiple angles:

“In Decline? Get on the Deckline.” — Positioning the KN-86 as the antidote to obsolescence. While mainstream computing “declines” into GUI bloat and mouse dependency, the Deckline holds the line for operators who work with text, code, and command.
“They Said Computing Was in Decline.” — Fake nostalgic framing. The ad pretends to be from 1988, when “real” computing (terminals, command lines, operator skill) was being displaced by consumer-friendly interfaces. Kinoshita saw the decline coming and built the Deckline as a refuge.
“Decline the Decline.” — Imperative voice. Refuse the trend. Choose the Deckline.
“The Deckline: For Those Who Refuse to Decline.” — Tagline variant. Positions the operator as someone who rejects the easy path.
Credit card angle: “Decline” is also what happens when a transaction fails. In a cyberpunk economy where credits (¤) are everything, your deck can’t afford to decline. Financial survival meets hacker survival.

Aesthetic direction: Period-accurate late-80s print ads, VHS-era TV spots, BBS-style text ads. Black background, amber text, the KN-86 photographed like high-end audio equipment. Could extend to fake magazine spreads (Byte, Creative Computing, CompuServe ads).

Possible executions:

Fake 1988 print ad series (3–5 ads) for the website and social media
Short VHS-style video spot (30–60 seconds, scanline filter, period music)
BBS-style ASCII art ad for terminal/retro computing communities
Fake “Kinoshita Consumer Electronics” corporate brochure

Next Steps (when advanced)

Brief the Marketing / Product agent on tone, period accuracy, and brand voice (start from KN-86-Marketing-Plan.md §Brand Voice)
Draft 3 print ad concepts with headline + body copy + visual direction
Determine whether this is launch material or pre-launch teaser content
Coordinate with website build (kn86-deckline.com) for placement

5. Glyph Keycaps — Symbolic Legends for Function Keys

Status: Concept — discussed 2026-04-17. Adjacent to ADR-0018 (custom keyboard build), which is silent on legends.

Core idea: Replace text labels on the 14 function keys with abstract glyphs. No words on the device. The operator learns the keys like an instrument, not a labeled control panel. Reinforces the braille accessibility story (glyph = visual, braille = tactile, both abstract). Eliminates language dependency, which matters for a Japanese-fiction device.

Proposed Glyph Set

Key	Glyph	Rationale
CAR	(	Lisp car extracts the first element. Opening paren = “go into the list.”
CDR	)	Lisp cdr returns the rest. Closing paren = “step through.”
CONS	·	The dot-pair. Cons connects two things.
NIL	∅	Empty set. Nil is the void. Clean and mathematical.
ATOM	•	A single filled dot. Indivisible unit.
EQ	≡	Triple bar (identity), not double (equality). EQ tests identity.
EVAL	▶	Play button. Universal “go.” On the 3U bar.
QUOTE	’	Literally the Lisp quote character. Already a glyph.
LAMBDA	λ	The freebie.
APPLY	→	Arrow meeting target. Function applied to argument.
BACK	←	Universal retreat.
INFO	?	The query. You’re asking the system a question.
LINK	∞	Two interlocking rings. Deck-to-deck connection.
SYS	■	Solid block. The machine itself.

The strongest thematic read: ( ) · ∅ • ≡ ▶ ’ λ → ← ? ∞ ■ — fourteen keys, fourteen symbols, zero words. An operator who learns these will later recognize they’ve been “writing Lisp with their hands.”

Open Questions

CP437 coverage: Which glyphs are natively in the KN-86 code page vs. need custom bitmap additions?
Keycap production: UV printing vs. dye-sub vs. laser etching for glyph legibility at small scale?
Discoverability: Does the boot sequence or onboarding need a one-time key legend overlay?

Next Steps (when advanced)

Validate all 14 glyphs against the KN-86 Character Set spec
Mockup keycap renders with glyphs + braille side by side
Test legibility at actual Kailh Choc v1 keycap dimensions

6. Braille Key Legends for Tactile / Eyes-Free Play

Status: Concept — discussed 2026-04-17.

Core idea: Add raised braille legends to all 30 keycaps, making the entire device playable without sight as a first-class experience — not an accessibility accommodation but the most immersive way to play.

Why it fits: The sound-only play mode (Specialist operators navigating Threat 3 with the screen off) is already documented as an advanced technique in the ICE Breaker gameplay spec. Braille keycaps make that mode physically supported rather than emergent. A cyberdeck operator working by touch and sound in a dark room — feeling the keys, listening to the PSG voices — is the most in-fiction way to use the device.

Layout Notes

Function keys (left hand): Braille legends for each glyph key. These are the semantic keys — the ones the operator needs to identify by touch.
Numpad (right hand): Phone-style layout (1-2-3 top, 0 bottom-center) per ADR-0016 §5 — calculator layout was the original 2026-04-17 sketch but the device’s v1.0 numpad is phone-style. The nub on 5 is already a tactile anchor. Braille for digits is optional but completist.
EVAL bar: 3U wide and centered. Self-locating by size and position. Braille optional.

Open Questions

Full braille labels (e.g., ⠉⠁⠗ for “car”) or single-cell identifiers (⠉ for C) to keep caps clean?
Raised dot production method: injection-molded, UV-cured resin overlay, or aftermarket stickers?
Does braille + glyph + (optional) phone letter mapping create visual clutter on a small keycap?

Next Steps (when advanced)

Consult accessibility guidelines for braille keycap standards
Prototype a single keycap with glyph + braille and evaluate tactile clarity
Determine whether braille is production-only, prototype-only, or both

7. T9 / Multi-Tap Text Input on Numpad

Status: Promoted 2026-04-24 — locked into v1.0 hardware design via ADR-0016 §5–6 (phone-style keypad layout + Nokia multi-tap alpha entry). Multi-tap state machine, timeout-based commit, ENT-immediate-commit, and CIPHER-LINE Row 4 echo surface are all in the ratified ADR. Original parking-lot pitch retained below for design history.

Original concept (2026-04-17): Enable phone-style multi-tap text entry on the 16-key numpad. Press 2 once for A, twice for B, three times for C — the same input method an entire generation memorized on mobile phones. The firmware already has hold detection, so the input infrastructure exists.

What it unlocks:

Operator handle entry at boot — currently implied but not specified how text is entered on a 30-key device with no QWERTY.
Lambda macro naming — naming saved macros across cartridges.
MUD/text adventure input — free-text commands beyond the choice list (see Idea #8 — now THRESHOLD).
Linked play chat — short messages between intruder and sysop.

Fiction fit: This is 1988. Multi-tap on phone keypads predates T9 (1995) but the physical interaction is identical. A Japanese cyberdeck with phone-style text entry is exactly what that era’s engineers would have built. They wouldn’t add a QWERTY keyboard — they’d say “you have 16 keys, figure it out.”

Japanese input: Multi-tap kana input on a 12-key phone pad (あ ka さ ta な ha ま ya ら wa mapped to 1-0) is deeply culturally embedded in Japan. The KN-86 could support both romaji multi-tap and direct kana input, toggled via SYS. This is how an entire generation of Japanese people texted.

Keycap Integration

The numpad already has numbers. Add traditional phone letter mappings as small secondary legends (2 ABC, 3 DEF, etc.) — or let operators memorize them from muscle memory. Most people over 30 still have this mapping internalized.

With glyph function keys + number/letter numpad + braille on everything: three input layers on 30 keys. Nothing wasted.

Resolution Notes (2026-04-24)

ADR-0016 ratifies:

Phone-style numpad layout (1-2-3 top, 0 bottom-center) replaces calculator layout.
Multi-tap state machine: keys 2–9 cycle through their letter sets on repeated press; ~600 ms commit timeout; ENT for immediate commit.
CIPHER-LINE Row 4 acts as the echo surface for in-progress multi-tap text.
Mode scope: multi-tap is active when a text field expects alpha input; literal-entry mode (numbers only) when a numeric field is focused.

Open follow-ups (downstream of ADR-0016):

T9 dictionary (predictive) is not in v1.0 — flash budget assessment deferred. Multi-tap only.
Kana / Japanese input mode remains a parking-lot extension, not in the ratified ADR.

8. MUD / Text Adventure Capability Module

Status: Promoted 2026-04-21 — full gameplay spec at docs/software/cartridges/modules/threshold.md (v1.0, Engineering-Ready). Now the THRESHOLD launch-adjacent title (the “+1” in “14 + 1”) published by Pacific Rim Dynamics. Hybrid handcrafted core (~35–45 rooms in Threshold City) + procedural wilderness; party-based linked play via TRRS cable. See Notion task Design KN-86 MUD capability module gameplay spec for the completion record. Original parking-lot pitch retained below for design history.

Original concept: A choice-based MUD (Multi-User Dungeon) cartridge that uses the Lisp function keys as navigation verbs instead of typed commands. The operator is in a room, sees a text description on the amber screen (CP437 box drawing, 2-3 lines), and selects actions using the keys they already know.

Original Key Mapping (now reflected in THRESHOLD spec)

Key	MUD Verb
CAR	Enter / examine (go deeper into what’s in front of you)
CDR	Move / traverse (go to the next room or option)
CONS	Combine (use item with item, talk to someone about something)
INFO	Look (get more detail about the current room)
BACK	Retreat (go back where you came from)
Numpad 1-4	Select from presented choices
EVAL	Confirm selection

The verbs are already there — designed into the keyboard. A MUD is the purest expression of what those keys mean outside of network intrusion.

Why It Mattered

Makes the KN-86 feel like a computer, not a game console. MUDs are the ghost of early networked computing. A MUD on an amber terminal with PSG sound effects is deeply in the device’s fiction.
The keys transfer. An operator who knows ICE Breaker already knows what CAR, CDR, CONS, and INFO do. The context changes; the grammar doesn’t.
Choice-based solves the parser problem. No QWERTY means no free-text parser. But choice-list interaction gives all the theater-of-mind magic with none of the “I don’t understand that verb” frustration. Multi-tap (Idea #7) optionally extends this with limited free-text.

Resolution Notes (2026-04-21)

Spec settled on the multiplayer-first / Lisp-verb-native / Pacific Rim Dynamics framing after two design rounds + two playtests (Corwin, Vex, Mae).
Ships launch-adjacent — outside the 14-module launch track, hence the “14 + 1” terminology now used in the Master Index, Capability Model Spec, and CLAUDE.md.
Standalone cartridge (not firmware-native idle mode); the firmware-native MUD framing was rejected in favor of the published-cartridge fiction.
World scope: ~35–45 hand-crafted rooms in Threshold City + procedural wilderness — hybrid model, neither pure handcraft nor pure procgen.
Linked play is in scope (TRRS cable, party-based).
Economy: integrated with Universal Deck State (handle, credits, reputation flow through).

9. Statline as Event-Contracts Terminal (Repositioning from Fantasy Sports)

Status: Concept — reframed 2026-04-21. Original Statline pitch (fantasy sports deck with thermal printer + RJ-11 modem) superseded by stronger commercial and narrative read: a CFTC-regulated event-contracts terminal routing orders to a Designated Contract Market (DCM) partner. Sister-deck pitch — not a KN-86 concept. Cross-catalog networking implications tracked separately as Notion: GWP-N — Design spike — Statline / Gridline networking stack.

Why it fits: Event contracts — Kalshi, Polymarket, Robinhood prediction markets, Crypto.com derivatives — are the category that matured between 2024 and now. Fantasy sports (DraftKings / FanDuel / Underdog / Sleeper) is saturated with thin margins. Nobody has built a dedicated hardware device for event contracts. The category is getting heavy retail marketing investment right now, which is a durable tailwind.

Clean regulatory split from Gridline:

Gridline = FINRA / SEC (securities — equities, options, forex, crypto spot)
Statline = CFTC (event contracts, binary yes/no instruments, probability-denominated 0–100¢ pricing)

Different broker relationship, different compliance surface, different capital requirements. Easier to build in parallel than two securities products because broker infrastructure is not duplicated.

Capability Modules (Statline)

SPORTS — game outcomes, props, series odds, spreads-as-contracts
MACRO — CPI prints, Fed decisions, jobs reports, GDP
CULTURE — award shows, chart positions, entertainment events
WEATHER — temperature averages, hurricane landfall, named-storm count
POLITICS — elections, legislation outcomes, approval thresholds, confirmation votes
CRYPTO — price-level predictions, volatility contracts (distinct from Gridline’s spot trading)

Each module is a filter and contract schema over the DCM’s universe. Firmware pulls available contracts, filters by category, renders them through the Lisp grammar.

Lisp Grammar Mapping

Key	Statline semantics
CAR	Long the YES side
CDR	Long the NO side
CONS	Compose a spread between two contracts
EVAL	Execute at market
QUOTE	Limit order at display price
LAMBDA	Conditional / parameterized order (“if CPI > 3.2, buy YES on Fed Hikes”)

Conditional orders (LAMBDA) are a real differentiator — not well-supported in existing event-contracts UIs. A Lisp-powered order composer is a capability nobody else in the space has built.

Partnership Model

Kalshi — cleanest DCM partner; federal legal standing, broadest contract universe
ForecastEx / Nadex — alternate if Kalshi partnership unavailable
Crypto.com Derivatives — possible for crypto-specific contracts
Polymarket — offshore; useful for elections but regulatory-distinct

Statline white-labels the front-end. Customer KYC and funding live at the DCM; Statline authorizes via OAuth / API (Robinhood–Plaid pattern). Statline never touches the money.

Thermal Printer Story (Unchanged, Stronger)

Fantasy sports ticket printouts are cute. An event-contract position slip with strike, side, size, price, and settlement date is a real financial document — same ceremony as a 1988 printed stock confirmation, for a 2026 asset class. Fold it in your wallet. Show friends at the bar. Print a settlement slip when the contract resolves. The thermal printer fits the asset class in a way it never quite fit a DFS lineup.

Fiction Retcon: “Kinoshita Was Right Too Early”

Iowa Electronic Markets launched at the University of Iowa in 1988 — the first real prediction-market venue. Canonical beat:

Kinoshita’s Edgeware Systems division recognized the Iowa Electronic Markets experiment in 1989 as a category of instrument no existing terminal served. Event contracts — binary, probability-priced, settling on real-world outcomes — required a display format distinct from securities quoting and a workflow built around discrete settlement events. The Statline was Kinoshita’s answer, targeting what Edgeware projected as a $2B market by 1995. The projection was premature by 35 years. Commercial prediction markets remained marginal until regulatory clarity arrived in the mid-2020s. The Statline shipped briefly and was quietly discontinued in 1991 with fewer than 1,200 units sold. Collectors now refer to the original Statline as the deck Kinoshita built for a market that hadn’t been invented yet.

Re-release tagline: “Kinoshita was right too early.”

Real Considerations

DCM partner lock-in. Single point of dependency on partner API and contract universe. Mitigation: routing layer as capability-module interface so alternate DCMs plug in as future modules without re-architecting.
State-by-state sports. Kalshi has won most federal battles against state gaming regulators but some jurisdictions remain blocked or in active litigation. Requires geofencing and possibly pared-down contract sets per state.
Customer KYC and funding. Statline authorizes against the DCM account via OAuth. Same pattern as any modern brokerage connector. Well-trodden for Braintree-alumni team.
Settlement display. Event contracts settle discretely. Firmware needs a push channel (WebSocket or polling via Ethernet) to fire the thermal printer on resolution. Requires real networking stack — see cross-catalog implication below.
Catalog ordering. Statline’s commercial tailwind may justify moving it up in the roadmap, ahead of or alongside Gridline, despite Gridline also being a strong opportunity.

Cross-Catalog Implication: Networking Stack

Statline (and Gridline) routing to live DCM and brokerage APIs upgrades the KN-xx line’s networking expectations from RJ-11 / modem-era aesthetics to real TCP/IP + TLS. This is load-bearing for both sister decks and retroactively affects the KN-86’s own networking story. Tracked as a separate design spike — Notion task: GWP-N — Design spike — Statline / Gridline networking stack.

Next Steps (when advanced)

Partnership conversation with Kalshi (warm intro via Braintree alumnus network)
DCM API evaluation: which partner’s 2026–2027 contract roadmap best aligns with Statline capability-module taxonomy
Networking stack design spike (separate task, cross-catalog scope — GWP-N)
Draft Statline gameplay spec — capability model, Lisp grammar specifics, conditional-order UX
Update Kinoshita Electronics Consortium fiction timeline (Iowa Electronic Markets beat, 1989 Statline first release, 1991 discontinuation)
Confirm industrial design implications: receipt printer + Ethernet + cartridge slot likely unchanged by repositioning; validate with ID lead

Parking Lot Conventions

Add new ideas as new ## sections with a Status line.
Status values: Concept (default), Promoted (graduated to ADR / spec / Notion task — link out), Subsumed (functionally delivered by another decision — link to that decision), Shelved (rejected or dropped — record the reason; never delete).
Keep evaluation honest — including reasons to not do something.
When an idea is promoted: change the Status line, link to the canonical spec/ADR/Notion task at the top of the section, and retain the original pitch below for design history.
When an idea is shelved: change the Status line to Shelved with the reason; keep the body intact.
Never restate values from the Canonical Hardware Specification table in CLAUDE.md — reference it. Concepts that touch hardware should describe deltas against the canonical spec, not duplicate it.
Bump the *Last updated* date at the top whenever a meaningful edit lands.
Bump the bold-text Date: in the frontmatter when ratified status changes (a new promotion, a new shelving, a new top-level idea).

Capture Workflow

The companion skill kn86-deckline-brainstorming (.claude/skills/kn86-deckline-brainstorming/) governs how new entries land here. Load that skill whenever brainstorming a new Deckline concept; it enforces the capture template, cross-reference checklist, and promotion/shelving discipline.

Docs-Site Routing (follow-up)

This file lives in docs/ and follows the bold-text frontmatter convention used by the kn86-docs/ Astro/Starlight site. It is not yet routed by the site. To publish, the sibling kn86-docs/ repo needs:

A routing rule in kn86-docs/scripts/sync-from-docs.mjs: { match: 'future-concepts.md', target: 'concepts', rename: 'kn-deckline-future-concepts' }
A 'concepts' entry added to CLEAN_DIRS in the same file
A new sidebar section in kn86-docs/astro.config.mjs: { label: 'Future Concepts', collapsed: true, autogenerate: { directory: 'concepts' } }

Tracked as a Notion follow-up; see PR description for the link.