Latest recorded Ask OKF service publication
<!-- Generated by scripts/build_service_publication.py. Edit evaluation/service-publication.json, not this page. -->
This page reports retained observations, not real-time health. It makes no live request. Ask OKF is an independent experiment, not an official DWP service or benefits advice.
The latest recorded successful publication is service 0.7.0, on 25 September 2026 at 15:02:03 BST. See the exact recorded receipt.
Open the service · Monday walkthrough · What Search, Ask OKF and an AI answer mean
| Recorded identity | Value |
|---|---|
| Service version | 0.7.0 |
| DWP source commit | 7eeded763042ddd0070f4fed834c6074149e8e2f |
| Deployed runtime commit | 31d8c3436ed289bfd694b7889a9e5edea834ea8b |
| Local Worker SHA-256 | 9c7f31dc62e40b69de10a22aa7685becb16bbe22531d6ee78a9bbc357adfc680 |
Recorded tool verification
The exact recorded receipt completed at 25 September 2026 at 15:06:32 BST. It passed 12 evidence cases, including 10 approved source/engine combinations, with 135 HTTP requests and 11,974,541 received bytes.
SDK means software development kit: here it is the test client used to call the tools. Complete packages were reconstructed from bounded reads and compared with the local reference. There were no automatic retries, model calls or full ask_okf calls.
HTTP response census: 134 × HTTP 200, 1 × HTTP 202.
- Context engine source:
d6930bbcddaab616deec002d9e6efff6e3aae953. - Context engine identifier:
urn:okf:context-engine:sha256:256b19d6d8a2e16191866ead0ffd48d9edb7f705143bd8a91597b19f242c0968. - SDK verifier commit:
31d8c3436ed289bfd694b7889a9e5edea834ea8b.
The verifier and deployed runtime can have different commits: a verifier correction does not redeploy the service.
What these records do not establish
The hosting record and SDK observation are separate evidence. The SDK explicitly does not independently attest the hosted Worker bytes. Delivery integrity does not establish complete evidence, legal correctness, specialist acceptance, a public browser journey or ChatGPT/Voice access. Those require their own observations. Earlier failures and successful historical checks remain unchanged.
Keep this page in step with new observations
One authored receipt selection pins exact public Git commits, paths, byte lengths and hashes. A hash identifies exact file contents. The generator checks those immutable bytes and scans the bounded validation/compact-delivery/ receipt namespace. A newer successful publication or matching successful SDK receipt must be represented before CI passes. CI means automated repository checks.
The census includes the unversioned compact receipt and versioned releases, including explicitly named follow-ups. Candidate builds, failure.json attempts, earlier non-compact deployment schemas and unrelated Explorer/Pages observations are outside this service-status census. An unknown schema or location within the reserved census fails closed. The check never queries a host or executes an acquired receipt.
After recording a new publication, commit its receipt first, update the selection to its immutable identity, then regenerate this page. Set sdk to null while that publication has no matching successful observation. Do not copy an older SDK pass onto it.
uv sync --locked
uv run --locked python scripts/build_service_publication.py
uv run --locked python scripts/build_service_publication.py --check
uv run --locked python -m unittest discover -s scripts -p test_service_publication.py
A shallow checkout must contain the commits named in the receipt selection. CI fetches those exact public objects separately; the generator itself never uses the network.