Skip to content
HRIMH

Products & Platforms

Systems that make information quality visible.

HRIMH develops technology initiatives focused on better-informed decisions, responsible information practices and practical public-interest applications. Each initiative is presented according to its current stage of development.

How status labels are used
Platform concept
Problem, workflow and architecture defined; not presented as built.
Product direction
Intended capabilities under active definition; not released features.
Prototype
A working artefact testing key assumptions. Used only when verified.
Available
In production use. Used only when verified.
P—01Consumer Trust InfrastructureProduct direction

BELIEF

BELIEF explores how technology can help consumers make more informed everyday decisions through clearer and more accessible information.

The problem

Every day, people make consumption decisions with incomplete information. A packaged food label lists ingredients but not their origin. Information exists, but it is scattered across sources of very different reliability, and consumers have no practical way to tell them apart.

Existing ratings tend to compress this complexity into a single number or star count. That is convenient but misleading: a score does not reveal what it was based on, how current that information is, or what was missing when it was calculated. People either over-trust it or ignore it.

BELIEF addresses a narrower and more honest question: what is actually known about this item, how do we know it, and what is not known?

Intended categories

  • Packaged products
  • Food
  • Medicine
  • Cosmetics
  • Baby Care

Packaged product

Example item

EAN ··· 0000
  • IngredientsMatches manufacturer label
    Verified
  • Allergen statementContains: milk, soy
    Verified
  • Origin“Locally sourced” (retailer)
    Reported
  • Packaging claimNo supporting evidence
    Unverified

Not known: independent laboratory test results are not available for this item.

Fig. 2 — Illustrative information pattern showing tier labelling and stated limitations. Not a screenshot of a released product.

Trust must communicate its basis — and its limits

The core design rule of BELIEF is a strict separation between three tiers of information. They are never merged into one undifferentiated figure. A trust signal is a summary of available evidence; it does not independently prove that a product is safe, authentic or suitable, and BELIEF is designed so that it never implies otherwise. When better evidence appears, records change — and the change is visible.

Verified
Information confirmed against an identifiable, authoritative source, with the source and date recorded.
e.g. Ingredient list matched to manufacturer label data; source and retrieval date shown.
Reported
Information supplied by a party — a seller, a user or a third party — that has not been independently confirmed.
e.g. “Locally sourced” as stated by the retailer; attributed, not endorsed.
Unverified
Claims for which no supporting evidence is currently available. Shown only with an explicit label, if at all.
e.g. A marketing claim with no available substantiation.

Product direction

The capabilities below describe the intended direction of the product. They are not presented as released features.

  • Product discovery and identification

    Locate an item by search, category or barcode, and resolve it to a single canonical record so that information from different sources attaches to the right product.

  • Scan-led information experiences

    A camera-first path designed for use in a shop: scan, see a clear summary within seconds, and expand into detail only when needed.

  • Evidence-oriented trust explanations

    Every trust signal is accompanied by its basis — which sources contributed, how recent they are and what was not available — rather than an unexplained score.

  • Consumer-facing information architecture

    Information is organised around the questions people actually ask — what is in it, where it is from, what others have reported — not around internal data structures.

  • Product intelligence and comparison

    Compare items on attributes that matter to the user, with comparisons limited to fields where comparable evidence exists for both items.

An example journey

  1. 01 — Identify

    A consumer begins by identifying a product or exploring relevant information.

  2. 02 — Summarise

    BELIEFs intended direction is to present relevant information in a clear, accessible format.

  3. 03 — Inspect evidence

    Users can explore available information and understand its stated basis and limitations.

  4. 04 — Understand limits

    The experience is intended to communicate uncertainty and distinguish available information from what remains unknown.

  5. 05 — Decide

    The goal is to support more informed choices without overstating what the available information proves.

Intended users

Consumers making everyday purchasing and consumption decisions; secondarily, producers and sellers who wish to provide verifiable information about what they offer.

Technical considerations

The initiative considers data quality, information reliability, source transparency and responsible handling of user-contributed information.

Current verified status

Published as product direction. Prototype, implementation and availability details will be stated here once they have been verified for publication.

P—02Platform concept

Suraksha FDA

Digital Food-Safety Governance

An AI-powered digital food-safety governance platform concept: a structured path from a citizen complaint to an accountable administrative review, with evidence, roles and an auditable record.

Food-safety complaints are often submitted through channels that were not designed for them — phone lines, general email inboxes, paper forms or social media. Evidence arrives detached from the complaint, location details are vague, and once submitted the citizen rarely learns what happened next. For the authority, complaints are difficult to deduplicate, prioritise and track, and there is limited consistent data from which to identify recurring problems.

Suraksha FDA proposes a single structured path from report to resolution: a citizen-facing submission experience, an administrative review workflow for authorised personnel, and a complete record linking the two. AI assistance is envisaged for supporting tasks such as suggested categorisation or duplicate detection, always as a recommendation reviewed by staff.

Proposed workflow

Six steps across three participants. Responsibility moves from the citizen to the platform to authorised personnel — and the citizen can follow status throughout.

Citizen
Step 1Submit complaintA guided form captures the nature of the concern in plain language.
Step 2Attach evidencePhotographs, receipts or documents are added to support the report.
—
—
—
—
Platform
—
—
Step 3Record contextLocation and submission details are recorded where appropriate and consented.
Step 4Enter review queueThe complaint receives a reference and enters the administrative workflow.
—
—
Authorised personnel
—
—
—
—
Step 5Review & categoriseAuthorised staff assess the complaint, assign category and priority.
Step 6Manage status & actionFollow-up actions and status changes are recorded through the admin interface.

Complaint lifecycle states

  1. Submitted
  2. Under review
  3. Information requested
  4. Action assigned
  5. Resolved
  6. Closed

Transitions are constrained: a complaint cannot be closed without a recorded outcome, and every transition is attributed to an authorised user.

Technical and governance considerations

Role-based access
Citizens, reviewing officers, supervisors and administrators hold distinct permissions, enforced on the server for every request. Staff see only the complaints within their jurisdiction and remit.
Auditability
Every status change, categorisation and note is recorded with the acting user and time in an append-only log, so the handling of any complaint can be reconstructed and reviewed.
Evidence handling
Uploaded files are stored privately, scanned and validated by type and size, served only through short-lived authorised links, and linked immutably to the complaint they support.
Privacy
Only information needed to investigate is collected. Complainant identity is separated from complaint content where possible, and precise location is captured only when relevant and consented.
Secure infrastructure
Encrypted transport and storage, least-privilege service credentials, rate-limited public endpoints and monitored administrative access appropriate to sensitive public-sector data.
Regulatory alignment
Categories, timelines, escalation and outcomes must be configured to match the applicable regulatory process and the authority’s own procedures — the platform supports that process; it does not define it.

Intended users

Citizens reporting food-safety concerns, and the authorised personnel responsible for reviewing and acting on those reports within an appropriate authority.

Potential value

More complete complaints, consistent categorisation, visible status for citizens, traceable handling for supervisors, and structured data that could help identify recurring issues.

Current verified status

A platform concept. It is not presented as officially endorsed, adopted or operational for any government authority.

Interested in either initiative?

HRIMH welcomes conversations with organisations, researchers and domain specialists who could help validate, shape or responsibly deploy these systems. Please describe your context and interest.