Idrak

YFlow · intelligence engine

It learns what

your data

actually means.

YFlow reads the systems you already run and works out what every table and column means. Anything it cannot be sure of, it asks the person who knows, once, and every tool built on top inherits the answer: a semantic model, then a knowledge graph, then an open door for your agents over MCP and API.

Book a demo How it builds understanding

↓ Scroll

Why schemas are not enough

A table name is not

a definition.

Ask a language model for last month's net revenue by site and it will happily write SQL against tbl_ord_hdr. It will not know that voided orders sit in the same table, that the Riyadh entity reports on a different calendar, or that your finance team excludes internal transfers.

Those rules are the business. YFlow captures them once, in a layer that sits between the raw systems and everything that asks questions of them.

Same question, two answers

Raw schema access

SAR 4,182,900

Includes voids and internal transfers. Fluent, and wrong.

Through YFlow

SAR 3,904,150

Net revenue as your finance team defines it, with the definition attached.

Real before / after

One ambiguous column. Two different outcomes.

A real record, a real question, a real trust badge, straight from the YFlow console. Answer it and watch what changes.

YFlow · understanding & questions

The record

Ledger Entries Blocked

General ledger postings.

Blocked · needs your decision

Blocking 3 Finance metrics

The question

Does the AMOUNT column on Ledger Entries hold a signed value, negative for debits, or an absolute value with a separate direction flag?

Evidence

82% of AMOUNT values are positive, and a DR_CR column holds 'D' / 'C'.

My best guess

It is an absolute value. The DR_CR column carries the debit / credit direction.

Waiting on your decision. Answer the question above to see what changes.

That was a sample warehouse. A demo starts with a read-only connection to yours.

The understanding layer

Four steps from raw tables to agent-ready meaning.

0% understood

01 · Connect

Read the systems, change nothing

Read-only against ERP, CRM, inventory and finance. YFlow profiles schemas, sample values and lineage to see how the data is really used.

02 · Semantic layer

Name things the way you do

Entities are resolved and deduplicated, metrics get one canonical definition, and anything YFlow cannot settle from the data alone it asks your team to confirm, once.

03 · Knowledge graph

Hold how everything relates

Site, product, supplier, invoice and shift become a connected graph, so a question can traverse from a cost spike to the purchase order behind it.

04 · Open the doors

MCP and API, governed

Agents and analysis tools query the layer instead of the raw schema, inheriting your definitions and your permissions on every call.

What you get

One layer, three things it guarantees.

One definition

Net revenue means the same thing in a board deck, a dashboard and an agent's answer, because all three read the same layer.

Traceable answers

Every result carries the path it took, from the question through the graph to the rows it rests on. You can audit it, not just trust it.

Model independence

The understanding lives in your layer, not in a prompt. Swap the model underneath and your definitions survive.

Open by design

Your agents get a door, not a scraper.

YFlow exposes the understanding layer as tools over MCP and as a REST and GraphQL API. Whatever you build on, the agent asks in business language and gets governed, defined answers back.

MCP tools REST GraphQL Row-level permissions

MCP · yflow.query

→ "net revenue by site, last month,

excluding internal transfers"

resolved metric.net_revenue

grain entity.site × month

filters exclude order.type = internal

graph site → order → line → product

✓ 14 rows · definition v4 · 320ms

In the stack