Datics AI
← All work

Summers & Company

An AI platform's knowledge graph, built on public data we structured first

Summers & Company is building an AI enabled B2B SaaS platform. Our data engineer worked inside its project, first structuring public datasets in Python, then building the knowledge graph the platform draws on.

EdTechKnowledge graph for an AI platformBuilt from zero

The challenge

The platform's AI depends on public data that sat in scattered, unstructured sources, and an AI is only as dependable as the data beneath it.

What we did

Our data engineer worked inside the client's project in two steps: public datasets collected and structured in Python, then a structured knowledge graph.

The outcome

The client came back for a second, larger scope, vouched for our execution in writing to another AI builder and asked to deepen the partnership.

Client
Summers & Company, an advisory firm
Renewal
A second, larger scoped engagement
Our role
Data engineering and core technical execution
How we worked
A Datics data engineer inside the client's project

The starting point

Summers & Company is an advisory firm led by a university technology leader. It is building an AI enabled B2B SaaS platform whose AI features draw on information from public sources.

What had to change

The public data the platform needs was scattered and unstructured. It had to become structured data first, and then a knowledge graph the AI could work from.

What could not break

  • Sources are public records in mixed formats: HTML portals, CSV exports, APIs and PDF links
  • Data needs periodic updates, so changes must be detected, not reloaded blindly
  • Work runs inside the client's project, under its direction and priorities
  • The graph phase builds on the structured data, not on raw sources

The calls we made

We treated the data as the first deliverable of the AI platform, so its models would inherit structure instead of raw sources.

  1. 01

    Structure the data before the graph

    Phase one scraped and ingested public records from each source, normalized them into JSON or SQL and added basic change detection, because a knowledge graph is only as reliable as the records it links.

    Ruled out

    Modeling the graph straight from raw sources.

  2. 02

    A testable ingestion pipeline

    The first deliverable was a clean, testable pipeline the client's own developers could run and extend, not a one time data dump.

    Ruled out

    A single export with no way to refresh it.

  3. 03

    Lineage in the graph

    Phase two defines the graph schema, normalizes PDF forms, CSVs and API outputs into it and tracks versions and lineage, so the platform can tell where each fact came from.

  4. 04

    The same people across both phases

    The same Datics data engineer and lead carried both phases, so what we learned about the sources moved with the work from datasets to the graph.

How the system fits together

scrapedstructuredmodeledfeedsPublic datasetsScattered publicsourcesCollection andstructuringPython, phase oneStructureddatasetsPublic data instructured formKnowledge graphStructured graph,phase twoClient's AIplatformAI enabled B2B SaaS,in development
Outside serviceBuilt by DaticsData storeClient's existing systemOur data engineering ran inside the client's own project; the AI platform on top of the knowledge graph is the client's own, still being built.

What we built

01

Public data ingestion

Python scraping and ingestion of public records from city level portals, CSV exports, APIs and PDF links, normalized into JSON or SQL with change detection for updates.

02

Structured knowledge graph

A graph schema with PDF forms, CSVs and API outputs normalized into it, versions and lineage tracked, built with the client's ML engineers for retrieval relevance.

How it works

Collect

Public datasets are gathered with Python scraping.

Structure

The records are turned into consistent structured data.

Link

The structured data is modeled as a knowledge graph.

Feed the platform

The knowledge graph gives the client's AI platform a structured base to work from.

A closer look

What changed

The client renewed into a second, larger scoped engagement for the knowledge graph. It vouched for our execution in writing when introducing us to a nonprofit building a human centered AI application, and has since asked to explore a deeper partnership.

Under the hood

Datics role
Forward deployed engineering
Data
Public datasets only, collected and structured in Python.
Knowledge graph
A structured graph built from the structured datasets to feed the client's AI enabled B2B SaaS platform.
Engagement
A forward deployed data engineer inside the client's own project, directed by the client, across two scopes of work.

Apps and APIs

Python

Also in the stack

Web scrapingPublic datasetsKnowledge graph

How it shipped

  1. Phase one: public datasets

    Our data engineer collected public datasets with Python and turned them into structured data for the client's platform.

  2. Phase two: knowledge graph

    The client came back with a second, larger scope for the structured knowledge graph behind the AI platform, and that work continues.

Inside the client's project

Our data engineer worked with the client's own PM and backend developer, mostly asynchronously, available on Slack in Eastern Time with weekly updates in GitHub.

One lead across both phases

The same Datics lead carried both phases, and the client describes our role as data engineering and core technical execution.

Trusted with what came next

The client introduced us to a nonprofit starting a human centered AI application and later asked to deepen the partnership.

What this unlocked

The knowledge graph work continues, and the client has asked to explore a deeper partnership with us.

Related work

Have a product with the same kind of constraints?

Tell us what already exists and what you want it to do. We will tell you what it takes.

Book a 30-minute Product Review