Build the clickable POC prototype for the internal demo #37

New Issue

christian · 2026-08-03T20:52:59Z

christian commented

2026-08-03 20:52:59 +00:00

Question

The artifact for the first internal POC meeting, chosen by author direction over a decision review
and over a working end-to-end slice.

What it shows. The six surfaces from the app framework, styled, navigable, populated
with real content from the synthesized corpus: one solicitation with its confirmed requirement
overlay, four responses, the evaluation matrix populated with coverage states and per-scenario
cost, the invitation wall, and the Pro affordances visible-but-locked.

What it does not have. No RLS, no scheduler, no extraction, no billing. Every one of those is
mocked. This demonstrates the design and the domain model; it does not exercise the architecture.

Resolve on the way: which single narrative path the demo walks - most likely issue, invite, bid,
seal, open, evaluate - and which decisions are worth making visible in it. Several resolutions are
only legible as behaviour rather than as screens: the sealed-until-deadline transition, the
suggestion-versus-committed-score distinction, and the amendment that reopens one answer. A demo
that skips those shows a generic procurement tool.

Neutrality must be visible, not merely true. Because the venue carries the HelmDocs brand,
the demo cannot rely on brand distance to answer "why is the bid-writing company running my
evaluation?" The walk should make the mechanisms legible: bids sealed until the deadline, every
score created by a human commit, the model barred from gates and arithmetic.

Scope boundary, stated so it does not drift. This is a prototype, not the first build. It is
allowed to be throwaway and should not be mistaken for the code layout, which is the map's actual
destination and is a separate artifact.

Parent: #1

## Question The artifact for the first internal POC meeting, chosen by author direction over a decision review and over a working end-to-end slice. **What it shows.** The six surfaces from [the app framework](https://gitea.stephenmann.io/christian/helmdocs-proposal-system/issues/23), styled, navigable, populated with real content from the synthesized corpus: one solicitation with its confirmed requirement overlay, four responses, the evaluation matrix populated with coverage states and per-scenario cost, the invitation wall, and the Pro affordances visible-but-locked. **What it does not have.** No RLS, no scheduler, no extraction, no billing. Every one of those is mocked. This demonstrates the design and the domain model; it does not exercise the architecture. Resolve on the way: which single narrative path the demo walks - most likely issue, invite, bid, seal, open, evaluate - and which decisions are worth making visible in it. Several resolutions are only legible as behaviour rather than as screens: the sealed-until-deadline transition, the suggestion-versus-committed-score distinction, and the amendment that reopens one answer. A demo that skips those shows a generic procurement tool. **Neutrality must be visible, not merely true.** Because the venue carries the HelmDocs brand, the demo cannot rely on brand distance to answer "why is the bid-writing company running my evaluation?" The walk should make the mechanisms legible: bids sealed until the deadline, every score created by a human commit, the model barred from gates and arithmetic. **Scope boundary, stated so it does not drift.** This is a prototype, not the first build. It is allowed to be throwaway and should not be mistaken for the code layout, which is the map's actual destination and is a separate artifact. --- Parent: #1

christian added the

wayfinder:prototype

wayfinder:ticket

labels 2026-08-03 20:52:59 +00:00

christian added a new dependency 2026-08-03 20:52:59 +00:00

#36 Define the v1 component system and visual identity

christian added a new dependency 2026-08-03 20:52:59 +00:00

#30 Build the synthesized response corpus

christian referenced this issue

2026-08-03 20:52:59 +00:00

Retail RFP transmission system — v1 build spec #1

christian referenced this issue

2026-08-03 21:30:20 +00:00

Define the v1 component system and visual identity #36

christian referenced this issue

2026-08-03 21:49:21 +00:00

Build the synthesized response corpus #30

christian referenced this issue

2026-08-03 23:53:34 +00:00

Define the v1 component system and visual identity #36

christian self-assigned this 2026-08-03 23:56:57 +00:00

christian commented

2026-08-04 00:07:35 +00:00

Resolution

The prototype: https://claude.ai/code/artifact/5b871a79-c939-4c15-a6a5-d572d6937bd1 — eight steps, arrow keys or the rail, on the Friendship PCS corpus.
Built on the component system fixed by #36.

The walk, and why it is this one

The ticket asked which single narrative path the demo takes. It is issue → seal → switch → bid →
open → evaluate → amend, and the switch is load-bearing rather than decorative: walking one
capability start-to-finish shows a procurement tool, and the whole thesis of this product is that
the two sides are one venue with a boundary through the middle. The walk crosses that boundary in
the middle of a live solicitation, which is the only way to show it.

Step	Surface	What is actually being shown
1 Confirm	Compose	The ledger is ordered by uncertainty, not by page. Two of the top three were caught by the completeness sweep, not the extractor.
2 Issue	Issued	Three responses received, zero readable. Sealed is a state on screen, not a claim in a deck.
3 Switch	Invitation wall	Nav swaps wholesale, `Acting as` changes, and the wall shows issuer / category / deadline and nothing else.
4 Bid	Bid workspace	Requirement-led. `R-B6C` reads not evaluable, never failing.
5 Vault	Eligibility	Expiry phrased as consequence — "you drop out of three rosters". Pro locked and legible.
6 Open	Evaluation	The whole field opens at once.
7 Commit	Evaluation	Dashed proposals; the drawer carries evidence, anchor and provenance; your commit creates the score.
8 Amend	Evaluation	A substantive amendment voids what it touches.

The three that are only legible as behaviour

The ticket named these specifically, and they are the reason this is clickable rather than a
screenshot deck.

Sealed → open. Step 2 shows an evaluation surface that exists and is empty by construction —
not an empty state, a withheld one. Advancing the deadline fills it in one move.

Suggestion versus committed score. Every scored cell starts dashed. Opening one gives the
verbatim evidence span, the matched anchor with the full scale beside it, and the note that the
criterion→requirement mapping was authored, not extracted. Committing turns the cell solid and
moves the footer from — · 0/10 committed to a real number. Gates have no drawer at all —
there is nothing to propose, because the model is barred from them.

The amendment. Step 8 voids GEO_PREF across the live field, and its drawer explains that the
previous commit is retained in the record but no longer counts. Scores are destroyed and re-earned,
never silently recomputed.

Neutrality, made visible rather than argued

Because the venue carries the bidder-tools brand, these had to be mechanisms on screen:

the sealed field, and the deadline that opens it for everyone simultaneously
Commit scores as the loudest control on the evaluation surface — a human act, not a batch job
the gate band, computed and unproposable, sitting above everything the model touched
indeterminate marks that route to a person instead of resolving themselves

None of that is a claim about intent. It is all observable in ten seconds of clicking.

Two design bugs the build found

Both were invisible on the static system page and appeared the moment real state moved. Recording
them because they are findings about the design, not about the prototype:

Roll-up rows blended committed and proposed scores into one number. Method of Approach read
23.75 while only one of its three children had been committed — a number that looks like a score,
is presented like a score, and is mostly suggestion. This is the exact sin #15 exists to prevent,
reproduced by an innocent-looking sum. A roll-up must total committed children only, and show
its denominator: 9.00 · 1/3, or — at zero.

Voiding did not propagate to the totals. After the amendment, a voided cell rendered correctly
as voided while its value quietly survived in the committed total and the 1/10 count. The
amendment appeared to work and did not.

Both are now fixed in the prototype, and both are constraints on <EvaluationMatrix>: totals
and roll-ups must read through a single "is this an effective score" predicate, never off the raw
commit map. Handed to whoever builds it for real.

Verified, and not

Walked end to end in a browser: all eight steps, the capability switch, the seal→open transition, a
live commit with the footer updating, and the amendment voiding across two vendors. node --check
clean.

Not verified: it renders blank in an automated Chrome profile via the artifact viewer while
rendering correctly when served directly — the same is true of #36's static page, which has no
script at all, so this is the viewer in that profile rather than either file. Worth one manual
check on the demo machine before the meeting rather than discovering it in the room.

Scope, held

No RLS, no scheduler, no extraction, no billing — all mocked, as the ticket specified. This is
throwaway and is not the code layout, which remains the map's destination and lives in src/.
The corpus numbers are real; the scores over them are authored for the demo, and the narratives
they produce (cheapest bid disqualified; 82.15 against 81.90) come from the corpus ground truth.

What the first real build will find that this cannot

Column resize past ten vendors, virtualisation against a sticky footer, and how expand-in-place
interacts with horizontal scroll. The 360/132/34px geometry from #36 survived three bidders and
seventeen rows; it has not met two hundred.

## Resolution **The prototype:** https://claude.ai/code/artifact/5b871a79-c939-4c15-a6a5-d572d6937bd1 — eight steps, arrow keys or the rail, on the Friendship PCS corpus. Built on the component system fixed by [#36](https://claude.ai/code/artifact/c69c2fa3-3b4d-42b8-902c-a1b62259e5ec). ### The walk, and why it is this one The ticket asked which single narrative path the demo takes. It is **issue → seal → switch → bid → open → evaluate → amend**, and the switch is load-bearing rather than decorative: walking one capability start-to-finish shows a procurement tool, and the whole thesis of this product is that the two sides are one venue with a boundary through the middle. The walk crosses that boundary in the middle of a live solicitation, which is the only way to show it. | Step | Surface | What is actually being shown | |---|---|---| | 1 Confirm | Compose | The ledger is ordered **by uncertainty, not by page**. Two of the top three were caught by the completeness sweep, not the extractor. | | 2 Issue | Issued | Three responses received, **zero readable**. Sealed is a state on screen, not a claim in a deck. | | 3 Switch | Invitation wall | Nav swaps wholesale, `Acting as` changes, and the wall shows issuer / category / deadline and nothing else. | | 4 Bid | Bid workspace | Requirement-led. `R-B6C` reads **not evaluable**, never *failing*. | | 5 Vault | Eligibility | Expiry phrased as consequence — *"you drop out of three rosters"*. Pro locked and legible. | | 6 Open | Evaluation | The whole field opens **at once**. | | 7 Commit | Evaluation | Dashed proposals; the drawer carries evidence, anchor and provenance; your commit creates the score. | | 8 Amend | Evaluation | A substantive amendment **voids** what it touches. | ### The three that are only legible as behaviour The ticket named these specifically, and they are the reason this is clickable rather than a screenshot deck. **Sealed → open.** Step 2 shows an evaluation surface that exists and is *empty by construction* — not an empty state, a withheld one. Advancing the deadline fills it in one move. **Suggestion versus committed score.** Every scored cell starts dashed. Opening one gives the verbatim evidence span, the matched anchor with the full scale beside it, and the note that the criterion→requirement mapping was **authored, not extracted**. Committing turns the cell solid and moves the footer from `— · 0/10 committed` to a real number. **Gates have no drawer at all** — there is nothing to propose, because the model is barred from them. **The amendment.** Step 8 voids `GEO_PREF` across the live field, and its drawer explains that the previous commit is retained in the record but no longer counts. Scores are destroyed and re-earned, never silently recomputed. ### Neutrality, made visible rather than argued Because the venue carries the bidder-tools brand, these had to be mechanisms on screen: - the sealed field, and the deadline that opens it for everyone simultaneously - **`Commit scores`** as the loudest control on the evaluation surface — a human act, not a batch job - the gate band, computed and unproposable, sitting *above* everything the model touched - `indeterminate` marks that route to a person instead of resolving themselves None of that is a claim about intent. It is all observable in ten seconds of clicking. ### Two design bugs the build found Both were invisible on the static system page and appeared the moment real state moved. Recording them because they are **findings about the design**, not about the prototype: **Roll-up rows blended committed and proposed scores into one number.** `Method of Approach` read `23.75` while only one of its three children had been committed — a number that looks like a score, is presented like a score, and is mostly suggestion. This is the exact sin #15 exists to prevent, reproduced by an innocent-looking sum. **A roll-up must total committed children only**, and show its denominator: `9.00 · 1/3`, or `—` at zero. **Voiding did not propagate to the totals.** After the amendment, a voided cell rendered correctly as `voided` while its value quietly survived in the committed total and the `1/10` count. The amendment appeared to work and did not. Both are now fixed in the prototype, and both are **constraints on `<EvaluationMatrix>`**: totals and roll-ups must read through a single "is this an effective score" predicate, never off the raw commit map. Handed to whoever builds it for real. ### Verified, and not Walked end to end in a browser: all eight steps, the capability switch, the seal→open transition, a live commit with the footer updating, and the amendment voiding across two vendors. `node --check` clean. **Not verified:** it renders blank in an automated Chrome profile via the artifact viewer while rendering correctly when served directly — the same is true of #36's static page, which has no script at all, so this is the viewer in that profile rather than either file. Worth one manual check on the demo machine before the meeting rather than discovering it in the room. ### Scope, held No RLS, no scheduler, no extraction, no billing — all mocked, as the ticket specified. **This is throwaway** and is not the code layout, which remains the map's destination and lives in `src/`. The corpus numbers are real; the scores over them are authored for the demo, and the narratives they produce (cheapest bid disqualified; 82.15 against 81.90) come from the corpus ground truth. ### What the first real build will find that this cannot Column resize past ten vendors, virtualisation against a sticky footer, and how expand-in-place interacts with horizontal scroll. The 360/132/34px geometry from #36 survived three bidders and seventeen rows; it has not met two hundred.

christian closed this issue

2026-08-04 00:07:36 +00:00

christian referenced this issue

2026-08-04 02:29:28 +00:00

Define the v1 rate structure types #29

Sign in to join this conversation.