Our process
Kenyan business risk lives across courts, gazette notices, procurement lists, regulators, and news — not in one place. BRIA wires those records (plus licensed feeds we add over time) into a single cited view per company. This page explains how we work — enough for compliance and audit teams to assess validity, without publishing the proprietary models that make the product defensible.
What we optimise for
Every flag in a report must trace to an authoritative record — a court filing, gazette notice, regulator register, procurement list, licensed proprietary feed, or news article — not an opaque model output.
Data sources are ingested on separate schedules. If one government site is temporarily unavailable, others continue to update. No single feed defines the whole picture.
Risk flags ship with plain-language explanations and citations. A reviewer can open the underlying source and verify the finding without re-running our pipeline.
Public records are the foundation; we also onboard proprietary datasets with every release as they clear quality and licensing review. Your reports name which source families contributed — public, licensed, or both.
Each score is stamped with when it was calculated and which scoring model version produced it — so you know whether two reports are comparable.
From records to cited score
We do not ask you to trust a black box. The pipeline below is the full story at the level we share publicly. Individual techniques — matching rules, signal weighting, and quality controls — remain proprietary.
-
Collect from authoritative sources
We maintain scheduled ingestion from Kenyan public records — court judgments, official gazette notices, public procurement registers, sector regulator databases, and adverse media. With every release we also onboard additional proprietary datasets that pass licensing and quality review. Public and licensed sources run through the same pipeline; only what is named in your report contributed to the score.
-
Preserve and structure
Raw documents are archived before interpretation. Structured facts — parties, dates, case references, notice types — are extracted and stored as queryable records. Where a source publishes clean tabular data, we use it directly; where documents are unstructured, we apply controlled machine-assisted extraction with human-auditable outputs.
-
Resolve the entity
A company name you type rarely matches every database spelling exactly. We maintain a resolved entity graph — one profile per real organisation — so Acme Ltd, ACME LIMITED, and common trading names collapse to a single match with a stated confidence level. When we cannot match with sufficient confidence, we say so explicitly rather than guess.
-
Assess risk signals
Matched entities are evaluated against a fixed catalogue of risk signal types — litigation, debarment, regulatory action, adverse media, director-network exposure, and positive indicators such as active licences. Signals are combined into a 0–100 score and a plain-language rating band. The combination logic is calibrated against labelled scenarios and updated through versioned model releases — not ad hoc per query.
-
Deliver a cited report
The API and PDF report return the score, individual flags, explanations, source references, match confidence, data coverage, and freshness metadata. Your team can attach the PDF to an onboarding file or consume the JSON in your own workflow.
What you can audit on every report
These fields are designed for teams who need to defend a screening decision — not just read a number.
| Field | Why it matters |
|---|---|
| Match confidence | How certain we are that the returned entity is the company you searched for. |
| Flag explanations + citations | What we found, in plain language, with a path back to the primary record. |
| Sources checked | Which data families contributed to this score (e.g. courts, procurement, media). |
| Scored date | When the score was last calculated against our corpus. |
| Scoring model version | Which version of our rules produced the number — comparable across reports. |
How automation is used (and bounded)
BRIA is not “AI decides if a company is risky.” Automation helps where public records are messy — extracting fields from a judgment PDF, classifying whether a news article is materially adverse, reading a gazette scan — always into structured rows that a human reviewer can inspect via citations.
What we deliberately do not publish
To protect the integrity of the product and our customers’ screening advantage, we do not open-source:
- Signal weights, rating-band thresholds, or time-decay parameters
- Entity-matching algorithms, blocking rules, or merge heuristics
- Extraction prompts, classifier training details, or scraper implementation
- Proprietary feed identities, licensing terms, or ingestion mechanics beyond what is named in your report
Pilots and enterprise agreements can include deeper methodological walkthroughs under NDA. Public API responses always include enough metadata to verify individual findings without exposing the full engine.
Limitations — please read
BRIA aggregates Kenyan public records and proprietary datasets onboarded with each release. It is not a credit reference bureau, not a substitute for legal advice, and not endorsed by the Central Bank of Kenya.
A low score does not guarantee a company is safe; a high score does not prove guilt. Material onboarding decisions should be reviewed by qualified staff against the cited primary sources. Coverage depends on what has been published to the sources we monitor — we report coverage tier and confidence so gaps are visible.
Evidence we stand behind
We publish product claims only from live evaluation runs, not marketing approximations. In our most recent labelled screening exercise, we reported zero false positives across twenty known Kenyan companies — each flag spot-checkable against its cited source. The live demo uses the same response shape as production; sample data is labelled clearly where shown.