Proof Studio
Open a case, compare the cold and KBPD-backed output, inspect the evidence row, then read the limitation before you decide.
HERMES executive brief
The decision is not whether a demo sounds fluent. It is whether structured project knowledge changes the artifact in a way a buyer can inspect: one case, one contrast, one evidence row, one source trail, and one boundary.
A buyer should see decisions, source classes, limits, and next actions survive the jump from task prompt to finished artifact.
A case study earns attention when the reader can open the observation, value, source trail, and boundary without learning internal vocabulary.
Demo cases stay demos, pilot cases stay pilots, and the benchmark remains a null result until its run earns a number.
Demo
A design lead wants to see whether source-backed surfaces can change register without becoming a pile of one-off styles.
Persona council
A team is facing a hard product-planning decision and needs architecture, journey, verification, operations, and business judgment separated before synthesis.
Comparison
A team wants to know whether a new agent produces better work when it starts from the project system instead of a bare task prompt.
Openable proof
The strongest public proof is the system and specimen corpus: live surfaces, cold/backed pairs, measured artifact values, and clear claim boundaries. The harbor side-by-side fixture stays useful, but it is a supporting lab.
Start with the public switcher, then read the retained eight-adapter compositor boundary as the next publication target.
This is the better sales proof than one narrow app: visual hierarchy, composition, voice, grid, perception, product judgment, and typography.
Use this when you want a compact mechanical comparison. It is not the flagship proof surface; it is one bounded fixture inside the larger corpus.
Can the same brief become a clearer visual system when the run has a retained palette contract?
Near-value collisions: 441 -> 18 Lower is better: fewer color pairs collapse into the same visual weight.
One fixture about palette discipline. It does not prove conversion lift or brand preference.
Does the page create one deliberate reading path instead of evenly weighted blocks?
Dominant element ratio: 2.889 -> 6.905 Higher means the first visual decision is more decisive.
Composition metrics are proxy checks. They need reader testing before they become a performance claim.
Does the page move from outputs to testable product outcomes?
Outcome/output ratio: 0.08 -> 0.73 Higher means the artifact talks more about buyer outcomes than produced outputs.
The measured terms are text/artifact checks. They do not prove roadmap success in market.
Does retained type guidance make the page easier to read and maintain?
Hardcoded pixel font sizes: 11 -> 0 Lower means the type system is easier to scale and audit.
This is an artifact-quality check. It does not prove reader comprehension without a reader study.
Demo source map
The proof program is larger than one fixture. Start with the public surfaces below, then read the retained boundaries before treating any result as a broader claim.
Can one retained system produce several buyer-facing surfaces without becoming a one-off demo?
Can a reviewer inspect more than one polished example and compare the cold/backed outputs directly?
What changed when the same scenario was run cold and then with retained project context?
Can the buyer open two shipped outputs and see the working-record difference without trusting a summary?
Can a buyer inspect KBPD locally before a hosted service exists?
Can separated specialist passes produce a more reviewable decision than a single generic answer?
Is there more system depth behind the public specimen than the current page exposes?
What happens when structure, sequence, system, taste, copy, and verification all act on the same demo?
When does KBPD earn a numeric lift claim instead of a qualitative proof claim?
Case files
These files are the cold-reader path through Proof Studio: the buyer question, the observed fact, the evidence values, the source trail, the claim boundary, and the next action stay in one frame.
Comparison
Does the same work improve when the run starts with project memory?
comparison diagram
The agent received a competent task prompt but no project memory, decision trail, or reusable surface inventory.
The agent read the project state, decision records, and role guidance before producing the same class of artifact.
Run metadata lists five paired scenarios; the comparison matrix is retained as the public projection source.
Paired scenario review excerpt Five anonymized work scenarios were reviewed in paired form: one prompt-only run and one project-system-backed run for each scenario.
Treat the starter kit as worth testing when continuity, reusable structure, and limits matter more than generic polish.
Review the paired pilot rows before accepting any broader productivity claim.Surface trace
Can a public page trace to structured source instead of loose marketing copy?
process trace
A conventional page brief describes the message but does not bind sections, checks, or implementation decisions.
The route source names the audience, primary action, components, checks, and proof boundaries.
Run metadata and source artifacts name the structured route record, narrative record, code plan, and process trace.
Use KBPD when a product surface needs a visible line from source material to claim discipline.
Open the evidence room and compare the route source, public page, and claim boundary.Demo
Do specialist persona surfaces carry distinct capabilities instead of one generic answer?
process trace
A general assistant blends strategy, design, critique, and implementation into one plausible but hard-to-audit response.
Each role has a distinct job: decide, explain, verify, translate, remember, build, direct attention, or choreograph state changes.
Homepage persona cards and this proof case both name eight featured roles and one artifact sample per role.
Role gallery surface excerpt The public gallery presents eight launch-safe role samples and routes them into decision, copy, verification, and visual/motion surface types.
Use KBPD when prompts need named ownership, role-specific standards, and reusable review lanes.
Open the persona gallery evidence rows and inspect which corpus lane supports each claim.Persona council
Does retained corpus make a hard planning answer more inspectable than one blended response?
council fanout
A generic assistant can produce a plausible plan from the prompt alone, but the reasoning lanes, source assumptions, and evidence standards are fused together.
The same hard brief is routed through specialist lenses, prompt archive patterns, and retained project source before one synthesis is written.
Council fanout visual, transcript storyboard, and mechanism stage each show five named lanes converging only after lane outputs exist.
Five-lane council excerpt One complex brief is routed to architecture, journey, verification, operations, and business lanes before synthesis. Each lane has a distinct evidence job.
Use KBPD when a decision needs separate architecture, journey, verification, operations, and business lanes before synthesis.
Open the council evidence room and compare each lane to the final synthesis.Demo
Can one brand system survive multiple generated surface moods without losing inspection value?
system specimen
A page changes mood by introducing new color values, new spacing, and special-case component CSS.
The same component contract reads a different brand-source cluster. Structure holds while register changes.
Metric row names three theme registers; visual evidence shows three surfaces sharing one component structure.
Specimen gallery table excerpt Seven public rows expose cold and system-backed links for color, composition, voice, grid, perception, product decision, and typography specimens.
Use KBPD when design generation must preserve a system, not only produce attractive variants.
Open the specimen gallery and inspect the cold/backed pairs before reading the retained compositor summary.Measured pilot
Can demos, screenshots, and tests be held to one public review standard?
registry map
Each demo has its own layout, vocabulary, maturity level, and proof standard.
Every demo becomes a proof case with the same claim, use case, evidence, limitation, and CTA shape.
Proof Studio index renders eight cards; validator output reports eight proof cases passed validation and leak scan.
Trust the studio only when every public case uses the same claim, evidence, source, and limitation frame.
Use the full evidence view to compare case rows across proof families.Local MCP
Can a buyer inspect KBPD locally before hosted access exists?
evidence terminal
$ node mcp/local-server.mjs --self-test {"ok": true} $ node mcp/smoke.mjs tools/list + representative calls passed The buyer must trust a roadmap claim before they can inspect how project context becomes available to tools.
The extracted archive can answer health, search, context read, proof index, lint, and diagnostics calls from local files.
Metric row lists six local tools; source artifacts name the local MCP README, local server, smoke command, and manifest.
Local tool contract excerpt The local contract exposes six tools: health, search, context read, proof index, lint, and diagnostics.
Buy the starter kit when local inspection, offline read paths, and transparent tool boundaries are enough for first value.
Run the local MCP smoke and read the tool manifest from the extracted kit.Benchmark
What must be true before a broad benchmark claim ships?
benchmark gate
The tempting path is to publish a broad productivity number before the benchmark earns it.
The benchmark separates structured files from generic docs and prompt-only baselines before any public number ships.
Metric row says current public number is none; claim status is null result.
Treat this as a preregistered gate, not a purchase claim, until the benchmark clears.
Read the benchmark boundary and inspect which gates remain pending.Public proof actions
Proof Studio should not ask a reader to believe a list. Each path below opens a surface, jumps to a row, and exposes the values and source handles behind the claim.
System surface lab
This path starts with the public brand, motion, typography, and density switcher, then records the larger retained eight-kit compositor as the deeper proof program to publish next.
8 retained adapters / 596 generated stories
Open the same navigation, button, card, and status grammar under the day register.
Inspect motion rails and timing decisions without changing the component contract.
Compare value hierarchy and semantic color roles across the dawn register.
Review how surface, border, elevation, and interaction tokens hold the page together.
Brand, motion, typography, and density can be changed from the specimen drawer.
Four deep links open live kbpd.ai surfaces with different section and register choices.
PrimeReact, MUI, ShadCN, Radix, Ant Design, Chakra UI, Fluent UI v9, and Mantine adapters are present in the retained compositor source.
The retained Storybook compositor output contains 545 per-kit stories and 51 cross-kit comparison stories.
The public specimen shows warm, neutral, and cool surface registers while keeping the same component skeleton.
Demo gallery lab
This action opens the visual, voice, layout, product, and typography specimen surfaces as runnable cold/backed pairs with measured values in view.
7 microsites / 21 measured values
Lower is better: fewer color pairs collapse into the same visual weight.
One fixture about palette discipline. It does not prove conversion lift or brand preference.
Launch the paired microsites outside the frame when the surface needs closer review.
Higher means the first visual decision is more decisive.
Composition metrics are proxy checks. They need reader testing before they become a performance claim.
Launch the paired microsites outside the frame when the surface needs closer review.
The backed version says less while keeping the product surface intact.
This is a copy-quality specimen, not a statistically tested messaging study.
Launch the paired microsites outside the frame when the surface needs closer review.
Lower means less custom layout math to maintain.
The metric measures code structure in this output, not the long-term maintenance cost of a team.
Launch the paired microsites outside the frame when the surface needs closer review.
The backed surface uses spacing as an explicit perception tool.
This is a visual-perception fixture. It needs user observation before becoming a workflow-speed claim.
Launch the paired microsites outside the frame when the surface needs closer review.
Higher means the artifact talks more about buyer outcomes than produced outputs.
The measured terms are text/artifact checks. They do not prove roadmap success in market.
Launch the paired microsites outside the frame when the surface needs closer review.
Lower means the type system is easier to scale and audit.
This is an artifact-quality check. It does not prove reader comprehension without a reader study.
Launch the paired microsites outside the frame when the surface needs closer review.
The public registry currently contains eight proof cases spanning comparisons, demos, a case study, a surface trace, and a benchmark placeholder.
Paired pilot matrix
This action opens the calibration matrix behind the cold-start case: five cold runs beside five system-backed runs, with pass-rate signals and the scientific limit in view.
The system-backed output was shorter, source-bounded, and clearer about what context it did not need.
Both outputs found useful product shape; the system-backed run added decision boundaries and reversible tradeoffs.
The cold hollow-dependency failure is retained as a likely heuristic false positive; the system-backed run passed all three checks.
The system-backed output was more compact and deliberate about audience translation.
The system-backed output used a reusable doubt protocol and named tests that would change the verdict.
This is calibration evidence from one pilot run. The page keeps the caveat visible: no broad lift number until the preregistered benchmark clears its stronger bar.
Open the full pilot matrixThe pilot evidence set contains five anonymized tasks run once from a prompt-only starting point and once from a system-backed starting point.
Live side-by-side lab
This is a narrow fixture, not the flagship demo. Open the cold run and the project-memory-backed run in the same frame, then read the mechanical score matrix.
The public projection separates architecture, journey, verification, operations, and business lanes before the synthesized recommendation.
Before / after comparison
This action opens the paired-run case and jumps to the first evidence row instead of asking a buyer to trust the summary.
comparison diagram
Review the first evidence rows here, then open the case for the full value/source/limit table.
The pilot evidence set contains five anonymized tasks run once from a prompt-only starting point and once from a system-backed starting point.
The system-backed summaries include inherited decisions, named reusable assets, and explicit limitation language that the cold summaries did not consistently carry.
The public case labels the result as a measured pilot and explicitly avoids broad ROI or productivity lift claims.
The pilot evidence set contains five anonymized tasks run once from a prompt-only starting point and once from a system-backed starting point.
Specialist fanout
The case shows how separate specialist passes become a buyer-readable decision, with raw private screenshots withheld until sanitized.
council fanout
Review the first evidence rows here, then open the case for the full value/source/limit table.
The public projection separates architecture, journey, verification, operations, and business lanes before the synthesized recommendation.
The public persona page now shows five persona lenses as layered color-separation plates that converge into one resolved buyer artifact.
The public case describes the cold start as one recommendation where architecture, journey, verification, operations, and business judgments are fused together.
The public projection separates architecture, journey, verification, operations, and business lanes before the synthesized recommendation.
Local buyer inspection
This action goes to the local MCP proof surface: declared tools, proof-index access, zero hosted dependency for local inspection, and smoke paths.
evidence terminal
$ node mcp/local-server.mjs --self-test {"ok": true} $ node mcp/smoke.mjs tools/list + representative calls passed Review the first evidence rows here, then open the case for the full value/source/limit table.
The starter kit local MCP contract exposes health, search, context read, proof index, lint, and diagnostics tools.
The local inspection path reads extracted starter-kit files and does not require hosted authentication.
The proof case records two smoke paths: extracted-package Node smoke and Docker image smoke.
The starter kit local MCP contract exposes health, search, context read, proof index, lint, and diagnostics tools.
Audit mode
When the buyer wants the full register, this leaves the marketing path and opens the evidence desk with rows, values, source trail, and limits.
registry map
Review the first evidence rows here, then open the case for the full value/source/limit table.
The public registry currently contains eight proof cases spanning comparisons, demos, a case study, a surface trace, and a benchmark placeholder.
The proof-case validator rejects entries without claim status, limitations, visuals, metrics, source artifacts, and evidence facts.
The current registry is intentionally curated and raw experiment assets still require redaction before publication.
The public registry currently contains eight proof cases spanning comparisons, demos, a case study, a surface trace, and a benchmark placeholder.
Cold reviewer start
Start with a single claim, inspect the row behind it, then decide whether the public boundary is strong enough for the purchase decision in front of you.
Evidence workbench
Pick a case study, read the public observation, inspect the values and source trail, then open the detail page for the full review. The export stays available, but the evidence has to make sense on the page first.
Selected case study
System-backed runs preserve prior decisions, reuse existing structures, and surface clearer next actions than cold runs on the same scenario set.
A team wants to know whether a new agent produces better work when it starts from the project system instead of a bare task prompt.
Cold run vs. System-backed run
The pilot evidence set contains five anonymized tasks run once from a prompt-only starting point and once from a system-backed starting point.
Small sample size.
The pilot evidence set contains five anonymized tasks run once from a prompt-only starting point and once from a system-backed starting point.
Run metadata lists five paired scenarios; the comparison matrix is retained as the public projection source.
Each row states what was observed, which values support it, where the source trail points, and where the claim stops.
evidence_facts[0] The pilot evidence set contains five anonymized tasks run once from a prompt-only starting point and once from a system-backed starting point.
evidence_facts[1] The system-backed summaries include inherited decisions, named reusable assets, and explicit limitation language that the cold summaries did not consistently carry.
evidence_facts[2] The public case labels the result as a measured pilot and explicitly avoids broad ROI or productivity lift claims.
These are the metric and run fields used by the rows above. The label and value carry the story; audit handles stay visible without becoming the main interface.
data-01-scenario-set 5
Five anonymized work scenarios were compared as cold and system-backed runs.data-02-primary-signal reuse
Cases were reviewed for inherited decisions, named reusable assets, and explicit limitations.data-03-claim-boundary pilot
Good enough to inspect; not a broad numeric ROI claim.data-04-run-date June 2026
Date label attached to this public proof case.data-05-sample Five paired scenarios
Sample size or unit under review.data-06-provenance Public projection of internal comparison runs
Where the public projection says the evidence came from.data-07-reproducibility Representative excerpts are public; raw transcripts remain internal until fully redacted.
What a reviewer can repeat or inspect publicly.data-08-claim-status measured pilot
The maximum strength of the public claim.First evidence value: Scenario set (data-01-scenario-set) Selected case study
The demonstration page is itself a rendered proof: its sections, route intent, checks, and implementation plan were specified before code.
A buyer wants to see whether KBPD can make a product surface trace back to structured source material instead of a hand-built page.
Ordinary page brief vs. Structured surface source
The page is backed by route, process, narrative, and code-emission records rather than a standalone marketing brief.
This is one route, not the whole product.
The page is backed by route, process, narrative, and code-emission records rather than a standalone marketing brief.
Run metadata and source artifacts name the structured route record, narrative record, code plan, and process trace.
Each row states what was observed, which values support it, where the source trail points, and where the claim stops.
evidence_facts[0] The page is backed by route, process, narrative, and code-emission records rather than a standalone marketing brief.
evidence_facts[1] The demonstration exists as an inspectable public route and is included in the static site build.
evidence_facts[2] The page avoids a numeric improvement claim until the controlled comparison clears its gates.
These are the metric and run fields used by the rows above. The label and value carry the story; audit handles stay visible without becoming the main interface.
data-01-source-families 4
Route, process, narrative, and code-emission records inform the page.data-02-primary-gate claim discipline
The page explicitly avoids a numeric improvement claim until the benchmark runs.data-03-run-date Launch build
Date label attached to this public proof case.data-04-sample One production route
Sample size or unit under review.data-05-provenance Sanitized route-source projection
Where the public projection says the evidence came from.data-06-reproducibility The public page includes the rendered trace; source excerpts are summarized.
What a reviewer can repeat or inspect publicly.data-07-claim-status qualitative proof
The maximum strength of the public claim.First evidence value: Source families (data-01-source-families) Selected case study
Different specialist lenses produce visibly different artifacts from the same project source: architecture decisions, buyer-facing copy, cold-audience review, adversarial verification, art direction, and motion grammar.
A team wants to understand why KBPD uses specialist roles instead of one generic assistant voice.
One generic assistant vs. Role-specific outputs
The public role gallery exposes eight launch-safe roles with a role caption, capability statement, and concrete output sample.
Samples are static in the first launch.
The public role gallery exposes eight launch-safe roles with a role caption, capability statement, and concrete output sample.
Homepage persona cards and this proof case both name eight featured roles and one artifact sample per role.
Each row states what was observed, which values support it, where the source trail points, and where the claim stops.
evidence_facts[0] The public role gallery exposes eight launch-safe roles with a role caption, capability statement, and concrete output sample.
evidence_facts[1] The gallery covers decision, copy, verification, and visual/motion surfaces rather than only persona descriptions.
evidence_facts[2] The public case states that static samples ship first and interactive role calls are reserved for the hosted-service phase.
These are the metric and run fields used by the rows above. The label and value carry the story; audit handles stay visible without becoming the main interface.
data-01-featured-roles 8
The public page shows eight launch-safe examples with one artifact sample each.data-02-surface-types 4
Decision, copy, verification, and visual/motion surfaces are represented.data-03-claim-boundary demo
This is a capability demonstration, not a measured quality comparison.data-04-run-date Launch build
Date label attached to this public proof case.data-05-sample Eight role samples
Sample size or unit under review.data-06-provenance Public-safe projection of the role roster
Where the public projection says the evidence came from.data-07-reproducibility Static samples are inspectable on the homepage.
What a reviewer can repeat or inspect publicly.data-08-claim-status demonstrator
The maximum strength of the public claim.First evidence value: Featured roles (data-01-featured-roles) Selected case study
Role-specific context and a retained prompt corpus produce more inspectable work than a single generic assistant because each lane has a different evidence job before synthesis.
A team is facing a hard product-planning decision and needs architecture, journey, verification, operations, and business judgment separated before synthesis.
Single assistant response vs. Council fanout
The public projection separates architecture, journey, verification, operations, and business lanes before the synthesized recommendation.
This is one sanitized run, not a statistical benchmark.
The public projection separates architecture, journey, verification, operations, and business lanes before the synthesized recommendation.
Council fanout visual, transcript storyboard, and mechanism stage each show five named lanes converging only after lane outputs exist.
Each row states what was observed, which values support it, where the source trail points, and where the claim stops.
evidence_facts[0] The public projection separates architecture, journey, verification, operations, and business lanes before the synthesized recommendation.
source-01-council-projection Council projection source-06-t3-proof-row-table T3 proof-row table source-07-cold-baseline-review-board Cold baseline review board source-08-sanitized-run-gallery Sanitized run gallery source-09-capture-review-board Capture review board source-10-color-separation-lane-board Color-separation lane board evidence_facts[1] The public persona page now shows five persona lenses as layered color-separation plates that converge into one resolved buyer artifact.
source-03-persona-roster Persona roster source-04-prompt-archive Prompt archive source-05-prompt-archive-patterns Prompt archive patterns source-06-t3-proof-row-table T3 proof-row table source-07-cold-baseline-review-board Cold baseline review board source-09-capture-review-board Capture review board source-10-color-separation-lane-board Color-separation lane board evidence_facts[2] The public case describes the cold start as one recommendation where architecture, journey, verification, operations, and business judgments are fused together.
source-01-council-projection Council projection source-02-raw-run-captures Raw run captures source-04-prompt-archive Prompt archive source-05-prompt-archive-patterns Prompt archive patterns source-06-t3-proof-row-table T3 proof-row table source-07-cold-baseline-review-board Cold baseline review board source-09-capture-review-board Capture review board source-10-color-separation-lane-board Color-separation lane board evidence_facts[3] The public persona page shows a five-row T3 table before asking the reader to accept the broader claim.
source-03-persona-roster Persona roster source-04-prompt-archive Prompt archive source-05-prompt-archive-patterns Prompt archive patterns source-06-t3-proof-row-table T3 proof-row table source-07-cold-baseline-review-board Cold baseline review board source-09-capture-review-board Capture review board source-10-color-separation-lane-board Color-separation lane board evidence_facts[4] The public persona page now shows the cold artifact beside the KBPD-backed artifact and lists five baseline checks before the T3 table.
source-02-raw-run-captures Raw run captures source-03-persona-roster Persona roster source-04-prompt-archive Prompt archive source-05-prompt-archive-patterns Prompt archive patterns source-06-t3-proof-row-table T3 proof-row table source-07-cold-baseline-review-board Cold baseline review board source-09-capture-review-board Capture review board source-10-color-separation-lane-board Color-separation lane board evidence_facts[5] The proof case publishes redrawn mechanisms and explicitly reports zero public source screenshots.
source-01-council-projection Council projection source-02-raw-run-captures Raw run captures source-04-prompt-archive Prompt archive source-05-prompt-archive-patterns Prompt archive patterns source-06-t3-proof-row-table T3 proof-row table source-08-sanitized-run-gallery Sanitized run gallery source-09-capture-review-board Capture review board source-10-color-separation-lane-board Color-separation lane board evidence_facts[6] The public persona page now redraws the retained run as five frames: brief, corpus, lanes, synthesis, and buyer proof path.
source-01-council-projection Council projection source-02-raw-run-captures Raw run captures source-03-persona-roster Persona roster source-04-prompt-archive Prompt archive source-05-prompt-archive-patterns Prompt archive patterns source-06-t3-proof-row-table T3 proof-row table source-07-cold-baseline-review-board Cold baseline review board source-08-sanitized-run-gallery Sanitized run gallery source-09-capture-review-board Capture review board source-10-color-separation-lane-board Color-separation lane board evidence_facts[7] The public persona page shows five capture-review rows that connect retained screenshot classes to public frames, redaction boundaries, and exact evidence-row links.
source-02-raw-run-captures Raw run captures source-03-persona-roster Persona roster source-06-t3-proof-row-table T3 proof-row table source-07-cold-baseline-review-board Cold baseline review board source-09-capture-review-board Capture review board source-10-color-separation-lane-board Color-separation lane board evidence_facts[8] The public mechanism shows role roster, prompt archive patterns, prior decisions, and project source as inputs to the run.
evidence_facts[9] The public case names the public-language lane and the cold-reader gate as corpus owners before the result becomes buyer-facing copy.
source-04-prompt-archive Prompt archive source-05-prompt-archive-patterns Prompt archive patterns source-06-t3-proof-row-table T3 proof-row table source-07-cold-baseline-review-board Cold baseline review board source-09-capture-review-board Capture review board source-10-color-separation-lane-board Color-separation lane board These are the metric and run fields used by the rows above. The label and value carry the story; audit handles stay visible without becoming the main interface.
data-01-specialist-lanes 5
Architecture, journey, verification, operations, and business lenses are shown separately.data-02-public-source-screenshots 0
The public case is redrawn from sanitized structure; private screenshots remain internal.data-03-corpus-sources 4
Role roster, prompt archive, prior decisions, and project source are represented in the public mechanism.data-04-claim-boundary demo
This proves the pattern is inspectable, not that it wins every planning task.data-05-t3-proof-rows 5
Five public rows connect cold baseline, specialist lane, evidence signal, source class, and buyer decision.data-06-baseline-checks 5
Five public checks make the cold-start artifact reviewable before the reader reaches the T3 table.data-07-public-run-projections 5
Five redrawn gallery frames show the retained run structure without publishing raw screenshots.data-08-capture-review-rows 5
Five publication-safe rows map private capture classes to public frames, redaction boundaries, and evidence links.data-09-color-separated-lenses 5
Five persona lanes now render as layered color-separation plates before the longer mechanism and transcript surfaces.data-10-run-date June 2026
Date label attached to this public proof case.data-11-sample One sanitized council run
Sample size or unit under review.data-12-provenance Public projection of a retained multi-lane planning run
Where the public projection says the evidence came from.data-13-reproducibility The public projection is reproducible as a proof pattern; the retained source requires redaction before publication.
What a reviewer can repeat or inspect publicly.data-14-claim-status demonstrator
The maximum strength of the public claim.First evidence value: Specialist lanes (data-01-specialist-lanes) Selected case study
A single brand-source system can render different surface moods while preserving component structure, spacing rhythm, and motion rules.
A design lead wants to see whether source-backed surfaces can change register without becoming a pile of one-off styles.
Hand-themed surface vs. Source-bound surface
The public specimen shows warm, neutral, and cool surface registers while keeping the same component skeleton.
This proves visual system survival, not buyer conversion.
The public specimen shows warm, neutral, and cool surface registers while keeping the same component skeleton.
Metric row names three theme registers; visual evidence shows three surfaces sharing one component structure.
Each row states what was observed, which values support it, where the source trail points, and where the claim stops.
evidence_facts[0] The public specimen shows warm, neutral, and cool surface registers while keeping the same component skeleton.
source-02-specimen-page Specimen page source-03-motion-rules Motion rules source-04-specimen-gallery-lab Specimen gallery lab source-05-color-specimen-pair Color specimen pair source-06-product-decision-specimen-pair Product-decision specimen pair source-07-typography-specimen-pair Typography specimen pair evidence_facts[1] The case identifies generated design variables, the public specimen route, and motion rules as source artifacts.
source-01-design-outputs Design outputs source-02-specimen-page Specimen page source-03-motion-rules Motion rules source-04-specimen-gallery-lab Specimen gallery lab source-05-color-specimen-pair Color specimen pair source-06-product-decision-specimen-pair Product-decision specimen pair source-07-typography-specimen-pair Typography specimen pair source-08-retained-compositor-inventory Retained compositor inventory evidence_facts[2] The proof does not claim every visual register is automatically ready for every accessibility context.
evidence_facts[3] The brand-system case links seven public specimen pairs across color, composition, voice, grid, perception, product decision, and typography surfaces.
evidence_facts[4] Each public specimen lists one primary value and two secondary values, for twenty-one visible measured values across the gallery.
evidence_facts[5] The color specimen reports near-value collisions moving from 441 in the cold output to 18 in the system-backed output.
evidence_facts[6] The product-decision specimen reports outcome/output ratio moving from 0.08 in the cold output to 0.73 in the system-backed output.
evidence_facts[7] The typography specimen reports hardcoded pixel font sizes moving from 11 in the cold output to 0 in the system-backed output.
evidence_facts[8] The public case records eight retained UI-kit adapters and 596 retained generated stories as the next publication boundary.
source-01-design-outputs Design outputs source-02-specimen-page Specimen page source-03-motion-rules Motion rules source-04-specimen-gallery-lab Specimen gallery lab source-05-color-specimen-pair Color specimen pair source-06-product-decision-specimen-pair Product-decision specimen pair source-07-typography-specimen-pair Typography specimen pair source-08-retained-compositor-inventory Retained compositor inventory These are the metric and run fields used by the rows above. The label and value carry the story; audit handles stay visible without becoming the main interface.
data-01-theme-registers 3
Warm, neutral, and cool registers are generated from the same brand source.data-02-primary-signal survival
The component contract survives a register change.data-03-specimen-microsites 7
Seven public cold/backed surface pairs are openable from the proof case and gallery.data-04-measured-specimen-values 21
Each public specimen carries one primary value and two secondary values.data-05-cold-backed-outputs 14
Seven cold outputs and seven system-backed outputs are published as runnable microsites.data-06-near-value-collisions 441 -> 18
The color specimen reduces near-value collisions in the system-backed output.data-07-outcome-output-ratio 0.08 -> 0.73
The product-decision specimen shifts the artifact toward buyer outcomes.data-08-hardcoded-pixel-type-sizes 11 -> 0
The typography specimen removes ad hoc pixel font sizes from the backed output.data-09-retained-compositor-stories 596
The deeper retained compositor inventory remains queued for publication hygiene.data-10-retained-ui-kit-adapters 8
The retained compositor inventory covers eight component ecosystems.data-11-run-date Launch build
Date label attached to this public proof case.data-12-sample Seven public specimen pairs plus retained compositor inventory
Sample size or unit under review.data-13-provenance Generated design outputs, public specimen page, and public specimen gallery
Where the public projection says the evidence came from.data-14-reproducibility Visitors can inspect the specimen page, open the seven public cold/backed microsites, and use the retained counts as a publication boundary.
What a reviewer can repeat or inspect publicly.data-15-claim-status demonstrator
The maximum strength of the public claim.First evidence value: Theme registers (data-01-theme-registers) Selected case study
A consistent review frame makes accumulated tests legible: every demo carries the same claim, evidence, limitation, and next-action fields.
A team has many experiments and needs a shared way to compare them without turning the site into a folder of disconnected artifacts.
Loose demo pile vs. Proof case frame
The public registry currently contains eight proof cases spanning comparisons, demos, a case study, a surface trace, and a benchmark placeholder.
The first registry is curated, not automatically generated.
The public registry currently contains eight proof cases spanning comparisons, demos, a case study, a surface trace, and a benchmark placeholder.
Proof Studio index renders eight cards; validator output reports eight proof cases passed validation and leak scan.
Each row states what was observed, which values support it, where the source trail points, and where the claim stops.
evidence_facts[0] The public registry currently contains eight proof cases spanning comparisons, demos, a case study, a surface trace, and a benchmark placeholder.
evidence_facts[1] The proof-case validator rejects entries without claim status, limitations, visuals, metrics, source artifacts, and evidence facts.
evidence_facts[2] The current registry is intentionally curated and raw experiment assets still require redaction before publication.
These are the metric and run fields used by the rows above. The label and value carry the story; audit handles stay visible without becoming the main interface.
data-01-proof-families 8
The launch registry covers comparisons, local demos, surface traces, cases, and benchmark placeholders.data-02-required-labels 100%
Every public case has a claim status and limitation list.data-03-run-date Launch build
Date label attached to this public proof case.data-04-sample Eight proof families
Sample size or unit under review.data-05-provenance Sanitized public registry
Where the public projection says the evidence came from.data-06-reproducibility The registry is validated at build time.
What a reviewer can repeat or inspect publicly.data-07-claim-status measured pilot
The maximum strength of the public claim.First evidence value: Proof families (data-01-proof-families) Selected case study
The starter kit includes an offline-first MCP server with health, search, context read, proof index, lint, and diagnostics tools.
A buyer wants to know whether the starter kit can be inspected without waiting for a hosted account.
Hosted-only promise vs. Local server in the kit
The starter kit local MCP contract exposes health, search, context read, proof index, lint, and diagnostics tools.
The local server works against extracted kit files only.
The starter kit local MCP contract exposes health, search, context read, proof index, lint, and diagnostics tools.
Metric row lists six local tools; source artifacts name the local MCP README, local server, smoke command, and manifest.
Each row states what was observed, which values support it, where the source trail points, and where the claim stops.
evidence_facts[0] The starter kit local MCP contract exposes health, search, context read, proof index, lint, and diagnostics tools.
evidence_facts[1] The local inspection path reads extracted starter-kit files and does not require hosted authentication.
evidence_facts[2] The proof case records two smoke paths: extracted-package Node smoke and Docker image smoke.
These are the metric and run fields used by the rows above. The label and value carry the story; audit handles stay visible without becoming the main interface.
data-01-local-tools 6
Health, search, context read, proof index, lint, and diagnostics are exposed through the local server.data-02-hosted-dependency 0
The local inspection path reads extracted kit files without a hosted account.data-03-smoke-path 2
Extracted-archive Node smoke and Docker image smoke cover startup plus representative tool calls.data-04-run-date Launch build
Date label attached to this public proof case.data-05-sample One assembled archive and one Docker MCP image
Sample size or unit under review.data-06-provenance Starter-kit MCP README, manifest, local server source, archive assembler, and smoke command
Where the public projection says the evidence came from.data-07-reproducibility Build the starter-kit archive, extract it, run node mcp/smoke.mjs, or run the Docker MCP image smoke.
What a reviewer can repeat or inspect publicly.data-08-claim-status qualitative proof
The maximum strength of the public claim.First evidence value: Local tools (data-01-local-tools) Selected case study
No numeric lift claim is public until the preregistered benchmark runs and clears its validity gates.
A technical evaluator wants a controlled, reproducible answer to whether structured project context improves agent work.
Premature claim vs. Gated benchmark
The benchmark case publishes no numeric lift result and labels the current result as null.
No benchmark result exists on the public site yet.
The benchmark case publishes no numeric lift result and labels the current result as null.
Metric row says current public number is none; claim status is null result.
Each row states what was observed, which values support it, where the source trail points, and where the claim stops.
evidence_facts[0] The benchmark case publishes no numeric lift result and labels the current result as null.
evidence_facts[1] The planned benchmark compares project system, generic docs, and competent prompt-only baseline arms.
evidence_facts[2] The source artifact list marks run artifacts as pending, and the limitations state no public benchmark result exists yet.
These are the metric and run fields used by the rows above. The label and value carry the story; audit handles stay visible without becoming the main interface.
data-01-current-public-number none
The site does not claim a measured productivity lift yet.data-02-planned-arms 3
Project system, generic docs, and competent prompt-only baseline.data-03-run-date Pending
Date label attached to this public proof case.data-04-sample Not run publicly
Sample size or unit under review.data-05-provenance Benchmark design summary
Where the public projection says the evidence came from.data-06-reproducibility The public harness becomes the source once the run clears gates.
What a reviewer can repeat or inspect publicly.data-07-claim-status null result
The maximum strength of the public claim.First evidence value: Current public number (data-01-current-public-number) Case quality review
The evaluator checks whether a cold buyer can understand the case, open the evidence, see the limit, follow the visual hierarchy, and know the next purchase or inspection action.
A reviewer gets the situation, contrast, and buyer decision without reading the JSON.
The case exposes proof rows, values, source handles, and excerpts before the JSON export.
The page names what the case proves and what it does not prove.
The route uses visuals, storyboards, or surface frames to break the proof into inspectable layers.
The proof sends the buyer to an evidence room, artifact link, pricing path, or local run.
Visual hierarchy: Promote the proof row into a diagram, table, screenshot projection, or openable artifact.
Open evidence deskEvidence inspector
Start here if you are evaluating KBPD in detail. Every case below exposes the observation, supporting value, source trail, limitation, case room, and JSON export. Use the evidence table above when you want to compare values without leaving the page.
3 rows / 8 values System-backed runs preserve prior decisions, reuse existing structures, and surface clearer next actions than cold runs on the same scenario set.
evidence_facts[0] Public projection evidence_facts[1] Public projection evidence_facts[2] Publicly inspectable 3 rows / 7 values The demonstration page is itself a rendered proof: its sections, route intent, checks, and implementation plan were specified before code.
evidence_facts[0] Public projection evidence_facts[1] Publicly inspectable evidence_facts[2] Publicly inspectable 3 rows / 8 values Different specialist lenses produce visibly different artifacts from the same project source: architecture decisions, buyer-facing copy, cold-audience review, adversarial verification, art direction, and motion grammar.
evidence_facts[0] Publicly inspectable evidence_facts[1] Publicly inspectable evidence_facts[2] Publicly inspectable 10 rows / 14 values Role-specific context and a retained prompt corpus produce more inspectable work than a single generic assistant because each lane has a different evidence job before synthesis.
evidence_facts[0] Publicly inspectable source-01-council-projection Council projection sanitized diagram / public projection source-06-t3-proof-row-table T3 proof-row table sanitized review table / public projection source-07-cold-baseline-review-board Cold baseline review board sanitized review table / public projection source-08-sanitized-run-gallery Sanitized run gallery redrawn run projection / public projection source-09-capture-review-board Capture review board redacted capture map / public projection source-10-color-separation-lane-board Color-separation lane board sanitized visual proof surface / public projection evidence_facts[1] Publicly inspectable source-03-persona-roster Persona roster role registry / internal source retained source-04-prompt-archive Prompt archive corpus source / internal source retained source-05-prompt-archive-patterns Prompt archive patterns corpus source / internal source retained source-06-t3-proof-row-table T3 proof-row table sanitized review table / public projection source-07-cold-baseline-review-board Cold baseline review board sanitized review table / public projection source-09-capture-review-board Capture review board redacted capture map / public projection source-10-color-separation-lane-board Color-separation lane board sanitized visual proof surface / public projection evidence_facts[2] Publicly inspectable source-01-council-projection Council projection sanitized diagram / public projection source-02-raw-run-captures Raw run captures internal evidence / internal source retained source-04-prompt-archive Prompt archive corpus source / internal source retained source-05-prompt-archive-patterns Prompt archive patterns corpus source / internal source retained source-06-t3-proof-row-table T3 proof-row table sanitized review table / public projection source-07-cold-baseline-review-board Cold baseline review board sanitized review table / public projection source-09-capture-review-board Capture review board redacted capture map / public projection source-10-color-separation-lane-board Color-separation lane board sanitized visual proof surface / public projection evidence_facts[3] Publicly inspectable source-03-persona-roster Persona roster role registry / internal source retained source-04-prompt-archive Prompt archive corpus source / internal source retained source-05-prompt-archive-patterns Prompt archive patterns corpus source / internal source retained source-06-t3-proof-row-table T3 proof-row table sanitized review table / public projection source-07-cold-baseline-review-board Cold baseline review board sanitized review table / public projection source-09-capture-review-board Capture review board redacted capture map / public projection source-10-color-separation-lane-board Color-separation lane board sanitized visual proof surface / public projection evidence_facts[4] Publicly inspectable source-02-raw-run-captures Raw run captures internal evidence / internal source retained source-03-persona-roster Persona roster role registry / internal source retained source-04-prompt-archive Prompt archive corpus source / internal source retained source-05-prompt-archive-patterns Prompt archive patterns corpus source / internal source retained source-06-t3-proof-row-table T3 proof-row table sanitized review table / public projection source-07-cold-baseline-review-board Cold baseline review board sanitized review table / public projection source-09-capture-review-board Capture review board redacted capture map / public projection source-10-color-separation-lane-board Color-separation lane board sanitized visual proof surface / public projection evidence_facts[5] Publicly inspectable source-01-council-projection Council projection sanitized diagram / public projection source-02-raw-run-captures Raw run captures internal evidence / internal source retained source-04-prompt-archive Prompt archive corpus source / internal source retained source-05-prompt-archive-patterns Prompt archive patterns corpus source / internal source retained source-06-t3-proof-row-table T3 proof-row table sanitized review table / public projection source-08-sanitized-run-gallery Sanitized run gallery redrawn run projection / public projection source-09-capture-review-board Capture review board redacted capture map / public projection source-10-color-separation-lane-board Color-separation lane board sanitized visual proof surface / public projection evidence_facts[6] Publicly inspectable source-01-council-projection Council projection sanitized diagram / public projection source-02-raw-run-captures Raw run captures internal evidence / internal source retained source-03-persona-roster Persona roster role registry / internal source retained source-04-prompt-archive Prompt archive corpus source / internal source retained source-05-prompt-archive-patterns Prompt archive patterns corpus source / internal source retained source-06-t3-proof-row-table T3 proof-row table sanitized review table / public projection source-07-cold-baseline-review-board Cold baseline review board sanitized review table / public projection source-08-sanitized-run-gallery Sanitized run gallery redrawn run projection / public projection source-09-capture-review-board Capture review board redacted capture map / public projection source-10-color-separation-lane-board Color-separation lane board sanitized visual proof surface / public projection evidence_facts[7] Publicly inspectable source-02-raw-run-captures Raw run captures internal evidence / internal source retained source-03-persona-roster Persona roster role registry / internal source retained source-06-t3-proof-row-table T3 proof-row table sanitized review table / public projection source-07-cold-baseline-review-board Cold baseline review board sanitized review table / public projection source-09-capture-review-board Capture review board redacted capture map / public projection source-10-color-separation-lane-board Color-separation lane board sanitized visual proof surface / public projection evidence_facts[8] Publicly inspectable evidence_facts[9] Publicly inspectable source-04-prompt-archive Prompt archive corpus source / internal source retained source-05-prompt-archive-patterns Prompt archive patterns corpus source / internal source retained source-06-t3-proof-row-table T3 proof-row table sanitized review table / public projection source-07-cold-baseline-review-board Cold baseline review board sanitized review table / public projection source-09-capture-review-board Capture review board redacted capture map / public projection source-10-color-separation-lane-board Color-separation lane board sanitized visual proof surface / public projection 9 rows / 15 values A single brand-source system can render different surface moods while preserving component structure, spacing rhythm, and motion rules.
evidence_facts[0] Publicly inspectable source-02-specimen-page Specimen page public route / public projection source-03-motion-rules Motion rules component runtime / public projection source-04-specimen-gallery-lab Specimen gallery lab public route / public projection source-05-color-specimen-pair Color specimen pair public microsite pair / public projection source-06-product-decision-specimen-pair Product-decision specimen pair public microsite pair / public projection source-07-typography-specimen-pair Typography specimen pair public microsite pair / public projection evidence_facts[1] Public projection source-01-design-outputs Design outputs generated design variables / public projection source-02-specimen-page Specimen page public route / public projection source-03-motion-rules Motion rules component runtime / public projection source-04-specimen-gallery-lab Specimen gallery lab public route / public projection source-05-color-specimen-pair Color specimen pair public microsite pair / public projection source-06-product-decision-specimen-pair Product-decision specimen pair public microsite pair / public projection source-07-typography-specimen-pair Typography specimen pair public microsite pair / public projection source-08-retained-compositor-inventory Retained compositor inventory retained runtime inventory / internal source retained evidence_facts[2] Publicly inspectable evidence_facts[3] Publicly inspectable source-02-specimen-page Specimen page public route / public projection source-04-specimen-gallery-lab Specimen gallery lab public route / public projection source-05-color-specimen-pair Color specimen pair public microsite pair / public projection source-06-product-decision-specimen-pair Product-decision specimen pair public microsite pair / public projection source-07-typography-specimen-pair Typography specimen pair public microsite pair / public projection evidence_facts[4] Publicly inspectable source-02-specimen-page Specimen page public route / public projection source-04-specimen-gallery-lab Specimen gallery lab public route / public projection source-05-color-specimen-pair Color specimen pair public microsite pair / public projection source-06-product-decision-specimen-pair Product-decision specimen pair public microsite pair / public projection source-07-typography-specimen-pair Typography specimen pair public microsite pair / public projection evidence_facts[5] Publicly inspectable source-02-specimen-page Specimen page public route / public projection source-04-specimen-gallery-lab Specimen gallery lab public route / public projection source-05-color-specimen-pair Color specimen pair public microsite pair / public projection source-06-product-decision-specimen-pair Product-decision specimen pair public microsite pair / public projection source-07-typography-specimen-pair Typography specimen pair public microsite pair / public projection evidence_facts[6] Publicly inspectable source-02-specimen-page Specimen page public route / public projection source-04-specimen-gallery-lab Specimen gallery lab public route / public projection source-05-color-specimen-pair Color specimen pair public microsite pair / public projection source-06-product-decision-specimen-pair Product-decision specimen pair public microsite pair / public projection source-07-typography-specimen-pair Typography specimen pair public microsite pair / public projection evidence_facts[7] Publicly inspectable source-02-specimen-page Specimen page public route / public projection source-04-specimen-gallery-lab Specimen gallery lab public route / public projection source-05-color-specimen-pair Color specimen pair public microsite pair / public projection source-06-product-decision-specimen-pair Product-decision specimen pair public microsite pair / public projection source-07-typography-specimen-pair Typography specimen pair public microsite pair / public projection evidence_facts[8] Internal retained source-01-design-outputs Design outputs generated design variables / public projection source-02-specimen-page Specimen page public route / public projection source-03-motion-rules Motion rules component runtime / public projection source-04-specimen-gallery-lab Specimen gallery lab public route / public projection source-05-color-specimen-pair Color specimen pair public microsite pair / public projection source-06-product-decision-specimen-pair Product-decision specimen pair public microsite pair / public projection source-07-typography-specimen-pair Typography specimen pair public microsite pair / public projection source-08-retained-compositor-inventory Retained compositor inventory retained runtime inventory / internal source retained 3 rows / 7 values A consistent review frame makes accumulated tests legible: every demo carries the same claim, evidence, limitation, and next-action fields.
evidence_facts[0] Validated by build evidence_facts[1] Validated by build evidence_facts[2] Publicly inspectable 3 rows / 8 values The starter kit includes an offline-first MCP server with health, search, context read, proof index, lint, and diagnostics tools.
evidence_facts[0] Validated by build source-01-local-mcp-readme Local MCP README starter-kit docs / public projection source-02-mcp-manifest MCP manifest machine-readable contract / public projection source-03-local-server Local server starter-kit runtime / public projection source-04-smoke-command Smoke command verification script / public projection evidence_facts[1] Publicly inspectable evidence_facts[2] Validated by build 3 rows / 7 values No numeric lift claim is public until the preregistered benchmark runs and clears its validity gates.
evidence_facts[0] Publicly inspectable evidence_facts[1] Public projection evidence_facts[2] Pending Evidence Strip
Start with the comparison, inspect the specialist council, verify local execution, then review the accumulated proof frame before buying the starter kit.
comparison diagram
council fanout
evidence terminal
$ node mcp/local-server.mjs --self-test {"ok": true} $ node mcp/smoke.mjs tools/list + representative calls passed registry map
Evidence route board
This board is not another proof claim. It is the operating boundary for the studio: private captures stay private, public cases show sanitized evidence, build checks keep claims bounded, and external payment/email gates still decide whether the launch is complete.
Screenshots, transcripts, test notes, and run outputs remain internal until they can be redrawn without private names, paths, or operational details.
The studio converts promising work into a readable case: situation, claim, contrast, visual evidence, evidence values, limitations, and next action.
Schema validation, leak scanning, public route smoke, starter-kit checks, and local MCP tests keep the public site from drifting into unreviewed claims.
The proof pages, working draft, pricing boundary, account page, and local MCP route all point to the starter kit as the launchable offer.
The site can pass its own checks while DNS, human inbox download, and live order/return proof remain outside the repo and must close before launch-ready is true.
Evidence table
Every public claim below has an observation, a supporting value, a source trail, and a stated boundary. The JSON export is available, but the evidence should be understandable before a reviewer opens it.
Visible evidence cards
Each card pairs one public observation with the evidence values, source trail, and limitation that bound the claim. The IDs remain visible for audit, but the reviewer should not need JSON to understand what is being asserted. This index shows the first three cards; the full evidence view keeps the complete table open for deep audit.
The pilot evidence set contains five anonymized tasks run once from a prompt-only starting point and once from a system-backed starting point.
Small sample size.
The system-backed summaries include inherited decisions, named reusable assets, and explicit limitation language that the cold summaries did not consistently carry.
Anonymized scenarios only.
The public case labels the result as a measured pilot and explicitly avoids broad ROI or productivity lift claims.
The result supports a launch proof, not a statistical productivity claim.
Choose review depth
The evidence desk holds the full register: observation, value, source trail, limitation, and JSON pointer.
Open evidence deskThe public switcher and retained compositor boundary show the stronger system story: one specimen contract, four public views, eight retained adapters.
Open system lab7 runnable cold/backed demos with 21 measured values for visual, voice, product, and layout surfaces.
Open specimen galleryFive cold runs sit beside five system-backed runs with the pass-rate signal and benchmark caveat visible.
Open pilot matrixThe harbor fixture is a compact mechanical comparison. It is useful, but it is not the flagship proof surface.
Open side-by-side labThe local MCP case shows what a buyer can inspect before any hosted service exists.
Inspect local proofDepth lanes
A buyer should not have to decode a private tracker. These lanes name the public work still needed: clearer case stories, stronger data displays, and controlled evidence before stronger claims.
Cases
Showing 8 of 8
Audience
Type
Maturity
comparison diagram
A team wants to know whether a new agent produces better work when it starts from the project system instead of a bare task prompt.
process trace
A buyer wants to see whether KBPD can make a product surface trace back to structured source material instead of a hand-built page.
process trace
A team wants to understand why KBPD uses specialist roles instead of one generic assistant voice.
council fanout
A team is facing a hard product-planning decision and needs architecture, journey, verification, operations, and business judgment separated before synthesis.
system specimen
A design lead wants to see whether source-backed surfaces can change register without becoming a pile of one-off styles.
registry map
A team has many experiments and needs a shared way to compare them without turning the site into a folder of disconnected artifacts.
evidence terminal
$ node mcp/local-server.mjs --self-test {"ok": true} $ node mcp/smoke.mjs tools/list + representative calls passed A buyer wants to know whether the starter kit can be inspected without waiting for a hosted account.
benchmark gate
A technical evaluator wants a controlled, reproducible answer to whether structured project context improves agent work.
No proof cases match that filter set.