P08 · Experience · Rendered from source

innovation register

Archetypes, shells and layouts

101 lines57,777 bytessha256 b8d2e026a8b0
Archetype-native topologyrecord 1
{
  "id": "A01",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Archetype-native topology",
  "family": "a",
  "claim": "Each of the 10 archetypes ships its own nav skeleton derived from its data spine, not a shared N-slot rail.",
  "cost": "~10 topology definitions + selector; 2-3 weeks",
  "falsifier": "Build two archetypes' native topologies and find they converge to the same shape - meaning the shared rail was right and archetype variance is cosmetic.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Spine-derived navrecord 2
{
  "id": "A02",
  "evidence_class": "inferred",
  "source": "Backstage derives nav from PageBlueprint registration - mechanical derivation from declared structure is a shipped pattern",
  "observed": "2026-08-27",
  "name": "Spine-derived nav",
  "family": "a",
  "claim": "Nav items generated mechanically from the archetype's spine nouns (case_workflow -> Cases, Deadlines, Documents).",
  "cost": "Pure function spine->nav; days",
  "falsifier": "A generated nav where no pilot user completes a top-5 task, because spine nouns are storage concepts not work concepts ('Movements' is not how a clerk thinks).",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Stage-derived nav (workflow rail)record 3
{
  "id": "A03",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Stage-derived nav (workflow rail)",
  "family": "a",
  "claim": "For case_workflow, top-level nav is the state machine's stages, not entities. Nav IS the pipeline.",
  "cost": "Medium; needs stage->count queries",
  "falsifier": "Users navigate by finding a specific case far more than by browsing a stage, so search dominates and stage nav goes unclicked.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Deadline-primary railrecord 4
{
  "id": "A04",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Deadline-primary rail",
  "family": "a",
  "claim": "case_workflow shell leads with the deadline clock; nav sorted by time-to-breach, not entity type.",
  "cost": "Medium; needs a real deadline model",
  "falsifier": "Deadline pressure is bursty; on a normal day the sort is meaningless and users lose stable item positions.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Entity-derived navrecord 5
{
  "id": "A05",
  "evidence_class": "inferred",
  "source": "Attio ships object-driven nav",
  "observed": "2026-08-27",
  "name": "Entity-derived nav",
  "family": "a",
  "claim": "Nav mirrors the top-level entities of the data model, one row each.",
  "cost": "Low",
  "falsifier": "Entity count exceeds the nav budget in any non-trivial spine, forcing arbitrary grouping - the exact failure the five-slot rail already shows.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Role-derived navrecord 6
{
  "id": "A06",
  "evidence_class": "inferred",
  "source": "ISSO already ships agency vs model rails; SISOCRM defines a brokerage role matrix",
  "observed": "2026-08-27",
  "name": "Role-derived nav",
  "family": "a",
  "claim": "The rail is computed from the viewer's role; two roles in one product see two different rails.",
  "cost": "Medium; needs a role matrix",
  "falsifier": "Role-specific rails make support and documentation impossible ('click Team' - 'I don't have Team'), and users who switch roles lose spatial memory.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Icon rail + contextual panelrecord 7
{
  "id": "A07",
  "evidence_class": "inferred",
  "source": "Zendesk, Intercom, Datadog, VS Code activity bar 48px",
  "observed": "2026-08-27",
  "name": "Icon rail + contextual panel",
  "family": "a",
  "claim": "A narrow always-visible icon rail plus a wide contextual panel that changes per section.",
  "cost": "Medium",
  "falsifier": "Icon-only rails need labels to be learnable; if users hover every icon every time, the space saving bought nothing.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Dual railrecord 8
{
  "id": "A08",
  "evidence_class": "inferred",
  "source": "Front; VS Code activity bar + sidebar",
  "observed": "2026-08-27",
  "name": "Dual rail",
  "family": "a",
  "claim": "Two rails: outer for app/section switching, inner for within-section nav.",
  "cost": "Medium-high",
  "falsifier": "Two rails consume the pixel budget the app pane needed; users cannot predict which rail holds a given item.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Command-palette-primaryrecord 9
{
  "id": "A09",
  "evidence_class": "inferred",
  "source": "Linear, VS Code",
  "observed": "2026-08-27",
  "name": "Command-palette-primary",
  "family": "a",
  "claim": "Minimal visible nav; the palette is the primary navigation surface.",
  "cost": "Low-medium",
  "falsifier": "Novice and occasional users never discover the palette; the archetypes with the most infrequent users (portal) are exactly where it fails.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Zero-nav single surfacerecord 10
{
  "id": "A10",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Zero-nav single surface",
  "family": "a",
  "claim": "One surface, no rail; all movement is via in-content links and search.",
  "cost": "Low",
  "falsifier": "Users cannot form a mental model of what the product contains, and feature discovery collapses to zero.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Top-bar topologyrecord 11
{
  "id": "A11",
  "evidence_class": "inferred",
  "source": "Salesforce Lightning, ServiceNow, Xero, Metabase",
  "observed": "2026-08-27",
  "name": "Top-bar topology",
  "family": "a",
  "claim": "Horizontal top nav instead of a rail, freeing full width for the app pane.",
  "cost": "Low",
  "falsifier": "Top bars cap out around 7 items before overflow menus start hiding things, and nesting is worse than a rail's.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Hybrid top + railrecord 12
{
  "id": "A12",
  "evidence_class": "inferred",
  "source": "Jira, Shopify, HubSpot",
  "observed": "2026-08-27",
  "name": "Hybrid top + rail",
  "family": "a",
  "claim": "Top bar for global/product switching, rail for within-product nav.",
  "cost": "Medium",
  "falsifier": "Two nav planes double the places a user must check before concluding a feature does not exist.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Tile/launchpad homerecord 13
{
  "id": "A13",
  "evidence_class": "inferred",
  "source": "SAP Fiori launchpad",
  "observed": "2026-08-27",
  "name": "Tile/launchpad home",
  "family": "a",
  "claim": "Home is a tile grid of entry points rather than a dashboard.",
  "cost": "Low-medium",
  "falsifier": "Tiles are a menu with pictures; if users bounce straight through to the same three tiles, the grid is pure friction.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Fixed N with N per archetyperecord 14
{
  "id": "A14",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Fixed N with N per archetype",
  "family": "a",
  "claim": "Keep the fixed-tuple discipline but let N be set per archetype rather than globally 5.",
  "cost": "Low - a type change",
  "falsifier": "If the right N differs per INDUSTRY rather than per archetype, archetype-level N is still the wrong granularity.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Nav budget cap, not schemarecord 15
{
  "id": "A15i",
  "evidence_class": "inferred",
  "source": "IBM Carbon publishes 'more than five secondary items' as its left-panel rule",
  "observed": "2026-08-27",
  "name": "Nav budget cap, not schema",
  "family": "a",
  "claim": "Replace the fixed 5-tuple with a soft cap (5-7) enforced at generation time and warned, not typed.",
  "cost": "Low",
  "falsifier": "Without a hard type constraint, generated shells drift past the cap and nobody notices until a client sees 14 rail items.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Depth limit of tworecord 16
{
  "id": "A16",
  "evidence_class": "inferred",
  "source": "Carbon: 'The left panel does not support three tiers of navigation'",
  "observed": "2026-08-27",
  "name": "Depth limit of two",
  "family": "a",
  "claim": "No third tier of navigation anywhere; forced flattening or in-page nav below tier 2.",
  "cost": "Low",
  "falsifier": "An archetype with genuinely three-level structure (matter > phase > document set) becomes unnavigable when flattened.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Search-primary with thin railrecord 17
{
  "id": "A17",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Search-primary with thin rail",
  "family": "a",
  "claim": "Search box is the largest element; rail exists only for orientation.",
  "cost": "Low-medium",
  "falsifier": "Search only works when users know the name of what they want; browse-heavy archetypes (inventory, learning_content) degrade badly.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Object-switcher railrecord 18
{
  "id": "A18",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Object-switcher rail",
  "family": "a",
  "claim": "Rail rows are data objects the user has pinned, not fixed product areas.",
  "cost": "Medium",
  "falsifier": "Pinning is a power-user behaviour; the median user pins nothing and gets an empty rail.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Two shells per productrecord 19
{
  "id": "A19",
  "evidence_class": "inferred",
  "source": "ISSO already ships agency vs model vs client vs portal route groups",
  "observed": "2026-08-27",
  "name": "Two shells per product",
  "family": "a",
  "claim": "Ship a separate internal shell and external shell rather than one shell with role gating.",
  "cost": "Medium - two shells to maintain",
  "falsifier": "If the two shells drift in vocabulary or data, users straddling both (a paralegal who also answers portal messages) get two mental models of one system.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Rail as status surfacerecord 20
{
  "id": "A20",
  "evidence_class": "inferred",
  "source": "ISSO summaryItems already carry stat strings",
  "observed": "2026-08-27",
  "name": "Rail as status surface",
  "family": "a",
  "claim": "Rail items carry live counts/stats so the rail doubles as an at-a-glance status board.",
  "cost": "Medium - needs per-item queries",
  "falsifier": "Live counts on every row create N queries per page load and become the slowest thing in the shell; stale counts are worse than none.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Fixed 320px host railrecord 21
{
  "id": "B01",
  "evidence_class": "inferred",
  "source": "Zendesk 320, Grafana 320, Metabase 324 - three independent corroborations",
  "observed": "2026-08-27",
  "name": "Fixed 320px host rail",
  "family": "b",
  "claim": "Host rail specified as 320px at >=1056px viewport, not as a percentage.",
  "cost": "Low",
  "falsifier": "Donors that need more than 320px of their own nav still overflow, so the number bought nothing for the hardest case.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Collapse-rate as the verdictrecord 22
{
  "id": "B02",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Collapse-rate as the verdict",
  "family": "b",
  "claim": "Ship the rail collapsible with per-user memory; permanent-collapse rate decides whether it earned its pixels.",
  "cost": "Very low - a toggle and an event",
  "falsifier": "If collapse correlates with screen size rather than preference, the metric measures monitors, not value.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open",
  "rank": 3,
  "rationale": "The 20/80 proposal has an unusually clean behavioural falsifier: ship the rail collapsible and see whether users keep it. That is a verdict rather than an opinion, and it costs a toggle and an event."
}
Proportional rail with caprecord 23
{
  "id": "B03",
  "evidence_class": "inferred",
  "source": "VS Code layout.ts:3026 - the only proportional rule found in the corpus",
  "observed": "2026-08-27",
  "name": "Proportional rail with cap",
  "family": "b",
  "claim": "Rail width = min(320px, viewport/4) rather than a flat constant.",
  "cost": "Low",
  "falsifier": "On ultrawide monitors a quarter is absurd, so the cap does all the work and the proportion is decorative.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Host rail carries only host-owned surfacesrecord 24
{
  "id": "B04",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Host rail carries only host-owned surfaces",
  "family": "b",
  "claim": "The rail holds identity, tenant, settings, search, notifications - nothing else; all app nav is in the pane.",
  "cost": "Low",
  "falsifier": "If the rail holds only five rarely-clicked controls, it is a puck's worth of function occupying a rail's worth of pixels.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Host puck instead of railrecord 25
{
  "id": "B05",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Host puck instead of rail",
  "family": "b",
  "claim": "Collapse host-owned controls into a small persistent puck; give the rail's pixels to the app.",
  "cost": "Low",
  "falsifier": "Tenant switching and settings become hard to find, and portal users (who need the most orientation) lose the most.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Top host bar, no railrecord 26
{
  "id": "B06",
  "evidence_class": "inferred",
  "source": "Metabase app bar 52px; Stripe, Vercel",
  "observed": "2026-08-27",
  "name": "Top host bar, no rail",
  "family": "b",
  "claim": "Host identity/settings/search live in a thin top bar; the entire width below is the app pane.",
  "cost": "Low",
  "falsifier": "Cross-app navigation has nowhere to live; a top bar cannot hold 8 destinations plus identity plus search.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Adaptive rail width per archetyperecord 27
{
  "id": "B07",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Adaptive rail width per archetype",
  "family": "b",
  "claim": "scheduling and inventory get a narrow rail (calendar/grid want width); case_workflow gets a wide one.",
  "cost": "Medium",
  "falsifier": "Users with several archetype apps in one host experience the rail jumping width between apps, which reads as a bug.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Rail collapses by viewport class, not pxrecord 28
{
  "id": "B08",
  "evidence_class": "inferred",
  "source": "Material 3 switches by window size class; Polaris and Primer both switch at 768px",
  "observed": "2026-08-27",
  "name": "Rail collapses by viewport class, not px",
  "family": "b",
  "claim": "Switch rail/icon-rail/bottom-bar by window size class rather than raw pixel breakpoints.",
  "cost": "Low",
  "falsifier": "Size classes hide real differences: a 1024px tablet and a 1024px window on a 4K monitor are the same class but different use.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Donor pane must never be less than 1024px effectiverecord 29
{
  "id": "B09",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Donor pane must never be less than 1024px effective",
  "family": "b",
  "claim": "Guarantee the app pane a minimum usable width; the rail yields first.",
  "cost": "Low",
  "falsifier": "Donors built for full-viewport still break at 1024px, so the guarantee is not a guarantee.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Rail hover-flyout when collapsedrecord 30
{
  "id": "B10",
  "evidence_class": "inferred",
  "source": "Atlassian collapses to a 20px stub with a 240px hover flyout",
  "observed": "2026-08-27",
  "name": "Rail hover-flyout when collapsed",
  "family": "b",
  "claim": "Collapsed rail expands on hover rather than requiring a click.",
  "cost": "Low",
  "falsifier": "Hover flyouts are unusable on touch and hostile to users with motor impairments.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Host owns identity absolutelyrecord 31
{
  "id": "C01",
  "evidence_class": "observed",
  "source": "TEABLE-ABSORPTION-BRIEF success criteria 1 and 4; Luigi host-holds-token pattern",
  "observed": "2026-08-27",
  "name": "Host owns identity absolutely",
  "family": "c",
  "claim": "No donor may present a login, signup, or account UI; host injects session at the donor's auth seam.",
  "cost": "Medium per donor - a seam per donor",
  "falsifier": "A donor whose auth is not separable from its data layer forces either a shadow user table or abandonment.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "adopt-as-contract"
}
Settings as host route, donor settings as sectionsrecord 32
{
  "id": "C02",
  "evidence_class": "inferred",
  "source": "FROZEN-PAGE-SKELETON gives Settings one host page with a module registry",
  "observed": "2026-08-27",
  "name": "Settings as host route, donor settings as sections",
  "family": "c",
  "claim": "Host owns /settings; each donor's settings become a section inside it, never a peer nav item.",
  "cost": "Medium",
  "falsifier": "Donor settings that are tightly coupled to donor routing cannot be relocated without forking the donor's UI.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Settings in a separate consolerecord 33
{
  "id": "C03",
  "evidence_class": "inferred",
  "source": "Salesforce Setup, Zendesk Admin Center, Metabase /admin",
  "observed": "2026-08-27",
  "name": "Settings in a separate console",
  "family": "c",
  "claim": "Follow Salesforce/Zendesk: admin is a separate console, not competing for a nav slot.",
  "cost": "Medium",
  "falsifier": "Small products do not have enough settings to justify a console, and the context switch annoys users who change one toggle.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Host-owned global search across donorsrecord 34
{
  "id": "C04",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Host-owned global search across donors",
  "family": "c",
  "claim": "One search surface federating donor indexes.",
  "cost": "High - a federation layer per donor",
  "falsifier": "Donors with no search API force either scraping or exclusion, and a search that silently omits a donor is worse than no search.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Host-owned notification spinerecord 35
{
  "id": "C05",
  "evidence_class": "inferred",
  "source": "SISOCRM consumes donor events into SISO-owned tables via Svix + event envelope",
  "observed": "2026-08-27",
  "name": "Host-owned notification spine",
  "family": "c",
  "claim": "All donor events normalize into one host notification model with host-coordinate deep links.",
  "cost": "Medium-high",
  "falsifier": "Donors that emit no webhooks cannot participate, and polling them does not scale past a few.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Host-owned tenant switchrecord 36
{
  "id": "C06",
  "evidence_class": "inferred",
  "source": "OWNERSHIP-AND-DATA-LAYER-DECISIONS: one server, separate schemas",
  "observed": "2026-08-27",
  "name": "Host-owned tenant switch",
  "family": "c",
  "claim": "Tenant/workspace switching is host-only; donors receive tenant context and cannot change it.",
  "cost": "Medium",
  "falsifier": "A donor with hardcoded single-tenant assumptions needs one instance per tenant, changing the cost model entirely.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Theming tokens flow host->donor onlyrecord 37
{
  "id": "C07",
  "evidence_class": "observed",
  "source": "qiankun documents style isolation as one-way: host CSS enters the donor regardless",
  "observed": "2026-08-27",
  "name": "Theming tokens flow host->donor only",
  "family": "c",
  "claim": "Host publishes tokens; donors consume them. No donor ships its own theme.",
  "cost": "Medium",
  "falsifier": "Donors with hardcoded colours require CSS overrides that break on every upstream upgrade.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Host-owned empty and error statesrecord 38
{
  "id": "C08",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Host-owned empty and error states",
  "family": "c",
  "claim": "Donor empty/error states are replaced with host ones so failures look like one product.",
  "cost": "Medium",
  "falsifier": "Donor errors carry diagnostic detail; replacing them can hide the information needed to debug.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Host-owned onboardingrecord 39
{
  "id": "C09",
  "evidence_class": "inferred",
  "source": "MASTER-SYNTHESIS names replacing donor onboarding as typical adaptation",
  "observed": "2026-08-27",
  "name": "Host-owned onboarding",
  "family": "c",
  "claim": "No donor onboarding, tour, or welcome modal ever renders.",
  "cost": "Low-medium",
  "falsifier": "Some donor onboarding writes required setup state; suppressing the UI without replicating the writes leaves the donor unconfigured.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Host-owned keyboard maprecord 40
{
  "id": "C10",
  "evidence_class": "inferred",
  "source": "ISSO already reserves Cmd1-Cmd5 for rail sections",
  "observed": "2026-08-27",
  "name": "Host-owned keyboard map",
  "family": "c",
  "claim": "Host reserves a keyboard namespace; donors may not bind conflicting global shortcuts.",
  "cost": "Low",
  "falsifier": "Donors bind shortcuts deep in their own code; policing this requires reading donor source per upgrade.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Route re-mount with basenamerecord 41
{
  "id": "D01",
  "evidence_class": "observed",
  "source": "react-admin <Admin basename>; Grafana serve_from_sub_path; Next.js inlines basePath at build time",
  "observed": "2026-08-27",
  "name": "Route re-mount with basename",
  "family": "d",
  "claim": "Mount the donor under a host path prefix using its documented basename option.",
  "cost": "Low where documented, high where not",
  "falsifier": "A donor that bakes its base path at build time cannot serve two mount points from one artifact.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "candidate"
}
Nav registry injectionrecord 42
{
  "id": "D02",
  "evidence_class": "observed",
  "source": "Backstage PageBlueprint auto-discovery; Piral registerMenu; Grafana addToNav boolean",
  "observed": "2026-08-27",
  "name": "Nav registry injection",
  "family": "d",
  "claim": "Donor declares nav intent; host renders it in host chrome and owns ordering.",
  "cost": "Medium",
  "falsifier": "Donors that cannot enumerate their own routes cannot declare them, and a partial declaration produces a rail that lies.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "candidate"
}
Host-declared nav config (donor declares nothing)record 43
{
  "id": "D03",
  "evidence_class": "observed",
  "source": "Luigi navigation.nodes with viewUrl and virtualTree",
  "observed": "2026-08-27",
  "name": "Host-declared nav config (donor declares nothing)",
  "family": "d",
  "claim": "Host config enumerates every nav node including donor view URLs.",
  "cost": "Medium",
  "falsifier": "Donor route changes on upgrade silently break host nav nodes, because nothing derives them from the donor.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "candidate"
}
iframe isolation with host railrecord 44
{
  "id": "D04",
  "evidence_class": "observed",
  "source": "wujie documents modal confinement; MDN Storage Access API requires transient activation; Firefox partitions since 103",
  "observed": "2026-08-27",
  "name": "iframe isolation with host rail",
  "family": "d",
  "claim": "Donor runs in an iframe; host provides the rail around it.",
  "cost": "Low to mount, high in constraints",
  "falsifier": "Donor modals cannot cover the viewport and iframe auth requires transient user activation, so silent SSO on load is unavailable.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "fallback-only"
}
Reverse-proxy chrome strippingrecord 45
{
  "id": "D05",
  "evidence_class": "observed",
  "source": "Apache: will not rewrite URL references inside HTML pages by default; mod_proxy_html has no knowledge of URLs within embedded script",
  "observed": "2026-08-27",
  "name": "Reverse-proxy chrome stripping",
  "family": "d",
  "claim": "Strip donor chrome at the proxy by rewriting HTML in flight.",
  "cost": "Medium and brittle",
  "falsifier": "Runtime-generated URLs have no documented fix, so the donor escapes the mount as soon as it builds a link in JS.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "reject"
}
Web Component / shadow DOM isolationrecord 46
{
  "id": "D06",
  "evidence_class": "observed",
  "source": "jd-opensource/micro-app docs; WHATWG same-root requirement for ARIA references",
  "observed": "2026-08-27",
  "name": "Web Component / shadow DOM isolation",
  "family": "d",
  "claim": "Mount the donor inside a custom element, optionally shadowed.",
  "cost": "Medium",
  "falsifier": "Enabling shadow DISABLES the default scoped isolation rather than layering with it, and aria-labelledby/aria-controls resolve to null across a shadow boundary.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "conditional"
}
Headless donor, host renders UIrecord 47
{
  "id": "D07",
  "evidence_class": "inferred",
  "source": "Refine, Tremor, Cube have no chrome to strip",
  "observed": "2026-08-27",
  "name": "Headless donor, host renders UI",
  "family": "d",
  "claim": "Take the donor's engine and API only; rebuild every surface in host components.",
  "cost": "Highest - a full UI build per donor",
  "falsifier": "The rebuild cost exceeds building the feature outright, making the donor pure liability.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "candidate-for-some"
}
Donor as embedded surface inside a host pagerecord 48
{
  "id": "D08",
  "evidence_class": "observed",
  "source": "TEABLE-ABSORPTION-BRIEF: 'Teable is NOT a page'; FROZEN-PAGE-SKELETON folds donors under 11 host pages",
  "observed": "2026-08-27",
  "name": "Donor as embedded surface inside a host page",
  "family": "d",
  "claim": "Donor renders as a component within a host-owned workflow page and is never a nav destination.",
  "cost": "Medium",
  "falsifier": "Donors that demand the full viewport or assume they own the document root cannot render below full-page.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "primary-candidate",
  "rank": 6,
  "rationale": "The Teable rule is stated as a rule with good reasoning, but its feasibility across donors is unverified. If donors demand the full viewport, the rule is unhonorable and Option 1 collapses into Option 5 or 6."
}
Donor as whole-slice page under host railrecord 49
{
  "id": "D09",
  "evidence_class": "observed",
  "source": "FROZEN-PAGE-SKELETON: Tasks = Plane (whole-slice); Grafana /a/<id>/* nesting",
  "observed": "2026-08-27",
  "name": "Donor as whole-slice page under host rail",
  "family": "d",
  "claim": "One host nav row hands the entire page to the donor, which keeps its internal nav below the rail.",
  "cost": "Low",
  "falsifier": "Donor internal nav uses donor vocabulary, teaching users the host is a wrapper rather than a product.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "candidate"
}
RouteRef indirection for donor linksrecord 50
{
  "id": "D10",
  "evidence_class": "observed",
  "source": "Backstage RouteRef and ExternalRouteRef bound in app-config.yaml",
  "observed": "2026-08-27",
  "name": "RouteRef indirection for donor links",
  "family": "d",
  "claim": "Donors declare routing targets, never URLs; host binds targets to concrete paths in config.",
  "cost": "Medium",
  "falsifier": "Donors with hardcoded absolute links cannot be retrofitted without patching their source on every upgrade.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "adopt-as-contract",
  "rank": 8,
  "rationale": "RouteRef indirection is the most reusable idea found in the entire OSS survey and it solves a problem Actionist will otherwise hit on the first cross-donor link. Adopting it early is far cheaper than retrofitting."
}
Donor admission test as a gaterecord 51
{
  "id": "D11",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Donor admission test as a gate",
  "family": "d",
  "claim": "Four binary questions per donor answered by real attempts, not doc reads, before any absorption work.",
  "cost": "1 day per donor",
  "falsifier": "If every donor passes trivially the gate was theatre; if none pass, absorption itself is the wrong strategy.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open",
  "rank": 1,
  "rationale": "Every other absorption decision is downstream of knowing which donors are actually absorbable. Three observed constraints already eliminate strategies (iframe modal confinement, one-way CSS isolation with unstyled portals, Module Federation's Bridge). This converts scattered constraints into one gate, and it is the cheapest high-leverage item in the register. It also directly targets A34, which remains UNKNOWN."
}
MountProfile per donorrecord 52
{
  "id": "D12",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "MountProfile per donor",
  "family": "d",
  "claim": "Record sub-path support, path-substitution timing, auth seam, chrome-disable mechanism, and licence constraint per donor.",
  "cost": "Low - a schema plus one row per donor",
  "falsifier": "Profiles go stale on donor upgrades faster than anyone maintains them.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Never let a donor pick a numeric positionrecord 53
{
  "id": "D13",
  "evidence_class": "observed",
  "source": "WordPress $position collisions patched by MD5 hash offset; Grafana addToNav boolean; Shopify s-app-nav",
  "observed": "2026-08-27",
  "name": "Never let a donor pick a numeric position",
  "family": "d",
  "claim": "Donors declare intent (label, icon, routeRef); the host assigns order.",
  "cost": "Low",
  "falsifier": "Host-assigned ordering may put a critical donor entry below the fold, and donors have no recourse.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "adopt-as-contract"
}
Server-driven donor surfacesrecord 54
{
  "id": "D14",
  "evidence_class": "inferred",
  "source": "Intercom Canvas Kit, Slack Block Kit",
  "observed": "2026-08-27",
  "name": "Server-driven donor surfaces",
  "family": "d",
  "claim": "Donor returns JSON describing its UI; host renders every pixel.",
  "cost": "High for donor authors, perfect consistency",
  "falsifier": "Expressiveness collapses: a donor whose value IS its interaction (a grid, an editor) cannot be expressed in host JSON.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Host component library for donorsrecord 55
{
  "id": "D15",
  "evidence_class": "inferred",
  "source": "Atlassian Forge UI Kit, HubSpot UI extensions, Retool",
  "observed": "2026-08-27",
  "name": "Host component library for donors",
  "family": "d",
  "claim": "Donors write declarative UI against host tokens and components.",
  "cost": "Medium-high",
  "falsifier": "Only donors written FOR the host can comply; no existing third-party app qualifies.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Closed surface cataloguerecord 56
{
  "id": "D16",
  "evidence_class": "inferred",
  "source": "Atlassian Forge module types; Zendesk ticket_sidebar/nav_bar/top_bar/modal",
  "observed": "2026-08-27",
  "name": "Closed surface catalogue",
  "family": "d",
  "claim": "Host enumerates every legal donor surface; anything not listed is impossible.",
  "cost": "Medium",
  "falsifier": "A closed catalogue blocks a donor whose value needs a surface nobody anticipated.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Admit no donor UI at allrecord 57
{
  "id": "D17",
  "evidence_class": "observed",
  "source": "AWS Console admits no third-party embedded UI",
  "observed": "2026-08-27",
  "name": "Admit no donor UI at all",
  "family": "d",
  "claim": "Donors contribute data and actions; the host renders 100% of the interface.",
  "cost": "High UI cost, zero absorption cost",
  "falsifier": "Rebuilding every donor surface is precisely the cost absorption exists to avoid.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "live-option"
}
Licence gate before chrome workrecord 58
{
  "id": "D18",
  "evidence_class": "observed",
  "source": "NocoBase 5.2 forbids removing branding; Directus MSCL forbids circumventing the licence key",
  "observed": "2026-08-27",
  "name": "Licence gate before chrome work",
  "family": "d",
  "claim": "Read the LICENSE body before planning any chrome removal.",
  "cost": "Very low",
  "falsifier": "None - this one is nearly free and has already caught two live cases.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "adopt-as-contract",
  "rank": 7,
  "rationale": "Nearly free, and it has already caught two live cases where chrome removal is a licence violation rather than an engineering task. In a client deliverable this is the error class that costs money rather than time."
}
Earned navrecord 59
{
  "id": "E01",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Earned nav",
  "family": "e",
  "claim": "Rail items appear only once the user has the data or permission to use them.",
  "cost": "Medium",
  "falsifier": "Users cannot find a feature they were told exists, and support cost exceeds the clarity gain.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Usage-ranked navrecord 60
{
  "id": "E02",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Usage-ranked nav",
  "family": "e",
  "claim": "Rail order adapts to per-user click frequency.",
  "cost": "Low-medium",
  "falsifier": "Moving targets destroy spatial memory; users hunt for an item that used to be third.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Stage-gated navrecord 61
{
  "id": "E03",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Stage-gated nav",
  "family": "e",
  "claim": "For case_workflow, nav reveals stages as the case advances.",
  "cost": "Medium",
  "falsifier": "Users need to look ahead to prepare; hiding future stages blocks planning.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Empty-state-aware navrecord 62
{
  "id": "E04",
  "evidence_class": "inferred",
  "source": "Common SaaS pattern; not verified in this run",
  "observed": "2026-08-27",
  "name": "Empty-state-aware nav",
  "family": "e",
  "claim": "Sections with zero records show a setup affordance rather than an empty list.",
  "cost": "Low",
  "falsifier": "Setup affordances that persist after setup become nagging dead weight.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Onboarding rail vs steady-state railrecord 63
{
  "id": "E05",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Onboarding rail vs steady-state rail",
  "family": "e",
  "claim": "A different, smaller rail for the first N sessions.",
  "cost": "Medium",
  "falsifier": "The transition is jarring and users must relearn the product at exactly the moment they felt competent.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Pinned + overflowrecord 64
{
  "id": "E06",
  "evidence_class": "inferred",
  "source": "Azure Portal favourites; common pattern",
  "observed": "2026-08-27",
  "name": "Pinned + overflow",
  "family": "e",
  "claim": "A short pinned set plus a 'more' surface holding everything else.",
  "cost": "Low",
  "falsifier": "Whatever is in overflow is effectively invisible, so the pinned default decides the product.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Role-progressive disclosurerecord 65
{
  "id": "E07",
  "evidence_class": "inferred",
  "source": "SISOCRM defines a brokerage role matrix with confidentiality overrides",
  "observed": "2026-08-27",
  "name": "Role-progressive disclosure",
  "family": "e",
  "claim": "Nav grows with the user's permissions rather than their tenure.",
  "cost": "Medium",
  "falsifier": "Permission changes silently restructure the UI, and users blame themselves for 'losing' a feature.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Vocabulary skinning layerrecord 66
{
  "id": "F01",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Vocabulary skinning layer",
  "family": "f",
  "claim": "One shell, one spine, per-industry entity names supplied as a config.",
  "cost": "Low once the spine exists",
  "falsifier": "If the state machines differ structurally between industries, renaming produces a product that uses the right words to do the wrong thing.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Vocabulary-isomorphism testrecord 67
{
  "id": "F02",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Vocabulary-isomorphism test",
  "family": "f",
  "claim": "Compare state machines, deadline rules and document sets across the six case_workflow industries after renaming.",
  "cost": "Desk research + expert interviews; days",
  "falsifier": "If overlap is high the per-industry template strategy is unjustified; if low, the rules engine is the real product.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open",
  "rank": 5,
  "rationale": "The commercially riskiest hypothesis in the register. case_workflow is primary for 6 of 17 industries; if those six differ only in vocabulary you have one product sold six ways, which changes pricing, positioning and how much per-industry work is justified. Either answer is worth a lot and neither requires a build."
}
Vocabulary as the only differentiator (null hypothesis)record 68
{
  "id": "F03",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Vocabulary as the only differentiator (null hypothesis)",
  "family": "f",
  "claim": "The six case_workflow industries differ ONLY in vocabulary.",
  "cost": "Free to state, cheap to test",
  "falsifier": "Deadline rules differ by regime (statutory vs contractual vs regulatory) in ways renaming cannot express.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Configurable stage machinerecord 69
{
  "id": "F04",
  "evidence_class": "inferred",
  "source": "b2b shelf: the state machine and who may advance it is what differentiates case_workflow",
  "observed": "2026-08-27",
  "name": "Configurable stage machine",
  "family": "f",
  "claim": "Stages, transitions and authority are data, not code.",
  "cost": "High - this is a real engine",
  "falsifier": "If every industry needs a code-level escape hatch anyway, configurability added complexity without removing work.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Deadline-rule engine as the productrecord 70
{
  "id": "F05",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Deadline-rule engine as the product",
  "family": "f",
  "claim": "The defensible asset for case_workflow is the deadline computation, not the shell.",
  "cost": "High",
  "falsifier": "If clients accept manual deadline entry, the engine is over-built relative to demand.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Per-industry document set templatesrecord 71
{
  "id": "F06",
  "evidence_class": "inferred",
  "source": "b2b shelf names document set as part of the case_workflow spine",
  "observed": "2026-08-27",
  "name": "Per-industry document set templates",
  "family": "f",
  "claim": "Ship the required document set per industry as a template.",
  "cost": "Medium",
  "falsifier": "Document sets vary per client within an industry more than between industries, making the template a starting point nobody keeps.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Mobile-first shell for field_operationsrecord 72
{
  "id": "G01",
  "evidence_class": "inferred",
  "source": "b2b shelf: offline capture and evidence as first-class data",
  "observed": "2026-08-27",
  "name": "Mobile-first shell for field_operations",
  "family": "g",
  "claim": "field_operations gets a distinct mobile shell: bottom bar, camera-first, one-handed reach.",
  "cost": "High - a second shell",
  "falsifier": "If field users actually work from a truck-mounted tablet in landscape, the one-handed assumption is wrong.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Offline-capable shellrecord 73
{
  "id": "G02",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Offline-capable shell",
  "family": "g",
  "claim": "Shell and nav function with no network; queued writes surface in the rail.",
  "cost": "High",
  "falsifier": "Donors with server-rendered UI cannot participate offline at all, so only host-built surfaces work.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Bottom bar below 768pxrecord 74
{
  "id": "G03",
  "evidence_class": "inferred",
  "source": "Polaris nav becomes full-width overlay below 768; Primer panes 100% width below 768",
  "observed": "2026-08-27",
  "name": "Bottom bar below 768px",
  "family": "g",
  "claim": "Rail becomes a bottom bar or full-width overlay under 768px.",
  "cost": "Low",
  "falsifier": "Bottom bars cap at ~5 items, so an 8-item rail must hide 3 behind 'more' on exactly the device with least screen.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Donor mobile behaviour is unowned riskrecord 75
{
  "id": "G04",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Donor mobile behaviour is unowned risk",
  "family": "g",
  "claim": "Donor responsive behaviour cannot be assumed and must be tested per donor per breakpoint.",
  "cost": "Medium per donor",
  "falsifier": "A donor that is simply unusable below 1024px forces desktop-only for any page it occupies.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Portal shell is minimal by requirementrecord 76
{
  "id": "G05",
  "evidence_class": "inferred",
  "source": "b2b shelf: a portal is an authorization product before it is a UI",
  "observed": "2026-08-27",
  "name": "Portal shell is minimal by requirement",
  "family": "g",
  "claim": "The portal shell carries almost no chrome - no internal nav, no global search, no tenant switch.",
  "cost": "Low",
  "falsifier": "Portal users need MORE orientation, not less, and a bare shell leaves them unable to find what they came for.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Touch target floor in the railrecord 77
{
  "id": "G06",
  "evidence_class": "inferred",
  "source": "Material 3 rail tokens; standard accessibility guidance",
  "observed": "2026-08-27",
  "name": "Touch target floor in the rail",
  "family": "g",
  "claim": "Rail items meet a minimum touch target on all devices.",
  "cost": "Low",
  "falsifier": "Meeting the floor forces fewer visible items, pushing the rail past its budget.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Machine-readable nav manifestrecord 78
{
  "id": "H01",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Machine-readable nav manifest",
  "family": "h",
  "claim": "The shell emits a manifest of every nav node, route and required capability that an agent can traverse.",
  "cost": "Low-medium",
  "falsifier": "Manifest drifts from reality unless generated from the same source as the rail; a stale manifest is worse than none.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Nav derived from route registrationrecord 79
{
  "id": "H02",
  "evidence_class": "observed",
  "source": "Backstage removed NavItemBlueprint in favour of deriving nav from PageBlueprint title/icon",
  "observed": "2026-08-27",
  "name": "Nav derived from route registration",
  "family": "h",
  "claim": "Nav cannot drift from routes because it is derived from them.",
  "cost": "Medium",
  "falsifier": "Routes that should not appear in nav need an opt-out, which reintroduces a second source of truth.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "adopt-as-contract",
  "rank": 9,
  "rationale": "Deriving nav from route registration eliminates a whole class of 'nav points at a dead route' bugs by construction, and Backstage removed its own nav-item API in favour of exactly this - a mature project's second answer is worth more than its first."
}
Deep-link addressability contractrecord 80
{
  "id": "H03",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Deep-link addressability contract",
  "family": "h",
  "claim": "Every meaningful state has a URL an agent can navigate to directly.",
  "cost": "Medium",
  "falsifier": "Donor internal state (an open modal, a selected grid cell) is often not addressable, capping coverage at the donor boundary.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
data-verify attributes on navrecord 81
{
  "id": "H04",
  "evidence_class": "inferred",
  "source": "Local verifiable-frontend work uses a data-verify-* contract with window.__verify, DEV-only",
  "observed": "2026-08-27",
  "name": "data-verify attributes on nav",
  "family": "h",
  "claim": "Every nav node carries a stable machine-readable identifier for verification.",
  "cost": "Low",
  "falsifier": "Attributes must be tree-shaken from production or they become an attack surface and a payload cost.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Nav as a testable artifactrecord 82
{
  "id": "H05",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Nav as a testable artifact",
  "family": "h",
  "claim": "Nav topology is asserted in tests: budget cap, depth limit, no orphan routes, no dead links.",
  "cost": "Low",
  "falsifier": "Tests pass on a nav that is structurally valid and semantically meaningless - exactly the current five-slot situation.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Agent-operable settingsrecord 83
{
  "id": "H06",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Agent-operable settings",
  "family": "h",
  "claim": "Settings are addressable and settable through the same contract as nav.",
  "cost": "Medium",
  "falsifier": "Donor settings behind donor UI are not addressable, so coverage is partial and the gaps are invisible.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Shell as a compiled artifactrecord 84
{
  "id": "I01",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Shell as a compiled artifact",
  "family": "i",
  "claim": "The builder emits shell source that is then owned and editable.",
  "cost": "Medium",
  "falsifier": "Regeneration conflicts with hand edits, and clients edit immediately.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Shell as runtime configrecord 85
{
  "id": "I02",
  "evidence_class": "inferred",
  "source": "Luigi is fully config-driven navigation",
  "observed": "2026-08-27",
  "name": "Shell as runtime config",
  "family": "i",
  "claim": "The shell is data interpreted at runtime; regeneration is a config swap.",
  "cost": "Medium",
  "falsifier": "Config-driven shells cap expressiveness at whatever the interpreter supports, and the first bespoke request breaks the model.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Determinism checkrecord 86
{
  "id": "I03",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Determinism check",
  "family": "i",
  "claim": "Run the generator twice on identical inputs and diff byte-for-byte.",
  "cost": "One hour",
  "falsifier": "Any semantic difference falsifies shell-diffing, golden-file testing and version pinning simultaneously.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open",
  "rank": 4,
  "rationale": "Ranked purely on cost-to-information ratio - it takes an hour. If shell generation is non-deterministic, then shell diffing, golden corpora, regeneration merges and route stability are all built on sand, and you need to know that before designing any of them."
}
Shell diffing across regenerationsrecord 87
{
  "id": "I04",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Shell diffing across regenerations",
  "family": "i",
  "claim": "Show the client what changed in the shell between generations.",
  "cost": "Medium",
  "falsifier": "Requires determinism (I03); without it the diff is noise.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Visual side-nav variant chooserrecord 88
{
  "id": "I05",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Visual side-nav variant chooser",
  "family": "i",
  "claim": "The client picks a rail variant visually from a small set.",
  "cost": "Medium",
  "falsifier": "Clients pick on aesthetics and pick the variant worst suited to their archetype.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Route stability across regenerationrecord 89
{
  "id": "I06",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Route stability across regeneration",
  "family": "i",
  "claim": "URLs survive shell regeneration so links and bookmarks do not rot.",
  "cost": "Medium",
  "falsifier": "Adding an archetype-native topology inherently changes routes, so stability and improvement conflict.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Golden shell corpusrecord 90
{
  "id": "I07",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Golden shell corpus",
  "family": "i",
  "claim": "A fixed set of input specs with expected shell outputs as regression tests.",
  "cost": "Medium",
  "falsifier": "Depends on determinism; and golden files entrench whatever was generated first, including its mistakes.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Generation-time nav budget enforcementrecord 91
{
  "id": "I08",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "Generation-time nav budget enforcement",
  "family": "i",
  "claim": "The generator refuses to emit a shell exceeding the budget cap or depth limit.",
  "cost": "Low",
  "falsifier": "A hard refusal blocks legitimate edge cases and gets disabled the first time it fires on a real client.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Nav budget cap as policyrecord 92
{
  "id": "J01",
  "evidence_class": "inferred",
  "source": "IBM Carbon left-panel rule",
  "observed": "2026-08-27",
  "name": "Nav budget cap as policy",
  "family": "j",
  "claim": "A hard maximum on top-level rail items, enforced and reported.",
  "cost": "Low",
  "falsifier": "The cap is arbitrary without evidence; Carbon's >5 rule is guidance about secondary nav, not a validated top-level limit.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Depth limit as policyrecord 93
{
  "id": "J02",
  "evidence_class": "inferred",
  "source": "Carbon: left panel does not support three tiers",
  "observed": "2026-08-27",
  "name": "Depth limit as policy",
  "family": "j",
  "claim": "Maximum two tiers of navigation anywhere in a generated shell.",
  "cost": "Low",
  "falsifier": "Archetypes with real three-level structure get flattened into something worse.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Donor nav admission rulerecord 94
{
  "id": "J03",
  "evidence_class": "inferred",
  "source": "TEABLE-ABSORPTION-BRIEF; FROZEN-PAGE-SKELETON gives exactly one whole-slice donor",
  "observed": "2026-08-27",
  "name": "Donor nav admission rule",
  "family": "j",
  "claim": "A donor gets a nav row only if it is a destination, not a capability.",
  "cost": "Low",
  "falsifier": "The destination/capability line is judgement, and reasonable people will draw it differently per donor.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "adopt-as-contract"
}
At most two whole-slice donors per productrecord 95
{
  "id": "J04",
  "evidence_class": "hypothesis",
  "source": "P08 innovation lane, 2026-08-27",
  "observed": "2026-08-27",
  "name": "At most two whole-slice donors per product",
  "family": "j",
  "claim": "Cap the number of donors that get their own page and internal nav.",
  "cost": "Low",
  "falsifier": "The cap is invented; SISOCRM chose exactly one, which is a sample of one.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Retire the fixed five-tuple typerecord 96
{
  "id": "J05",
  "evidence_class": "observed",
  "source": "sidebar-factory.tsx:19-25 types sections as a fixed five-element tuple",
  "observed": "2026-08-27",
  "name": "Retire the fixed five-tuple type",
  "family": "j",
  "claim": "Replace the compile-time 5-tuple with a validated variable-length list.",
  "cost": "Low - a type change plus call-site updates",
  "falsifier": "If every generated shell lands on five anyway, the type was harmless and the change bought nothing.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "recommended",
  "rank": 2,
  "rationale": "The largest inherited assumption in P08, now shown to be a compile-time constraint whose slot ids have already lost meaning across two personas in one codebase. It is load-bearing for every generated app and cheap to test with paper navs before any code changes."
}
Slot ids must be semanticrecord 97
{
  "id": "J06",
  "evidence_class": "observed",
  "source": "ISSO 'recon' means Team in one rail and Tasks in another; 'content-gen' means Tools and Insights",
  "observed": "2026-08-27",
  "name": "Slot ids must be semantic",
  "family": "j",
  "claim": "Nav slot identifiers must name the work, not a positional product id.",
  "cost": "Low",
  "falsifier": "Semantic ids are harder to keep stable across regenerations than positional ones.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "recommended"
}
One owner per nav rowrecord 98
{
  "id": "J07",
  "evidence_class": "inferred",
  "source": "OWNERSHIP-AND-DATA-LAYER-DECISIONS: one owner per table, never two",
  "observed": "2026-08-27",
  "name": "One owner per nav row",
  "family": "j",
  "claim": "Every rail row has exactly one owning system; no shared rows.",
  "cost": "Low",
  "falsifier": "Genuinely cross-cutting surfaces (a unified inbox over three donors) have no single owner by construction.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "hypothesis-open"
}
Do not build marketplacerecord 99
{
  "id": "J08",
  "evidence_class": "observed",
  "source": "b2b shelf: marketplace is primary for none and secondary for none across 17 industries",
  "observed": "2026-08-27",
  "name": "Do not build marketplace",
  "family": "j",
  "claim": "The marketplace archetype has zero demand anchor and should not be built speculatively.",
  "cost": "Zero - a decision not to spend",
  "falsifier": "A client arrives whose product genuinely is two-sided, and the archetype is missing.",
  "limitations": "Not tested; no user data exists for any option in this register.",
  "disposition": "recommended",
  "rank": 10,
  "rationale": "A decision not to spend, justified by a computed zero across 17 industries. Cheap to adopt, and it protects the build order for the two archetypes that actually carry demand."
}
Two rail width classes, not a continuumrecord 100
{
  "id": "B11",
  "evidence_class": "inferred",
  "source": "WordPress #adminmenu 160px vs Zendesk 320 / Grafana 320 / Metabase 324",
  "observed": "2026-08-27",
  "name": "Two rail width classes, not a continuum",
  "family": "b",
  "claim": "Rail widths cluster into two functional classes rather than a continuum: ~160px forces donors to flatten their nav and use flyouts, while ~320px is wide enough to host a donor's nested nav inline. Choosing a width is therefore choosing whether donors may keep hierarchy.",
  "cost": "Zero - it is a specification choice made once",
  "falsifier": "Measure real donor nav labels; if the median exceeds 320px at readable type sizes then neither class supports inline hierarchy and all donors must flatten regardless.",
  "limitations": "Clustering observed across four products; no vendor publishes rationale for any of the numbers.",
  "disposition": "hypothesis-open"
}