In Part 1, we saw why probabilistic AI architectures fail without a deterministic data foundation. In Part 2, we looked under the hood at how Knowledge Graphs model business reality using Subject – Predicate – Object triples and global Web identifiers (IRIs). At this point in the conversation, almost every VP of Engineering or Product asks the same practical question: "Even if I agree with the architecture, doesn't building our first Knowledge Graph require a six-month database migration, a cross-team security audit, and an enterprise ontology committee?"

The short answer is no. If your engineering team already knows how to write JSON and publish a website, you already have every tool and skill required to stand up a production Knowledge Graph in a couple of weeks—without touching a single internal IT system or breaking a single existing REST endpoint.

Rather than walking through a hypothetical tutorial, this installment examines a real production deployment I built for Evidence Action—a global nonprofit organization delivering health interventions across Africa and Asia. In just two weeks, using nothing more than plain JSON-LD files on disk and standard open vocabularies, we stood up a 4,850-triple Knowledge Graph (live visual explorer and public SPARQL endpoint), connected their third-party hiring platform into the graph without vendor support, and made the entire organization natively queryable by both deterministic code and LLM agents.

01. Start With What You Already Publish: The Zero-IT-Friction Wedge

When engineering teams try to launch an internal Knowledge Graph initiative, they almost always make the mistake of starting with their most sensitive, most coupled internal databases: production billing tables, customer PII in Salesforce, or internal ERP ledgers. Before a single triple is written, the project is bogged down in data-access approvals, schema-freeze negotiations, and ETL pipeline tickets.

When I began building the Knowledge Graph for Evidence Action, I started at the exact opposite end of the spectrum: what is simultaneously the most valuable and the easiest data in the entire organization?

Not just for Evidence Action, but for almost any company, the answer is the public core of the organization. Think about the facts every business already puts on its public website:

• Organizational Structure & Footprint: Where the headquarters and regional offices are based, how subsidiaries and technical partners relate to the parent entity, and which countries or markets each unit serves.
• Core Offerings & Programs: The products, services, or interventions the organization delivers, how they are categorized, and which stage of maturity each offering is in.
• Leadership, Board & Domain Expertise: The executives, directors, advisors, and researchers leading the organization, along with their roles and verified academic or professional credentials.
• Ecosystem Partners & Funders: The institutional partners, evaluators, universities, and backers connected to the organization's work.

Starting with your public organizational core gives you three structural advantages right out of the gate:

1. Zero Security or IT Friction: Every fact on your public website has already been vetted by legal, communications, and leadership for public release. You do not need a security review or database credentials to model facts you have already told the world in HTML.
2. It Inevitably Forms the Center of Your Graph: Even when you later connect private internal databases or third-party SaaS tools, those records need canonical organizational units, geographies, products, and people to attach to. Your public core is the central skeleton of the enterprise.
3. It Is Just a Format Translation (HTML → JSON-LD): For Evidence Action, building the initial graph did not require inventing new data. It meant looking at the pages already published on their website and expressing those exact same facts as structured JSON-LD files on disk.

"Wait—Isn't JSON-LD on a Website Just SEO Markup?"

If your engineering or growth team has encountered JSON-LD before, they probably saw it inside a <script type="application/ld+json"> tag used for Google Search rich snippets. Because of that, it is easy for a technical leader to glance at a JSON-LD snippet and think, "Oh, that's just SEO stuff."

That reaction misses the bigger picture. Think about why your company publishes HTML web pages and links out to other websites with <a href="..."> tags: you do it so humans can understand who you are, how your products work, and how you connect to the rest of the world. Publishing a Knowledge Graph in JSON-LD is doing the exact same thing, except you are publishing a structured representation of your organization for machines.

Search engine optimization is an immediate dividend of publishing JSON-LD, not its ceiling. Once those canonical machine-readable entities exist, they become the integration hubs that let third-party SaaS feeds snap into your data model and allow AI agents to query your organization natively in natural language—without touching a single internal IT system until you choose to.

02. Demystifying JSON-LD: Upgrading Everyday JSON With @context, @id, and @type

In Section 03 of Part 2, we introduced JSON-LD (JSON for Linked Data) alongside N-Triples and Turtle, and promised to unpack the three special keys prefixed with an @ sign: @context, @id, and @type.

Let's look at a concrete example from the Evidence Action project. Evidence Action operates in India through a regional technical partner based in New Delhi called EAII Advisors. If a typical web developer were writing a plain JSON file or REST API response to describe EAII Advisors, they would write something like this:

{
  "id": "eaii-india",
  "name": "EAII Advisors",
  "legalName": "EAII Advisors Pty Ltd",
  "foundingDate": "2020",
  "description": "India technical partner",
  "parentOrg": "evidence-action",
  "office": {
    "id": "eaii-office",
    "streetAddress": "Tower C, Max House, Okhla Industrial Estate Phase 3 Rd, Bahapur",
    "city": "New Delhi",
    "region": "Delhi",
    "postalCode": "110-020",
    "country": "India"
  }
}

To a human developer who wrote the application, that JSON looks clean. To any machine outside that single codebase, it is an isolated silo of strings:

• Local String Identifiers: What is "eaii-india" or "evidence-action"? If your hiring platform or finance system has its own record for the India office, there is no global identifier allowing a machine to know they refer to the same real-world organization.
• Implicit, Undocumented Keys: Does "parentOrg" mean legal corporate ownership, fiscal sponsorship, or a department hierarchy? Does "country": "India" join with "country_code": "IN" in another microservice?

Now look at how we upgraded that exact JSON object into W3C JSON-LD for the Evidence Action Knowledge Graph using standard Schema.org terms:

{
  "@context": "https://schema.org/",
  "@id": "https://rdf.evidenceaction.org/graphs/core/eaii-india",
  "@type": ["NGO", "Organization"],
  "name": "EAII Advisors",
  "legalName": "EAII Advisors Pty Ltd",
  "foundingDate": "2020",
  "description": "India technical partner",
  "parentOrganization": {
    "@id": "https://rdf.evidenceaction.org/graphs/core/evidence-action",
    "@type": ["NGO", "Organization"],
    "name": "Evidence Action"
  },
  "address": {
    "@id": "https://rdf.evidenceaction.org/graphs/places/eaii-office",
    "@type": "PostalAddress",
    "streetAddress": "Tower C, Max House, Okhla Industrial Estate Phase 3 Rd, Bahapur",
    "addressLocality": "New Delhi",
    "addressRegion": "Delhi",
    "postalCode": "110-020",
    "addressCountry": {
      "@id": "https://rdf.evidenceaction.org/graphs/places/india",
      "@type": "Country",
      "name": "India"
    }
  }
}

Notice how little changed syntactically—it is still 100% valid JSON—yet adding those three keywords completely transforms what a machine can do with the payload:

1. @context (The Shared Dictionary): Setting "@context": "https://schema.org/" tells any JSON-LD processor that short property names like "name", "legalName", "parentOrganization", and "address" are shorthand for the global Web IRIs https://schema.org/name, https://schema.org/parentOrganization, and so on. Your developers keep writing clean, readable JSON keys without typing full URLs on every line.
2. @id (The Global Primary Key): Instead of a local string like "eaii-india", "@id": "https://rdf.evidenceaction.org/graphs/core/eaii-india" assigns a globally unique Web identifier to EAII Advisors. Notice that the nested objects—the parent organization (.../core/evidence-action), the physical office address (.../places/eaii-office), and the country (.../places/india)—also have their own @id URLs. Whenever any other file or application references one of those @id URLs, the graph automatically merges the facts together.
3. @type (The Entity Classification): Declaring "@type": ["NGO", "Organization"] (or "PostalAddress" and "Country") tells the graph—and any AI agent—what kind of real-world thing each node is, independent of which file or database table it came from.

Why Existing JSON.parse() Clients Never Break

One of the biggest fears engineering managers have when hearing "RDF" or "Knowledge Graph" is that their frontend TypeScript apps or mobile clients will have to learn a new parser. With JSON-LD, that fear disappears:

• To a standard JavaScript client running const org = JSON.parse(response), org.name is still "EAII Advisors", org.parentOrganization.name is still "Evidence Action", and org.address.addressLocality is still "New Delhi". The @context, @id, and @type keys are just ordinary JSON properties that legacy code can ignore or read as strings.
• To an RDF graph database (such as Oxigraph) or a JSON-LD processor, that exact same payload unrolls into 18 deterministic Subject – Predicate – Object triples that join across the entire enterprise graph.

03. What Two Weeks of Plain JSON-LD Files Looks Like: Inside the 4,850-Triple Evidence Action Graph

Once we established that pattern—taking public facts from Evidence Action's website and writing modular JSON-LD files on disk—how long did it take to model the core of a global organization operating across multiple continents?

It took two weeks. We did not buy a six-figure proprietary graph appliance, we did not spin up a complex Kafka streaming topology, and we did not touch a single internal database. We simply organized a directory of JSON-LD files covering Evidence Action's offices, programs, leadership, board members, academic credentials, and partner foundations, and loaded them into an open-source graph store exposed at https://rdf.evidenceaction.org/.

Even in a static snapshot, you can see how the "Strings to Things" principle plays out at organizational scale. Instead of isolated tables or HTML pages, every shared entity becomes a gravitational hub in the network. The table below breaks down the eight color-coded node clusters visible in Figure 1:

A Quick Look Ahead: What Are Those Amber Concept Clusters and External Links?

If you look closely at the upper region of Figure 1 (and Rows 7 and 8 of the table above), you will spot something important beyond standard Schema.org entities:

• Amber / Gold Concept Hubs (focus-area-concepts & program-lifecycle-concepts): While Schema.org covered roughly 80% of Evidence Action's core nouns (organizations, people, addresses, credentials), every enterprise also has domain-specific concepts—such as Evidence Action's six-stage Accelerator pipeline or its thematic focus areas (Clean Water, Maternal and Newborn Health, Neglected Tropical Diseases). We modeled those using the W3C SKOS (Simple Knowledge Organization System) standard and a tiny, four-term RDFS extension so they act as high-value connective tissue across the graph.
• Outbound Bridges to Global Knowledge Graphs: Many of those nodes also carry outbound machine-readable links directly to Wikidata, Google's Knowledge Graph, and the United Nations Sustainable Development Goals (SDGs).

We are intentionally saving the deep dive into how those SKOS taxonomies, surgical RDFS extensions, and external Wikidata / Google / UN bridges work for Part 4 ("Breaking Down Silos: Shared Vocabularies, Taxonomies, and Connecting to Global Knowledge"). Right now, the key takeaway is simpler: once your core Schema.org entities have canonical @id URLs, enriching the graph with new applications becomes strictly additive.

04. Additive SaaS Integration Without Vendor Support: Joining a 3rd-Party Hiring Feed

Once you have a core graph on disk, the next question is: "How do we integrate our day-to-day operational applications when our third-party SaaS vendors don't support RDF or Knowledge Graphs?"

Evidence Action uses Workable as its third-party Applicant Tracking System (ATS) to manage open job requisitions. Out of the box, Workable knows nothing about Evidence Action's Knowledge Graph. In a traditional data architecture, connecting ATS job postings to organizational structure, regional partner entities, and country programs would require modifying a central data warehouse schema and maintaining brittle join tables.

Because our core graph already defined canonical @id IRIs for Evidence Action (.../core/evidence-action), its India partner (.../core/eaii-india), its New Delhi office (.../places/eaii-office), and India (.../places/india), integrating Workable took a tiny JSON-LD wrapper. Here is the exact <script type="application/ld+json"> payload generated for a live role in New Delhi:

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "JobPosting",
  "@id": "https://rdf.evidenceaction.org/graphs/jobs/91DD310DAE",
  "identifier": {
    "@type": "PropertyValue",
    "name": "Workable Shortcode",
    "propertyID": "workable-shortcode",
    "value": "91DD310DAE"
  },
  "title": "(Associate) Director, Expansion, AI Access Initiative (EAII)",
  "description": "Evidence Action is hiring for the Full-time position of (Associate) Director, Expansion, AI Access Initiative (EAII), based in New Delhi, India. This is a Mid-Senior level role.",
  "datePosted": "2026-09-08",
  "url": "https://apply.workable.com/j/91DD310DAE",
  "hiringOrganization": {
    "@type": ["NGO", "Organization"],
    "@id": "https://rdf.evidenceaction.org/graphs/core/evidence-action",
    "name": "Evidence Action",
    "sameAs": "https://www.evidenceaction.org"
  },
  "employmentType": "FULL_TIME",
  "employmentUnit": {
    "@type": ["NGO", "Organization"],
    "@id": "https://rdf.evidenceaction.org/graphs/core/eaii-india",
    "name": "EAII Advisors"
  },
  "experienceRequirements": "Mid-Senior level",
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "@id": "https://rdf.evidenceaction.org/graphs/places/eaii-office",
      "addressLocality": "New Delhi",
      "addressRegion": "Delhi",
      "addressCountry": {
        "@type": "Country",
        "@id": "https://rdf.evidenceaction.org/graphs/places/india",
        "name": "India"
      }
    }
  }
}
</script>

Look at what happens at the graph layer because of four specific lines in that snippet:

• "hiringOrganization": { "@id": "https://rdf.evidenceaction.org/graphs/core/evidence-action" }
• "employmentUnit": { "@id": "https://rdf.evidenceaction.org/graphs/core/eaii-india" }
• "address": { "@id": "https://rdf.evidenceaction.org/graphs/places/eaii-office" }
• "addressCountry": { "@id": "https://rdf.evidenceaction.org/graphs/places/india" }

We did not have to ask Workable to change its product roadmap, and we did not have to run a single migration on the existing Evidence Action graph. Simply by emitting a schema:JobPosting node whose foreign references use the canonical @id URLs from our core graph, every open requisition in New Delhi automatically snaps into the existing network:

1. Immediate Machine & Search Visibility: Search crawlers and job aggregators reading the page get a complete, standards-compliant JobPosting record.
2. Zero-Join Multi-Hop Context: In the graph store, job 91DD310DAE is now one hop away from EAII Advisors, two hops away from the India leadership team (such as Country Director Ankur Garg and his team in New Delhi), and directly connected to the health programs delivered in India (Deworm the World and Equal Vitamin Access).
3. The Exact Blueprint for Any B2B SaaS Stack: Whether you are wrapping a Workable job feed, a Stripe invoice webhook, a HubSpot deal record, or an internal microservice response, the integration pattern is identical: wrap the payload in JSON-LD and point its entity references at your canonical @id IRIs.

05. Standalone Value + AI Leverage: Query the Live Graph Yourself (SPARQL & Agent Prompts)

Throughout this series, we have emphasized a critical architectural truth: Knowledge Graphs work remarkably well with LLMs and AI agents, but they are in no way tied to or dependent on them. A well-modeled Knowledge Graph delivers deterministic value on Day 1 through direct queries, structured publishing, and cross-application integration—and then acts as a zero-hallucination force multiplier when you point an AI agent at it.

You do not have to take my word for it. The Evidence Action Knowledge Graph is live on the public Web. You can inspect its visual topology at https://rdf.evidenceaction.org/, and you can query the live endpoint directly at https://rdf.evidenceaction.org/sparql.

Part A: 3 Deterministic SPARQL Queries You Can Run Right Now

Paste any of the three queries below into https://rdf.evidenceaction.org/sparql (or run them from your terminal via curl) to see how those plain JSON-LD files behave as a unified graph. (Note: As highlighted in Section 02, the live Evidence Action graph uses PREFIX schema: <https://schema.org/>.)

Query 1 — Global Operating Footprint Across Subsidiaries and Partner Offices

This query traverses from the parent organization (.../core/evidence-action) across every child entity linked via schema:parentOrganization, their physical office addresses, and the countries they operate in:

PREFIX schema: <https://schema.org/>

SELECT DISTINCT ?org ?name ?countryName
WHERE {
  ?org schema:parentOrganization <https://rdf.evidenceaction.org/graphs/core/evidence-action> ;
       schema:name ?name ;
       schema:address ?addr .
  ?addr schema:addressCountry ?country .
  ?country schema:alternateName ?countryName .
}
ORDER BY ?name

What it returns: All 7 regional offices and technical partner entities across three continents—EAII Advisors (India), Evidence Action Kenya (Kenya), Evidence Action Liberia (Liberia), Evidence Action Malawi (Malawi), Evidence Action Nigeria (Nigeria), Evidence Action U.S. Office (United States), and Evidence Action Uganda (Uganda).

Query 2 — Multi-Hop Leadership & Verified University Credentials

This query traverses from schema:Person nodes across their schema:EducationalOccupationalCredential nodes to the universities (schema:recognizedBy) that awarded their degrees:

PREFIX schema: <https://schema.org/>

SELECT ?personName ?jobTitle ?degreeName ?universityName
WHERE {
  ?person a schema:Person ;
          schema:name ?personName ;
          schema:hasCredential ?cred .
  OPTIONAL { ?person schema:jobTitle ?jobTitle }
  ?cred schema:name ?degreeName ;
        schema:recognizedBy ?uni .
  ?uni schema:name ?universityName .
}
ORDER BY ?personName
LIMIT 15

What it returns: Verified multi-hop academic lineages across leadership and board members—including Ankur Garg (Executive Vice President and Country Director, India (EAII Advisors) — Master’s degree in Technology Policy, University of Cambridge), Christina Riechers (Head of Product & Engineering — degrees recognized by Harvard University, Massachusetts Institute of Technology, and Stanford University), and Danielle Bayer (Chief Executive Officer — degrees recognized by Stanford Graduate School of Business and Harvard Kennedy School).

Query 3 — Cross-Entity Program & Partner Join for India

This query starts from the canonical geographic node for India (<https://rdf.evidenceaction.org/graphs/places/india>)—the exact same @id referenced by the Workable JobPosting in Section 04—and finds every health program serving India along with the partner organizations delivering it:

PREFIX schema: <https://schema.org/>

SELECT ?programName ?partnerName
WHERE {
  ?program schema:areaServed <https://rdf.evidenceaction.org/graphs/places/india> ;
           schema:name ?programName ;
           schema:provider ?partner .
  ?partner schema:name ?partnerName .
}
ORDER BY ?programName ?partnerName

What it returns: The active health interventions operating in India (Deworm the World and Equal Vitamin Access) paired with their operating providers (EAII Advisors, Evidence Action, Evidence Action Kenya, Evidence Action Malawi, and Evidence Action Nigeria)—illustrating how any external job posting or operational record linked to places/india or core/eaii-india inherits the organization's full programmatic context for free.

Part B: 3 Natural-Language Prompts for Your Favorite LLM Agent

Now test the second half of the equation. If you use an AI coding or research agent with web/HTTP tool access (such as Claude Code, Gemini, Cursor, or a custom MCP agent), hand it any of the three natural-language prompts below and watch how it explores the live graph without hallucinating:

1. Organizational & Geographic Discovery Prompt: "Using the public SPARQL endpoint at https://rdf.evidenceaction.org/sparql (where Schema.org predicates use https://schema.org/), list all regional offices and partner organizations connected to Evidence Action, the countries they operate in, and which health programs are delivered in India."
2. Candidate & Executive Briefing Prompt (Joining the Workable Role Context): "We are hiring an Associate Director in New Delhi for EAII Advisors (https://rdf.evidenceaction.org/graphs/core/eaii-india). Query https://rdf.evidenceaction.org/sparql to assemble a factual candidate briefing on EAII Advisors: its legal name, parent organization, office address, leadership team members associated with India, and the active programs EAII Advisors helps deliver."
3. Institutional & Academic Network Prompt: "Query https://rdf.evidenceaction.org/sparql to map the academic background of Evidence Action's leadership and board: which universities recognize the most credentials across the team, and what doctoral or master's specializations are represented?"

"You do not need a two-year data warehouse overhaul to give your AI agents deterministic memory. A folder of well-modeled JSON-LD files on disk can stand up a production Knowledge Graph in two weeks."

06. Where We Go Next: The 6-Part Series Roadmap

We have now seen how any engineering team can go from zero to a live, queryable Knowledge Graph in weeks by starting with its public organizational core, upgrading everyday JSON into W3C JSON-LD (@context, @id, @type) with Schema.org, and wrapping third-party SaaS feeds like Workable so they snap into canonical @id URLs automatically.

But what happens when off-the-shelf Schema.org terms are not specific enough for your proprietary business concepts—or when Engineering, Product, Marketing, and external datasets each use different terminology for the same domain?

In Part 4: "Breaking Down Silos: Shared Vocabularies, Taxonomies, and Connecting to Global Knowledge," we will zoom directly into those amber concept hubs and external bridges from Figure 1—showing how W3C SKOS concept schemes, lightweight RDFS subclassing, and outbound links to Wikidata, Google's Knowledge Graph, and the United Nations create semantic connective tissue across your organization and the wider Web.