DMBOK area 1
Data governance
Policies you can run, not just file. Who owns each domain, who fixes what breaks, and contracts that catch a schema change before the consumer does.
Master data · Quality · Governance · AI
Every value knows
where it came from.
BeY builds one golden record per entity, keeps the provenance of every field, and measures quality where the data lives. An AI assistant on Amazon Bedrock explains what it finds, ranks what to fix and drafts the fix — a person confirms it.
Capabilities
Eight areas, one model underneath.
The split follows the DMBOK2 knowledge areas — the reference framework for data management. Eight of the eleven have their own screens today. Data architecture lives inside modeling and design, and the last two — document management, and the data warehouse and BI — are under construction.
DMBOK area 3
Modeling & design
Get the model right before anything else. Business lines, domains and entities described without code — because the matching engine can only find the duplicates the model lets it see.
DMBOK area 4
Observability & operations
A control that ran is worth more than a control that exists. Every engine reports whether it is on, how many rules feed it and when it last fired — next to the AWS bill and the tenant's own settings.
DMBOK area 5
Data security & privacy
GDPR held by the platform, not by a spreadsheet. The Article 30 register is built from the data model, so it cannot drift from what you actually process — and every retention rule leaves proof that the purge ran.
DMBOK area 6
Integration
Nothing gets in without a contract, nothing gets out without a policy. Rejected rows land in quarantine with their cause attached; published data is filtered for whoever asks, and counted.
DMBOK area 8
Reference & master data
The golden record, and the proof behind every field. Each value keeps its source, the rule that chose it and who arbitrated — so a merge can be undone for thirty days without loss, and any record replayed as it stood on any date.
DMBOK area 10
Metadata
Business terms bound to real columns, not to a wiki. And lineage that draws what the platform observed and what people declared in different strokes — because the two are only useful if you can tell them apart.
DMBOK area 11
Data quality
Rules are data, not code. Draft one, try it on real rows in a sandbox, publish it, bind it to a field — and let the platform tell you which fields no rule watches yet.
Overview
One platform between your source systems and everyone who consumes the data.
Most organisations know where their data is. Few can say which copy is right. BeY takes the data from the door to publication and keeps, at every step, a record of what was decided and why.
A reference, not one more copy
BeY does not copy your systems around. Your sources keep their data; what lives here is the one version everyone agreed on, rebuilt field by field, with the reason each value won.
Quality measured, not declared
A score is only as honest as its coverage. Every quality figure here arrives with the share of fields it actually watched — so 96% on half the fields never passes for 96%.
Compliance derived from the model
Flag a column as personal data and it shows up in the Article 30 register, under a retention rule, behind an access policy. Compliance follows the model, so it changes when the model does — not when someone remembers the workbook.
An AI that proposes, never decides
On a platform built to say where a number came from, a plausible answer nobody can check is the costliest mistake. So the assistant's tools only read, it cites figures it measured, and every action it suggests waits for a person to confirm.
Why one platform, and not three tools
Quality, glossary and policy describe the same column.
Split across three tools, they contradict each other: the catalog does not know a rule just failed, the policy names an attribute the model has since renamed, and the audit asks for a state nobody can rebuild.
BeY holds them in one model. A quality rule points at the glossary attribute, which points at the physical column, which carries its classification, which triggers the policy. Change one and the others follow — or the gap is reported.
- One schema for every tenant, isolated by
tenant_id— never a schema per customer - Vertical packs — banking, healthcare — switched on per tenant, on a common core
- Custom fields without code: typed, versioned, governed from day one
Product
Four places where the hard part is already done.
The domain registry, engines driven by rules you never compile, an AI assistant that ranks duplicates without merging them, and groupings that lineage follows. Each one exists because doing it by hand stops scaling at the second domain — and each keeps a person in the decision.
Domain registry
Install a domain, not a migration.
The registry is a library of ready-made domain templates — each one a schema plus a semantic manifest. Pick one and the engine applies it, provisions the domain and makes it appear in every hub at once. Or build one from a table you already have.
Dependencies are read, not guessed. A domain declares what it needs to exist, and the
engine works out the full chain and the order to install it — party before
anything that refers to a party, never the reverse. No table is ever created with
references pointing at nothing.
- 39 domain templates, 41 dependency edges, no cycles
partyandlegal_entityare each required by ten other domains- Schema statements come from a reviewed allow-list in code — never from user input
The gain. A new domain goes live in the time it takes to choose it, and it arrives with everything it depends on already standing.
Generic engines & rules
One rule, many bindings — and most of them drawn for you.
A rule is a record in a library — a type and its parameters — not a function somebody deploys. Binding it to data is a link: one rule can watch an attribute, a whole domain or a dataset, and the same library serves every engine.
Most of those links you never draw. The platform reads what a domain already declares
and binds the rules it implies. A freshly provisioned domain carried thirty-five semantic
attributes and zero active rules — while its own manifest already said
preferred_currency → ISO_4217. The information was there; it was simply
unread.
- Rule types are parameters, not branches: pattern, reference-data lookup, built-in checksum, aggregate
- One dictionary across every engine, classified by what a rule does — constrain, control, propose, or nothing
- On the demo tenant: 139 rules, and the 85 that change nothing yet are named as such
The gain. A steward changes what is controlled without waiting for a release — and can see at a glance which rules actually bite.
AI assistant · duplicate arbitration
The assistant ranks the duplicates. A person rules on them.
Two records that may be the same party — same name, different identifiers, one from SAP and one from Salesforce. The engine scores the pair, deterministically on identifiers and probabilistically on the rest, and puts it in the queue. It does not merge on its own: a score of 100 on the name alone is not proof they are the same person.
So the assistant does the reading. Asked what to look at first, it reads the queue and the domain's quality figures, groups the pairs that share a name, flags where one source outweighs the other, and says which pairs are safe and which need a second look. The steward then makes one of three moves — merge, reject, defer — and every one is journalled.
- Merge is reversible for thirty days: the absorbed record is snapshotted, not deleted
- Reject closes the pair for good; defer parks it without losing count
- The assistant's tools only read — it cannot merge, and it cites figures it measured
The gain. The queue drains at the speed of reading rather than investigating, and nobody loses the trace of who decided what, or why.
Groupings & lineage
“These domains go together” — said once, read four ways.
Packs, categories and business lines all say the same thing — these domains belong together — and in most platforms each says it in its own format, so none can answer for the others. BeY stores every grouping as the same edge between a group and a domain. A fifth kind of grouping costs no code at all.
Lineage then reads along whichever grouping you care about: what a business line actually consumes, what a pack brings in, what a category spans. Impact analysis stops being a question you ask three tools.
- Four grouping types today — pack, business line, category, application
- One normalised edge, so every screen reads groupings the same way
- Business lines add what the others cannot: a freshness requirement per need, checked against what was delivered
The gain. “Who breaks if this stops?” gets an answer per business line, per pack or per category — from the same graph, without a second tool.
How it works
The journey of one record, from source to consumer.
- Connect. A connector declares the source: third-party database, file, API. Credentials never leave the secrets vault.
- Ingest. The batch is validated against its inbound contract. Whatever fails goes to quarantine with its exact cause.
- Normalize. The silver layer types and normalizes the records — this is what makes matching possible at all.
- Match. The engine proposes candidates; the steward arbitrates the ones that remain ambiguous.
- Consolidate. The golden record is composed field by field, each value keeping its source and the rule that chose it.
- Control. Quality rules run, the score is recomputed, and gaps surface in the steward's queue.
- Publish. The data product is exposed on pull or pushed to subscribers, under the policy that applies to the requester.
Each of those steps leaves a line in the journal — who, when, why. That journal is what lets Time-travel replay any record as it stood on a given date, with nothing rebuilt by hand.
Want to look under the hood?
The architecture page shows the six layers — one of them is the AI — what each one does, and how all of it gets built and shipped. Anything else, write to us.