What concrete public card, detail, and search presentation should show modeled text first, exact authored fallback prose when modeling is absent or stale, and a binary MODELED / NOT MODELED state consistently across Talent, OS Protocol Talent, Skill Chip Talent, and Specialization tree-rank effects without leaking internal lifecycle distinctions?
Part of #1
Blocked by: #2
## Question
What concrete public card, detail, and search presentation should show modeled text first, exact authored fallback prose when modeling is absent or stale, and a binary `MODELED` / `NOT MODELED` state consistently across Talent, OS Protocol Talent, Skill Chip Talent, and Specialization tree-rank effects without leaking internal lifecycle distinctions?
Adopt prototype Variant A, the integrated card hierarchy, for the Public Database. Keep Variant C on the prototype branch as precedent for a possible future ISAC mechanic registry; it does not change this public implementation.
full card and nested quick-view detail presentations;
global results on /database;
Talent, OS Protocol Talent, Skill Chip Talent, and Specialization tree-rank effect owners.
ISAC registries, Builder readiness, Modeling Session controls, and internal mechanic-reference pages remain unchanged except where they need shared data loaders.
Card hierarchy
Each mechanic owner card places a textual MODELED or NOT MODELED badge in the identity header. Status cannot rely on color. MODELED uses the established model surface, border, and blue status treatment. NOT MODELED uses neutral border and muted text. Orange remains reserved for links, selection, and action.
The card contains one primary behavior block in the position where readers currently expect the owner description:
a current valid model displays deterministic public behavior text rendered from the selected Mechanic Program;
an absent or stale model displays the exact materialized authored description;
an empty captured placeholder counts as absent;
ready, requires_assumptions, and non-empty valid captured_only models all display MODELED.
The behavior block labels its basis as MODELED BEHAVIOR or AUTHORED DESCRIPTION. It never displays stale, readiness, Scenario Input requirements, capability gaps, source hashes, revision IDs, or other internal lifecycle data.
Talent cards preserve the Tier I/Tier II hierarchy. Each tier shows its matching modeled rendering or authored variant. An Exotic with no Tier II renders Tier I only. OS Protocol uses the base rendering and retains its existing level and upgrade controls. Skill Chip Talent renders minimum and maximum variants within its three-piece section. Specialization cards add a rank-effect section that groups effects under Focus, node, and rank identity.
Modeled behavior renderer
Public modeled text comes from a deterministic renderer over the selected structured program. The application does not store or expose model-generated prose as a separate public authority. The renderer uses registered Event, condition, state, Outcome, duration, Cooldown, stack, Attribute, and variant labels and produces stable text for snapshots and search indexing.
If the selected graph cannot render under the installed contract, model validity fails and public presentation falls back to the authored description with NOT MODELED. Public routes never show raw JSON, pseudo-script syntax, unsupported tokens, or stale modeled output.
Detail and quick view
Quick views repeat the same badge and behavior-selection rule at larger reading width. They include DISPLAY SOURCE: MODELED BEHAVIOR or DISPLAY SOURCE: AUTHORED DESCRIPTION. That label explains the text without exposing why a record is not modeled.
Existing modal focus trapping, Escape handling, trigger-focus restoration, icon placeholders, Community Notes, correction links, and discussion controls remain intact. The status and source labels precede community controls in reading order.
Specialization detail exposes tree-rank effects even though the current public card shows only parent counts. Each effect displays its rank context, binary status, and selected behavior text. Reusable Specialization effect templates remain internal and do not gain a standalone public page.
Global search
Global search indexes and returns the behavior text currently shown to the public. Search results include owner category, record name, concise behavior text, and the textual binary badge. Specialization indexing expands to tree nodes, ranks, and rank-effect behavior.
A stale modeled rendering must leave the search index in the same transaction that changes the authored source fingerprint. Search and card loaders use the same public projection so they cannot disagree about status or text.
Long behavior text truncates visually in compact results while remaining available to assistive technology and on the linked card. Links retain the existing registry navigation and focus behavior.
Responsive and interaction states
The selected structure follows the current three-, two-, and one-column Public Database breakpoints. Badges remain adjacent to the identity header without reducing behavior text below a readable width. Mobile layouts stack the badge after identity and before behavior.
Production implementation covers hover, pressed, focus-visible, loading, empty, error, and reduced-motion states. Status changes do not animate in a way that suggests live simulation. MODELED and NOT MODELED meet text and border contrast requirements in every quality treatment.
This significant presentation decision updates docs/DESIGN_SYSTEM.md, reuses or extends tokens in src/app.css, and extends shared DatabaseItemCard and search-result DTOs rather than adding owner-local markup.
Acceptance checks
Every public owner card and quick view shows exactly one binary status.
Current valid models show deterministic modeled behavior; absent and stale owners show exact authored fallback.
Public output never reveals internal readiness or stale-versus-absent distinctions.
Talent, Exotic, OS Protocol, Skill Chip, and Specialization variant contracts render correctly.
Card, quick-view, and search surfaces use one shared public projection.
Search never retains stale modeled text after an authored edit.
Keyboard, screen-reader, responsive, contrast, and reduced-motion checks pass.
The Public Database adopts Variant A; Variant C remains only on the prototype branch as future ISAC precedent.
# Public fallback and model status presentation
## Selected direction
Adopt prototype Variant A, the integrated card hierarchy, for the Public Database. Keep Variant C on the prototype branch as precedent for a possible future ISAC mechanic registry; it does not change this public implementation.
Primary source: [`prototype/issue-5-model-status` at `904cb07`](https://git.jb.codes/jb/shd.build/src/commit/904cb07). The prototype covers cards, quick views, and global search for all four owner types.
## Public surfaces
The production change applies to:
- category cards on `/database/[category]`;
- full card and nested quick-view detail presentations;
- global results on `/database`;
- Talent, OS Protocol Talent, Skill Chip Talent, and Specialization tree-rank effect owners.
ISAC registries, Builder readiness, Modeling Session controls, and internal mechanic-reference pages remain unchanged except where they need shared data loaders.
## Card hierarchy
Each mechanic owner card places a textual `MODELED` or `NOT MODELED` badge in the identity header. Status cannot rely on color. `MODELED` uses the established model surface, border, and blue status treatment. `NOT MODELED` uses neutral border and muted text. Orange remains reserved for links, selection, and action.
The card contains one primary behavior block in the position where readers currently expect the owner description:
- a current valid model displays deterministic public behavior text rendered from the selected Mechanic Program;
- an absent or stale model displays the exact materialized authored description;
- an empty captured placeholder counts as absent;
- `ready`, `requires_assumptions`, and non-empty valid `captured_only` models all display `MODELED`.
The behavior block labels its basis as `MODELED BEHAVIOR` or `AUTHORED DESCRIPTION`. It never displays `stale`, readiness, Scenario Input requirements, capability gaps, source hashes, revision IDs, or other internal lifecycle data.
Talent cards preserve the Tier I/Tier II hierarchy. Each tier shows its matching modeled rendering or authored variant. An Exotic with no Tier II renders Tier I only. OS Protocol uses the base rendering and retains its existing level and upgrade controls. Skill Chip Talent renders minimum and maximum variants within its three-piece section. Specialization cards add a rank-effect section that groups effects under Focus, node, and rank identity.
## Modeled behavior renderer
Public modeled text comes from a deterministic renderer over the selected structured program. The application does not store or expose model-generated prose as a separate public authority. The renderer uses registered Event, condition, state, Outcome, duration, Cooldown, stack, Attribute, and variant labels and produces stable text for snapshots and search indexing.
If the selected graph cannot render under the installed contract, model validity fails and public presentation falls back to the authored description with `NOT MODELED`. Public routes never show raw JSON, pseudo-script syntax, unsupported tokens, or stale modeled output.
## Detail and quick view
Quick views repeat the same badge and behavior-selection rule at larger reading width. They include `DISPLAY SOURCE: MODELED BEHAVIOR` or `DISPLAY SOURCE: AUTHORED DESCRIPTION`. That label explains the text without exposing why a record is not modeled.
Existing modal focus trapping, Escape handling, trigger-focus restoration, icon placeholders, Community Notes, correction links, and discussion controls remain intact. The status and source labels precede community controls in reading order.
Specialization detail exposes tree-rank effects even though the current public card shows only parent counts. Each effect displays its rank context, binary status, and selected behavior text. Reusable Specialization effect templates remain internal and do not gain a standalone public page.
## Global search
Global search indexes and returns the behavior text currently shown to the public. Search results include owner category, record name, concise behavior text, and the textual binary badge. Specialization indexing expands to tree nodes, ranks, and rank-effect behavior.
A stale modeled rendering must leave the search index in the same transaction that changes the authored source fingerprint. Search and card loaders use the same public projection so they cannot disagree about status or text.
Long behavior text truncates visually in compact results while remaining available to assistive technology and on the linked card. Links retain the existing registry navigation and focus behavior.
## Responsive and interaction states
The selected structure follows the current three-, two-, and one-column Public Database breakpoints. Badges remain adjacent to the identity header without reducing behavior text below a readable width. Mobile layouts stack the badge after identity and before behavior.
Production implementation covers hover, pressed, focus-visible, loading, empty, error, and reduced-motion states. Status changes do not animate in a way that suggests live simulation. `MODELED` and `NOT MODELED` meet text and border contrast requirements in every quality treatment.
This significant presentation decision updates `docs/DESIGN_SYSTEM.md`, reuses or extends tokens in `src/app.css`, and extends shared `DatabaseItemCard` and search-result DTOs rather than adding owner-local markup.
## Acceptance checks
- Every public owner card and quick view shows exactly one binary status.
- Current valid models show deterministic modeled behavior; absent and stale owners show exact authored fallback.
- Public output never reveals internal readiness or stale-versus-absent distinctions.
- Talent, Exotic, OS Protocol, Skill Chip, and Specialization variant contracts render correctly.
- Card, quick-view, and search surfaces use one shared public projection.
- Search never retains stale modeled text after an authored edit.
- Keyboard, screen-reader, responsive, contrast, and reduced-motion checks pass.
- The Public Database adopts Variant A; Variant C remains only on the prototype branch as future ISAC precedent.
Variant A is selected for the Public Database. Variant C remains on the linked prototype branch as future ISAC precedent. The specification above defines card, quick-view, search, deterministic rendering, Specialization rank effects, responsive behavior, and design-system maintenance. Closing as resolved.
Variant A is selected for the Public Database. Variant C remains on the linked prototype branch as future ISAC precedent. The specification above defines card, quick-view, search, deterministic rendering, Specialization rank effects, responsive behavior, and design-system maintenance. Closing as resolved.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of #1
Blocked by: #2
Question
What concrete public card, detail, and search presentation should show modeled text first, exact authored fallback prose when modeling is absent or stale, and a binary
MODELED/NOT MODELEDstate consistently across Talent, OS Protocol Talent, Skill Chip Talent, and Specialization tree-rank effects without leaking internal lifecycle distinctions?Public fallback and model status presentation
Selected direction
Adopt prototype Variant A, the integrated card hierarchy, for the Public Database. Keep Variant C on the prototype branch as precedent for a possible future ISAC mechanic registry; it does not change this public implementation.
Primary source:
prototype/issue-5-model-statusat904cb07. The prototype covers cards, quick views, and global search for all four owner types.Public surfaces
The production change applies to:
/database/[category];/database;ISAC registries, Builder readiness, Modeling Session controls, and internal mechanic-reference pages remain unchanged except where they need shared data loaders.
Card hierarchy
Each mechanic owner card places a textual
MODELEDorNOT MODELEDbadge in the identity header. Status cannot rely on color.MODELEDuses the established model surface, border, and blue status treatment.NOT MODELEDuses neutral border and muted text. Orange remains reserved for links, selection, and action.The card contains one primary behavior block in the position where readers currently expect the owner description:
ready,requires_assumptions, and non-empty validcaptured_onlymodels all displayMODELED.The behavior block labels its basis as
MODELED BEHAVIORorAUTHORED DESCRIPTION. It never displaysstale, readiness, Scenario Input requirements, capability gaps, source hashes, revision IDs, or other internal lifecycle data.Talent cards preserve the Tier I/Tier II hierarchy. Each tier shows its matching modeled rendering or authored variant. An Exotic with no Tier II renders Tier I only. OS Protocol uses the base rendering and retains its existing level and upgrade controls. Skill Chip Talent renders minimum and maximum variants within its three-piece section. Specialization cards add a rank-effect section that groups effects under Focus, node, and rank identity.
Modeled behavior renderer
Public modeled text comes from a deterministic renderer over the selected structured program. The application does not store or expose model-generated prose as a separate public authority. The renderer uses registered Event, condition, state, Outcome, duration, Cooldown, stack, Attribute, and variant labels and produces stable text for snapshots and search indexing.
If the selected graph cannot render under the installed contract, model validity fails and public presentation falls back to the authored description with
NOT MODELED. Public routes never show raw JSON, pseudo-script syntax, unsupported tokens, or stale modeled output.Detail and quick view
Quick views repeat the same badge and behavior-selection rule at larger reading width. They include
DISPLAY SOURCE: MODELED BEHAVIORorDISPLAY SOURCE: AUTHORED DESCRIPTION. That label explains the text without exposing why a record is not modeled.Existing modal focus trapping, Escape handling, trigger-focus restoration, icon placeholders, Community Notes, correction links, and discussion controls remain intact. The status and source labels precede community controls in reading order.
Specialization detail exposes tree-rank effects even though the current public card shows only parent counts. Each effect displays its rank context, binary status, and selected behavior text. Reusable Specialization effect templates remain internal and do not gain a standalone public page.
Global search
Global search indexes and returns the behavior text currently shown to the public. Search results include owner category, record name, concise behavior text, and the textual binary badge. Specialization indexing expands to tree nodes, ranks, and rank-effect behavior.
A stale modeled rendering must leave the search index in the same transaction that changes the authored source fingerprint. Search and card loaders use the same public projection so they cannot disagree about status or text.
Long behavior text truncates visually in compact results while remaining available to assistive technology and on the linked card. Links retain the existing registry navigation and focus behavior.
Responsive and interaction states
The selected structure follows the current three-, two-, and one-column Public Database breakpoints. Badges remain adjacent to the identity header without reducing behavior text below a readable width. Mobile layouts stack the badge after identity and before behavior.
Production implementation covers hover, pressed, focus-visible, loading, empty, error, and reduced-motion states. Status changes do not animate in a way that suggests live simulation.
MODELEDandNOT MODELEDmeet text and border contrast requirements in every quality treatment.This significant presentation decision updates
docs/DESIGN_SYSTEM.md, reuses or extends tokens insrc/app.css, and extends sharedDatabaseItemCardand search-result DTOs rather than adding owner-local markup.Acceptance checks
Variant A is selected for the Public Database. Variant C remains on the linked prototype branch as future ISAC precedent. The specification above defines card, quick-view, search, deterministic rendering, Specialization rank effects, responsive behavior, and design-system maintenance. Closing as resolved.