Internal · Tech session guide

Knowledge Graphs — from concept to Codeaza

A guide for Muizz to walk the team through knowledge graphs in a way that actually sticks: start with why they matter, show how they work, then land it on the work we already do — and finish with a live demo everyone remembers.

Format

Talk + live demo

Length

~60 minutes

Presenter

Muizz

Audience

Codeaza engineering

Prepared for

Muizz — session lead

Codeaza engineering team
Internal knowledge-sharing session

Prepared by

Muhammad Asim — Founder & CEO

Codeaza Technologies, Islamabad
October 2026

00Running order

Part

Time

Goal

1 · What a knowledge graph is

10 min

The "why"

2 · How it works

10 min

The engine

3 · Where the world uses it

10 min

Make it familiar

4 · Where Codeaza can use it Key part

10 min

Make it ours

5 · How to build one

10 min

The method

6 · Live demo + Q&A

15–20 min

The "aha"

Try to keep parts 1–3 under 30 minutes, so there's plenty of time for the demo and questions.

01What a knowledge graph is

Open with the problem, not the definition: what can a knowledge graph do that a normal database or a vector store can't?

A knowledge graph stores information as a network: things (nodes) joined by named relationships (edges). A table gives you flat rows. A vector store tells you what's similar. A graph keeps the meaning of the connection. "Asim founded Codeaza" is stored as a fact, not as two things that happen to sit close together.

The basic unit is a simple three-part sentence: subject → relationship → object.

"Muizz"  → works on → "Price Pulse"
"Policy" → covers   → "Flood Damage"

Terms to cover briefly

Nodes — the things (people, companies, documents)

Edges — the named links between them

Properties — details on either one

Ontology — the rules for which things and links are allowed

Good to know

Big examples: Google Knowledge Graph, LinkedIn's Economic Graph, Wikidata

Formal standards: RDF, OWL, SPARQL

But you don't need them to build something useful. Neo4j or plain Python is fine

02How it works

Typed data

Things have types, and relationships matter as much as things

Nodes have a type and properties (Person, Company, Project). Relationships have labels and can carry their own details too, e.g. worked_on with a start_date.

The superpower

Following links is fast

"Which devs worked on projects that use Redis?" is one short graph query, but a pain in SQL. Graph databases jump straight from one node to the next, so each step costs about the same however big the data gets. No scanning whole tables.

Inference

The graph can work out new facts

If A manages B and B manages C, the graph can tell you A indirectly manages C, without anyone ever typing that in.

Tools

Where it lives and how you ask it questions

Storage: Neo4j, Amazon Neptune, ArangoDB, or lightweight Python (NetworkX, RDFLib)
Query languages: Cypher (Neo4j, reads a lot like SQL, so show this one) or SPARQL (RDF stores)

Snippet to show live

MATCH (doc:Document)-[:CONTAINS]->(clause:Clause)-[:REFERENCES]->(entity:Entity)
WHERE entity.type = 'coverage_limit'
RETURN doc.name, clause.text, entity.value

03Where the world already uses it

Google Search

Search "Karachi weather" and you get an answer panel, not just a list of links.

"People you may know" walks your 2nd- and 3rd-degree connections.

Healthcare

Drug → treats → disease and drug → interacts with → drug. This is how safety alerts work.

Fraud detection

Spot rings of accounts that share the same phone, IP or address a few steps apart.

Insurance & legal

Map policy coverage and regulations: law → clause → obligation.

AI / LLMs (GraphRAG)

Instead of handing the model the top few text chunks, give it a small, connected set of facts with sources attached.

04Where Codeaza can use it — the key part

This is the part the team will remember. Tie every idea to something we already build.

Core product

Document AI & extraction

Don't stop at raw JSON. Store what we extract as a graph: Policy → covers → Clause → requires → Document. Then "which clauses are missing from this submission?" is a simple graph lookup, not another LLM call.

The graph also works as a guard rail: does this field belong here? Does this link make sense for this type of document? We catch bad extractions before they reach the client.

Compliance

Insurance, legal & compliance pipelines

Map regulations as Regulation → Article → Clause → Obligation → Entity, then check each new document against it to catch mismatches early.

Sales

Atomic CRM & sales intelligence

Contacts, companies, deals and touchpoints already form a graph. A graph layer can answer "contacts at companies with open deals we haven't spoken to in 30 days" or "which past clients are close to this new prospect?" without a tangle of SQL joins.

Reliability

Sentry & SAU error triage

Model service → depends_on → service and error → originates_in → module. Finding the root cause then means following the links back.

Internal

Our codebase & hiring

Code map: files, functions, dependencies and owners. Useful for onboarding, for "if I change this, what breaks?", and for AI code review
Recruitment: candidate → applied_for → role → requires → skill. Finding skill gaps is a single query

05How to build one

The five steps

1. Design the schema first. Which types of things and which relationships are allowed?

2. Extract. Pull out things and links using regex, spaCy or an LLM, or map them from data we already have

3. Merge duplicates. "Codeaza" and "Codeaza Technologies" should be one node

4. Load. Neo4j Desktop (free Community edition) is the easiest local option

5. Query & visualise. Run 3–4 Cypher queries live: simple lookups, filtering by property, counting steps

Tools for the demo

Python + the neo4j driver, or

Just Python with networkx + matplotlib. No database needed

spaCy or an LLM prompt to extract things from a sample document

Neo4j Browser draws the graph for you automatically; PyVis gives a quick browser view from Python

06Live demo — pick one

Scenario

Effort

Impact

A · Codeaza team graphLoad team members, projects and skills. Ask: "which devs with Python skills are on active projects?"

Low

Good

B · Document extraction graph RecommendedTake a sample insurance policy, pull out Policy / Insured / Coverage / Exclusion with an LLM, load it into Neo4j, then ask: "what exclusions apply to flood damage?"

Medium

Highest

C · Error dependency graphA handful of Sentry errors and the services they hit. Ask: "which services go down if this module fails?"

Low

Good

Why B: it's the closest to where Codeaza is heading. The demo itself makes the case for why this matters, and it's worth an extra 20 minutes of prep.

Demo flow

1. Paste a paragraph from a policy → 2. Pull out the things and links with an LLM → 3. Load into Neo4j → 4. Run the flood-damage query → 5. Show the graph and let it click for everyone.

Size

15–20 nodes is plenty. Small and clear beats big and messy.

07Prep checklist for Muizz

Neo4j Desktop. Installed (free) and running before the session starts.

Python setup. Python with the neo4j driver and openai library installed.

Dataset. Pick one demo and build its data ahead of time. Don't build it live.

Timing. Rehearse once. Parts 1–3 in 30 minutes or less, then 15–20 minutes for the demo and Q&A.

Backup. Have screenshots of the final graph ready in case the live demo misbehaves.

Need help? We can generate the demo dataset, the Cypher queries or a Python ingestion script.