GENERATED VIEW · PRIVATE ARCHIVE · DO NOT SERVE
RobCo Industries · Archive Museum

parked-ai-feature-eval.md



MEMORY

memory/localmode-1060dea9-0dc3-42b4-958d-2a6f7a6c0c58/parked-ai-feature-eval.md

sha256 397349d318ed4fe9 · 5261 bytes · original held in the private archive

--- name: parked-ai-feature-eval description: "The SIX-AXIS AI COST MODEL — the durable framework for judging any proposed AI-native terminal feature. The parked evaluation brief around it is spent; the model is the keeper." metadata: node_type: memory type: project originSessionId: 0b7c5f41-bb34-4ab4-93be-fdb363f5eb40 --- **Origin: a PARKED, PLAN-ONLY evaluation brief (owner, 2026-06-28) — "evaluate which AI features can be made native to the terminal," implement nothing, produce specs only.** That brief has been spent. **What survives, and the reason this file exists, is the cost model below.** It applies to any future AI feature proposal, not just that run. Standing owner constraint from the same directive, still true: **AI features are inherently non-trivial. The default is SPEC-FIRST — write the spec, do not ship unattended.** Every AI feature awaits explicit owner go-ahead. --- # ⭐ THE AI COST MODEL — score EVERY candidate on all six axes 1. **Network honesty & offline degradation.** Any AI feature is networked. What happens with no signal? It must degrade **in-world** and **never block boot** (e.g. "TRADE LINK SEVERED — STANDALONE MODE," or fall back to a static canned interaction). A kill-switch plus a fail-safe fallback is **mandatory, not optional**, and the kill-switch read must itself be fail-safe. **A feature that breaks offline fails this axis outright.** 2. **Grounded vs. generative — classify it explicitly.** - **Grounded** (lore/factual: lookups, survival data) → must be constrained to sourced canon. **The AI is a typist, not an authority.** Free-generating canon facts is pollution. No reliable source-grounding ⇒ SKIP. - **Generative** (fiction by design: merchant banter, procedural logs, quests) → creative latitude is fine; stay in-world and safe. - ⚠ **Mislabeling a grounded feature as generative is the most dangerous error in this whole exercise.** 3. **Cost, latency & abuse.** Model calls cost money and time, and **anonymous public users can hammer them.** Reason explicitly about caching/memoizing responses, debounce, token budget, response-length caps, and whether App Check plus auth-gating actually limits spend. **Latency can be hidden behind an in-world progress beat; the bill cannot.** 4. **Injection & character robustness.** Any freeform user input invites jailbreaks. The persona must **refuse to break the RobCo fiction**; design the system prompt and input handling so the terminal stays in character and never leaks that it is a general model. **This is a public site — assume adversarial input.** 5. **State & data.** Stateful AI (companion memory, quest progress, trade stock) means cloud writes: additive, checksummed, versioned. **Any persistent *operator memory* is a privacy decision that needs its own written note** — not a side effect. 6. **Diegetic fit & ROI.** Does it read as the terminal's own intelligence, and does the payoff justify the spend, the complexity, and the other five axes combined? **Verdict tiers:** **SPEC-FIRST** (the default for any new networked AI subsystem) · **BUILD-NOW** (rare — only a genuinely self-contained, low-risk tweak to an *existing* feature that is already offline-safe) · **SKIP** (fails grounding, offline degradation, cost, or ROI — log it with a one-line reason so the owner sees it was considered). # THE DESIGN LENS THAT GOES WITH IT - **Diegetic cover for AI must exist in-world.** Frame it as a RobCo personality construct / ZAX-class subroutine bound to the terminal — **never the vendor's name, never modern-assistant phrasing.** Verify any lore or naming against the canon source. - **The AI-native move:** ask *"what in-world terminal system would a 2077 RobCo AI plausibly power?"* — a haggling merchant, a databank you consult, an intercepted distress signal, a hostile system you hack. The output is a **command or system**, voiced in RobCo register, with latency shown as `PROCESSING…` / `DECRYPTING…`. - **Extend real systems, don't float beside them.** An AI feature should plug into something the terminal already has. - ⭐ **The strongest pattern found: design offline-first, let AI augment.** The worked example that models it — procedural found-logs that ship with a static library of pre-written entries, so the feature is *good with no signal* and better online. **Build the fallback first; the AI is the enhancement layer.** - **Never hit the live model API inside the test gate.** Mock it. *Correction 2026-07-20: the original brief's repo/stack description, protocol numbers, test-count sync rules, cache-name formula and `RULES.md` reference were all removed — that state is derivable and partly obsolete (`RULES.md` no longer exists). Current rules live in `CLAUDE.md` + `rules/`.* ⚠ **Open question for the owner:** this cost model is doctrine that dies if this file is ever retired. It is a candidate for promotion into `rules/`. Related: [[parked-capability-survey]], [[parked-diegetic-audit]], [[player-control-principle]] (deterministic by default; AI only where interpretation *is* the product), [[deep-systems-review-2026-07-13]] (the app has been de-AI-ing itself for months — protect that trend), [[parked-task-workflow]].
STAMP · generated for RELEASE v2.8.5 commit 06e5180 (06e51801b38a) · archive input-tree hash c07fbfbdd2e1ddeb · 754 files · no wall-clock timestamp (regenerates identically when nothing changed).