HRS 1:2026 — Annex H

Public register — data schema and verification interface

Public consultation draft — draft v0.1 — issued 2026-09-07

This is a consultation draft, not an operative standard

The scheme described here is not yet certifying. No certificates have been issued and the Approved Supplier Register is not yet populated. Nothing in this document may be relied on as evidence of certification.

It is published for comment before it is finalised, because a certification standard that cannot be read by the people it governs is not a standard. Clause 12.2 commits us to publishing it; we would rather publish it early and be corrected.

Comments are invited until 2 November 2026. See How to respond. Passages marked ⚖️ are open questions on which we are specifically seeking views. Passages marked 📋 will be reconciled against OIC/SMIIC standards before issue.

This document is a scheme design. It is not a fatwa and does not purport to state Islamic law; questions of Shari'ah are for our Shari'ah Committee, whose rulings will be published with their reasoning.

Companion to HRS 1:2026 draft v0.2, clauses 8.2, 8.5, 11.3, 12.3. This is the technical bridge between the standard and the Süfrə platform.

H0. Why the register is the scheme

Clause 12.3 requires the register to be current and machine-readable. That word does real work:

• The certificate on the wall is not the authority — it is a pointer. The register is the authority, and the QR is what makes that true in practice.
• Suspension only means anything if it is visible the same day. A register updated in batches is a register that lies for a while.
• The supplier-suspension cascade (Annex B, B8.7) is only possible if establishment→supplier relationships are stored as data, not as text in an audit report.
• Platform listings (cl. 8.5) can only be reconciled against certification if something reconcilable exists to check them against.

Design rule: the register is a public, read-only source of truth. Süfrə consumes it. Süfrə is not it. Keeping the register separate from the directory app means a future regulator, a platform, or a competitor's app can consume it too — which is what makes it infrastructure rather than a feature.

H1. Entities

Establishment ──< Certificate >── Class
      │
      ├──< SupplierRelationship >── Supplier ──< SupplierCertificate
      │
      └──< PlatformListing

H2. Establishment record

{
  "id": "EST-0000123",
  "legal_name": "...",
  "trading_name": "...",
  "address": { "line1": "...", "city": "Bakı", "district": "...", "postcode": "...",
               "lat": 40.0000, "lng": 49.0000 },
  "contact": { "phone": "...", "website": "..." },
  "certificate": {
    "number": "HRS-A-2026-000123",
    "class": "A",
    "status": "active",
    "scope": "Entire premises: kitchen, service, storage",
    "scope_exclusions": [],
    "issued": "2026-03-01",
    "expires": "2027-02-28",
    "decision_date": "2026-02-24"
  },
  "status_history": [
    { "status": "active",    "from": "2026-03-01", "to": null, "reason": null }
  ],
  "suppliers": ["SUP-000045", "SUP-000112"],
  "platform_listings": [
    { "platform": "wolt", "url": "...", "declared": "2026-03-05", "verified": "2026-09-01" }
  ],
  "languages_verified": ["az", "ru", "en", "ar"],
  "last_audit": "2026-09-01",
  "last_audit_type": "unannounced",
  "next_audit_due": "2027-01-15",
  "verify_url": "https://sufra.halalekosistem.org/register/e/EST-0000123"
}

H2.1 status — the controlled vocabulary

status is never deleted and never silently changed. Every transition appends to status_history with a reason. The register's credibility rests on it being an append-only record rather than a current-members list.

H2.2 Fields deliberately not public

Audit reports, findings and gradings, fees paid, commercial terms, complaint and reporter identities, internal notes. Publishing findings would deter self-reporting under Annex C, which costs more integrity than the transparency gains.

But status changes caused by findings are always public — the fact of suspension, its date, and its category. Outcome public, evidence private.

H3. Supplier record

{
  "id": "SUP-000045",
  "name": "...",
  "site_address": { "...": "..." },
  "category": "S1",
  "route": 2,
  "species_scope": ["ovine", "bovine"],
  "stunning": "none",
  "recognising_body": null,
  "status": "active",
  "issued": "2026-01-15",
  "expires": "2027-01-14",
  "supplies_to_count": 14,
  "verify_url": "https://sufra.halalekosistem.org/register/s/SUP-000045"
}

• category — S1–S6 (Annex B, B1)
• route — 1 recognised certificate · 2 direct assessment · 3 imported certified
• stunning — none | reversible | not_applicable ⚖️ pending Annex B, B4.6
• recognising_body — required for routes 1 and 3, null for route 2
• supplies_to_count — a count, not a list. Which restaurants buy from whom is commercially sensitive; the count still lets a consumer see a supplier's reach

H4. Public API

Read-only, no authentication, CORS-open, rate-limited.

/changes is the important one. It lets Süfrə, a delivery platform, or anyone else keep a mirror correct without polling every record — and it is how a suspension propagates in minutes instead of at the next full sync.

H4.1 QR destinations

• Resolve to /register/e/{id} or /register/s/{id} — never to a PDF, never to a marketing page
• Work with no app and no login (Annex E, E3.1)
• Remain resolvable after expiry or withdrawal, showing that state — a dead link lets a stale certificate keep working
• Show, above the fold: name · class · status · valid-until · last audit date

H4.2 Status page rendering

suspended and withdrawn must be visually unmistakable — not a small grey label. Someone scanning a QR in a doorway has about three seconds and is probably holding a coat.

H5. Integration with Süfrə

The last row matters more than it looks. If our own directory is exempt from the platform rules we impose on Wolt and Bolt Food, clause 12's impartiality claim is decorative.

H6. Consultation questions

1. Domain and hosting for the register — separate from sufra.* so it reads as infrastructure rather than a feature of one app.
2. Certificate numbering — proposed HRS-{class}-{year}-{seq}; confirm with Annex E, E8.4.
3. /changes retention window — how far back can a consumer replay? Suggest ≥24 months to match cl. 11.3.
4. Geo-coordinates public? Useful for map integration; makes bulk scraping of the member list trivial. Probably accept — the register is public by design.
5. supplies_to_count — confirm with suppliers that a count is acceptable where a list is not.
6. Bilingual/trilingual API content — are scope and reason fields stored per language, or as codes resolved client-side? Codes are better for consistency across AZ/RU/EN/AR.
7. Availability commitment. If the QR is the verification mechanism, register downtime means no certificate in the country can be verified. Needs an uptime target and a static fallback.

H7. In preparation

• H-F1 OpenAPI specification
• H-F2 Register page designs — establishment, supplier, and the three status states
• H-F3 Süfrə sync service specification
• H-F4 QR generation and certificate-print integration
• H-F5 Backup, audit-log and tamper-evidence design for status_history