Origin, access model, eligibility, and substitution are reviewer diagnostics, not judging criteria. Authentication requirements are not penalized.
02 The two blind reviews
Two independent reviewers scored this project blind, from a sanitized evidence packet.
Scores are shown separately so the reasoning stays inspectable. A withheld score means the reviewers differed by more than two points.
Reviewer A (round 1)
confidence 92%
Leverage
10 /10
The central answers are computed from live geometric and approval state and are not necessarily rendered in the UI; WebMCP gives agents precise, stateful access to capabilities a DOM agent cannot reliably infer.
Evidence cited
Transcript demonstrates route, clearance, approval, decline, version, and topology queries.
Description says route is computed with Dijkstra over validated graph and names blocking doors.
Fourteen page-defined tools expose the venue session to agents.
Execution
9 /10
The video transcript shows a coherent end-to-end workflow across querying, reporting, approval, versioning, decline, and refresh, with safe non-live states.
Evidence cited
178-second video with transcript covering multiple successful and refused outcomes.
Transcript reports route distances, doorway widths, queued reports, approval, decline, and persistent version state.
Demo is reported alive and repository is public.
Impact
9 /10
Blind and low-vision visitors and wheelchair users have a specific, consequential need for reliable indoor accessibility routes; the product directly addresses it.
Evidence cited
Description identifies rehearsing unfamiliar routes and risk of being stranded or wasting a trip.
Demo answers step-free and personal-width route questions and explains barriers.
Creativity
9 /10
Making a floor plan conversational, route-computable, and community-correctable with venue approval is a notably original interaction model.
Evidence cited
Flat PDF becomes queryable topology rather than merely searchable text.
Visitor reports and venue approval preserve governance while updating route graphs.
Reviewer B (round 2)
confidence 93%
Leverage
10 /10
The key answers are computed from structured building topology and body constraints but are not rendered in the UI; WebMCP exposes capabilities a general UI-driving agent could not reliably discover.
Evidence cited
Transcript demonstrates route, clearance, blocking-door explanation, versioning, and approved/declined reports.
About text says answers are computed from geometry and absent from the DOM.
Fourteen tools expose route and venue state.
Execution
9 /10
The transcript gives unusually strong end-to-end evidence across successful routes, blocked routes, approvals, version refresh, and declined reports; frame sheet visibly supports floor-plan UI.
Evidence cited
178-second video with detailed end-to-end transcript.
Demo alive and public repository exists.
Transcript covers 13/13 style state progression and immutable declined report.
Impact
9 /10
Disabled and low-vision visitors have a high-stakes, specific need for reliable indoor accessibility answers before and during a visit.
Evidence cited
Specific wheelchair-width clearance scenario and step-free routing.
Tool returns reasons and blocking doorway rather than opaque failure.
Venue correction workflow reduces stale plan risk.
Creativity
9 /10
Turning a static floor plan into an agent-queryable, versioned accessibility authority with explainable topology updates is highly original and deeply pursued.
Evidence cited
Computed answers are not simple page actions.
Approval/decline audit semantics and route graph versioning are integrated into the interaction model.
03 Review highlights
Standouts across reviewers
Excellent end-to-end transcript evidence.
Fail-safe approval and decline semantics.
Personalized clearance checking.
High-stakes accessibility value.
WebMCP exposes non-rendered computed knowledge with auditably approved updates.
Red flags
Core floor-plan parser existed before challenge according to about text.
04 Evidence
What each artifact proves is labeled on the artifact itself. A Devpost page capture is packaging evidence, not proof the product runs;
video frames are evidence from the submitted demo, not live verification.
Probe captures come from Stage 2 interactive testing of the live product by a reviewer.
EX-01 Devpost page capture · packaging evidence, not runtime proof
· sourceEX-02 Live probe at Stage 2 · observed product behavior, reviewer-drivenEX-03 Live probe after interaction · observed product behavior
EX-V Submitted demo video — “Spatialize : The WebMCP Challenge”
Contact sheets from the 178s video the team submitted. This is what reviewers were shown;
it demonstrates the product in motion but is not independent verification.
· watch the original
EX-V1 Sheet 1 of 3 · reported video evidenceEX-V2 Sheet 2 of 3 · reported video evidenceEX-V3 Sheet 3 of 3 · reported video evidence
