match request fixes

[touchthesun]

Subject: Fix OHM match integration: valid OKH payloads, response parsing, and docs

Summary

Matching failed or looked “broken” mainly because the UI did not speak the same contract as supply-graph-ai’s POST /v1/api/match, and responses were interpreted incorrectly.

Root causes

• Invalid request body: The supply-graph test page sent a hardcoded recipe_id (cooking) instead of a manufacturing OKH input. OHM expects exactly one of okh_id / okh_manifest / okh_url, and rejects extra fields (extra = "forbid"), so requests could 422 or hit the wrong domain.
• Wrong response handling: OHM wraps results in { data: { solutions, … } }. The UI looked for top-level fields like components / related_items, so successful 200 responses appeared empty or useless.
• Problematic fetch usage: Setting Origin (and similar) from the client is invalid/forbidden for browsers and did not help CORS.
• Fragile product page: The supply tree view assumed data.solutions always existed and treated HTTP 200 with an empty solution list like a hard failure.
• Path / ops gaps: The real match path is /v1/api/match (not the mock’s /v1/match). Local setup (Docker OHM on 8001, 127.0.0.1 vs localhost for Azure Functions, blob URLs reachable from OHM) was undocumented.

Fixes

• Added packages/front-end/utils/ohmMatch.ts: build okh_url from listing fname, postOhmMatch, parseOhmMatchBody.
• Updated supply-graph-api.vue and products/[id]/supplyTree.vue to use that helper, strip bad headers, and parse data.solutions safely.
• Added docs/match-endpoint-integration.md and README updates: env vars, Docker vs local OHM, CORS, OKH vs OKW workflow (OKH from client URL; OKWs loaded in OHM), verification steps.
• Added scripts/verify-ohm-match.mjs to assert the same payload/headers as the UI against a running OHM.
• Stopped treating empty solutions on 200 as a transport error on the supply tree page.

[RobertLRead]

Dear @touchthesun, Thank you! I have looked over all of this and it looks excellent; it looks like you put a lot of work into it. We tested your code in this PR today. Unfortunately it STILL does not return a match for either our "chocolate chip cookie" OKH nor our "oatmeal raisin cookie" OKHs. We tested these through the changes that you made in this repo (thank you!) but it returned no matches. Then we went and tested the same thing through your swagger(?) API documentation, and it ALSO returns no matches. Here is an example from you code that we need to return a match---you should be able to run this yourself and tell us if it matches or not.

curl -X 'POST' \ 'http://localhost:8001/v1/api/match' \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d '{"okh_url":"https://projdatablobstorage.blob.core.windows.net/okh/okh-chococolate-chip-cookies-recipe.json"}'

This is from your api docs tool:

{ "status": "success", "message": "Matching completed successfully", "timestamp": "2026-03-31T22:11:03.850219", "request_id": "35673435-1c5d-4eff-ae82-653a8c820752", "data": { "solutions": [], "total_solutions": 0, "matching_mode": "single-level", "processing_time": 0.453461, "matching_metrics": { "direct_matches": 0, "heuristic_matches": 0, "nlp_matches": 0, "llm_matches": 0 }, "validation_results": [] }, "metadata": { "processing_time": 0.45374298095703125, "timestamp": "2026-03-31T22:11:03.850226" } }

When we do this in our browser from our GUI with this payload:
{"okh_url":"https://projdatablobstorage.blob.core.windows.net/okh/okh-chococolate-chip-cookies-recipe.json"}
we get this response:
{ "status": "success", "message": "Matching completed successfully", "timestamp": "2026-03-31T22:05:57.635622", "request_id": "ab15fe2a-4787-4c31-a277-36918a985b89", "data": { "solutions": [], "total_solutions": 0, "matching_mode": "single-level", "processing_time": 0.483513, "matching_metrics": { "direct_matches": 0, "heuristic_matches": 0, "nlp_matches": 0, "llm_matches": 0 }, "validation_results": [] }, "metadata": { "processing_time": 0.48415231704711914, "timestamp": "2026-03-31T22:05:57.635630" } }

If you can get this to match and return our OKWs (James's kitchen and Rob's kitchen), then please provide a screenshot showing exactly what you are doing (perhaps the curl command for it?)

[touchthesun]

"Butler Kitchen" and "Rob's Dessert Kitchen" have completely empty appliances, tools, and ingredients arrays in the OKW JSON files stored in Azure. These need to be populated with actual kitchen capabilities for accurate confidence scoring. The matching system has nothing to match against.

[touchthesun]

I patched the match endpoint on my end so that when there's no data in the kitchen, it defaults to confidence measure of 0.5 instead of 0, just to represent basic general capability. I'm pushing the patched code for supply-graph-ai into main, so just pull from main and run 'docker compose up --build -d' to recreate the server.

[RobertLRead]

This is the first time you have told us of those things. Do you mean this file in newformats: https://projdatablobstorage.blob.core.windows.net/newformats/okw/ButlerKitchen.json { "id": "550e8400-e29b-41d4-a716-446655440001", "name": "Rob's Dessert Kitchen", "appliances": [], "tools": [], "ingredients": [], "domain": "cooking" } I DID NOT create this file. I believe you must have created it. James and I created a completely different format carefully constructed from the sample from your docs api. It was much longer, and very voluminous.

…

On Mon, Apr 6, 2026 at 11:16 PM Nathan Parker ***@***.***> wrote: *touchthesun* left a comment (helpfulengineering/project-data-platform-ts#97) <#97 (comment)> "Butler Kitchen" and "Rob's Dessert Kitchen" have completely empty appliances, tools, and ingredients arrays in the OKW JSON files stored in Azure. These need to be populated with actual kitchen capabilities for accurate confidence scoring. The matching system has nothing to match against. — Reply to this email directly, view it on GitHub <#97 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABINEH3J7CYCIAXJBWZV77T4UR6IPAVCNFSM6AAAAACXFKZHYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOJWGQYTGNJRHE> . You are receiving this because your review was requested.Message ID: ***@***.*** com>

-- Robert L. Read, PhD Twitter: @RobertLeeRead @pubinvention Public Invention: https://www.pubinv.org Join Our Mailing list: ***@***.*** YouTube: https://www.youtube.com/channel/UCJQg_dkDY3KTP1ybugYwReg Medium: ***@***.***

[RobertLRead]

This is the file that we created with considerable labor from the example file that your documentation provided. The short empty one that is there now was not created by me, and almost certainly not by James.

…

On Mon, Apr 6, 2026 at 11:30 PM Robert Read ***@***.***> wrote: This is the first time you have told us of those things. Do you mean this file in newformats: https://projdatablobstorage.blob.core.windows.net/newformats/okw/ButlerKitchen.json { "id": "550e8400-e29b-41d4-a716-446655440001", "name": "Rob's Dessert Kitchen", "appliances": [], "tools": [], "ingredients": [], "domain": "cooking" } I DID NOT create this file. I believe you must have created it. James and I created a completely different format carefully constructed from the sample from your docs api. It was much longer, and very voluminous. On Mon, Apr 6, 2026 at 11:16 PM Nathan Parker ***@***.***> wrote: > *touchthesun* left a comment > (helpfulengineering/project-data-platform-ts#97) > <#97 (comment)> > > "Butler Kitchen" and "Rob's Dessert Kitchen" have completely empty > appliances, tools, and ingredients arrays in the OKW JSON files stored in > Azure. These need to be populated with actual kitchen capabilities for > accurate confidence scoring. The matching system has nothing to match > against. > > — > Reply to this email directly, view it on GitHub > <#97 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABINEH3J7CYCIAXJBWZV77T4UR6IPAVCNFSM6AAAAACXFKZHYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOJWGQYTGNJRHE> > . > You are receiving this because your review was requested.Message ID: > ***@***.*** > com> > -- Robert L. Read, PhD Twitter: @RobertLeeRead @pubinvention Public Invention: https://www.pubinv.org Join Our Mailing list: ***@***.*** YouTube: https://www.youtube.com/channel/UCJQg_dkDY3KTP1ybugYwReg Medium: ***@***.***

-- Robert L. Read, PhD Twitter: @RobertLeeRead @pubinvention Public Invention: https://www.pubinv.org Join Our Mailing list: ***@***.*** YouTube: https://www.youtube.com/channel/UCJQg_dkDY3KTP1ybugYwReg Medium: ***@***.***