Skip to main content

Validate one capability

Status: Foundation

Use demand-level SpecMatch when your application already has one explicit producer capability target and wants the explainable fit for that relationship.

validated canonical GJS
  + explicit producer capability target
  -> POST /v1/matches
  -> explainable fit, blockers, warnings and confidence

This operation is different from producer-universe matching. /v1/matches/universe evaluates and ranks the authorised universe. /v1/matches evaluates the one target you name.

Read the safe capability projection​

If you carried PROFILE_ID forward from Find capable production, you can read the safe public capability resource:

curl "https://api.gnaww.io/v1/producer-capabilities/${PROFILE_ID}" \
  --header "X-Gnaww-API-Key: ${GNAWW_API_KEY}" \
  --dump-header capability-headers.txt \
  --output capability.json

This is a safe capability read. It does not expose private producer lifecycle, tenancy, raw import or administration state.

Match the retained demand against that target​

Build the request from the retained GJS and the target evidence returned by Gnaww:

jq -n \
  --slurpfile specification specification.json \
  --arg profile_id "${PROFILE_ID}" \
  --arg source "${TARGET_SOURCE}" \
  '{
    gjs: $specification[0].gjs,
    target: {
      source: $source,
      producer_profile_id: $profile_id
    }
  }' > specific-match-request.json

Run SpecMatch:

curl https://api.gnaww.io/v1/matches \
  --request POST \
  --header "X-Gnaww-API-Key: ${GNAWW_API_KEY}" \
  --header "Content-Type: application/json" \
  --dump-header specific-match-headers.txt \
  --output specific-match.json \
  --data @specific-match-request.json

Inspect the explainable result:

jq '{
  status,
  demand_basis,
  recipe,
  readiness,
  target,
  match,
  next_actions,
  producer_selection_performed,
  live_pricing_performed,
  availability_checked,
  producer_acceptance_performed,
  order_created
}' specific-match.json

What the result means​

The result answers whether the controlled demand and the controlled producer capability fit, including the reasons, blockers, warnings and confidence represented by the current SpecMatch contract.

It does not reinterpret the GJS. It does not change the producer capability merely to create a match.

Keep these separate in your application:

capability match != current price
capability match != current availability
capability match != producer acceptance
capability match != an order

A technically capable route may still fail a later live transaction check. Conversely, a provider timeout later does not retroactively make the capability relationship false.

Trace the operation​

Retain X-Request-Id and X-Correlation-Id from specific-match-headers.txt for troubleshooting. The generated API reference remains the field-level schema authority.

Next​

The public developer contract currently stops before transaction orchestration. Read Send an approved job towards production to understand that planned boundary without inventing an order API.

Last updated on