Pharma intelligence, connected.

We began by identifying the core entities that regulatory teams care about:

• Sites. Manufacturing facilities tracked across regions and authorities.
• Inspections. Authority visits to a site, with dates and outcomes.
• Findings. Observations, 483s, and warning letters tied to an inspection.
• Documents. Guidance, Q&As, draft rules, technical notes.
• Regulatory topics. Data integrity, sterility, CAPA, supply chain, etc.
• Regulatory bodies. FDA, EMA, Health Canada, PMDA, MHRA, ANVISA.
• Manufacturers. Sponsors and CDMOs operating the sites.
• Enforcement actions. Import alerts, consent decrees, debarments.

I owned the data model. Working from the questions customers brought us, I defined the core entities, the metadata each one carried, and the relationships worth storing, then iterated the schema with engineering and data science until it held up under real queries. Every connection carried provenance and a confidence weight. Engineering built the pipeline around it. GPT-4o proposed relationships, LangChain processed and chunked documents, Neo4j stored and traversed the graph. I worked on the user experience of exploring it.

Rendered in Cypher-style notation and trimmed to entities and relationships; the full property set is longer. Engineering’s guidance shaped what stayed in, mostly around what would hold up at query time.

# Cypher-style sketch — illustrative, not full schema

(:Site {id, name, country, manufacturer_id})
(:Inspection {id, date, authority, site_id})
(:Finding {id, severity, topic_id, citation})
(:Document {id, type, title, language, authority, published})
(:Topic {id, slug, label})
(:Authority {code, name, region})
(:Manufacturer {id, name, parent_id})
(:Enforcement {id, type, date, severity})

// relationships
(Site)-[:OPERATED_BY]->(Manufacturer)
(Inspection)-[:AT]->(Site)
(Finding)-[:FROM]->(Inspection)
(Finding)-[:CONCERNS]->(Topic)
(Document)-[:ISSUED_BY]->(Authority)
(Document)-[:COVERS]->(Topic)
(Document)-[:RELATED_TO {confidence, source}]->(Document)
(Enforcement)-[:AGAINST]->(Manufacturer)
(Enforcement)-[:CITES]->(Document)

• GPT-4o. Relationship extraction, summarization, translation.
• LangChain. Document processing and chunking.
• Neo4j. Graph storage and traversal.
• Redis. Caching for traversal-heavy queries.

Redica’s users show up with questions like these:

• What was the root cause in this 483?
• How does this compare to similar findings across sites?
• What does current EMA guidance say about this issue?

We added chat to any node in the graph. You could open an inspection or guidance doc and ask a real question. The model answered from the graph context and the source text, with references back to the documents it used.

A lot of documents in Redica had no summaries. Many weren’t in English. That slowed everything down. We used GPT-4o to fix both.

Every document that came through the pipeline got a clear, scoped summary that regulatory teams could scan quickly. If the original language wasn’t English, we translated it. If metadata was missing, we filled in topic and geography. The point was to give users a reason to open a document instead of skipping it.

Regulatory documents often have genuine relationships that aren’t obvious from their titles or surface content.

We used GPT-4o to propose connections that keyword matching missed. An FDA observation about inadequate process control could relate to EMA guidance on aseptic processing, which covers the same regulatory ground in different vocabulary. I built the review loop that decided which proposals survived. SMEs reviewed candidate links directly, and when a whole class of link didn’t hold up, we stopped shipping that type instead of picking off links one at a time.

These connections appeared as “related guidance” or “related inspections” in the interface, providing users with relevant context without requiring them to know specific search terms.

Customers spend hours compiling reports before audits or internal reviews. They pull citations manually, summarize findings, and guess what context to include. We built a tool that does most of that for them.

You enter a site or manufacturer. It pulls in relevant inspections, observations, enforcement actions, and linked guidance, then assembles a structured draft briefing the team can review, edit, and send.

It doesn’t replace judgment. It just saves the team from doing the same work over and over.

{
  "site_id": "SITE_8421",
  "manufacturer": "Acme Pharma (CDMO)",
  "window": "last_24_months",
  "summary": "Two FDA inspections, one EU GMP cert.
              Recurring theme: data integrity in QC labs.",
  "events": [
    { "type": "FDA_483",  "date": "2024-03-12",
      "topics": ["data_integrity", "audit_trails"],
      "severity": "high" },
    { "type": "EMA_NCR",  "date": "2023-11-04",
      "topics": ["aseptic_processing"],
      "severity": "medium" }
  ],
  "linked_guidance": [
    "FDA 21 CFR 211 audit trails",
    "EMA Annex 1 aseptic processing (2023)"
  ],
  "open_questions": [
    "Has CAPA closed observations from 2024-03-12?",
    "Are similar topics flagged at sister sites?"
  ]
}

Multiplier on observation rate within a 90-day window after publication.

73% of documents reference multiple jurisdictions — surfacing harmonization signals and ICH alignment patterns that single-authority search would miss.

Counted by inbound + outbound edges per topic node.

# Most-used traversal shapes (illustrative, approximate shares, read as undirected) Site → Topic → Document // 85% Manufacturer → Enforcement → Topic // 70% Topic → Document → Authority // 60%

Latency was one of the three metrics I set for the product, alongside recall of relevant nodes and user task completion. Queries had to feel interactive or the graph wouldn’t get used. The engineering team hit that target by limiting default traversal depth on common queries, precomputing paths for the most-used node types, and caching with Redis.

We had regulatory experts from top pharma companies on staff, and they reviewed relationships directly. When a link type didn’t hold up in review, it came out of the graph. I preferred a smaller graph that held up in review over a bigger one that didn’t.

We also built feedback tools into the product. Early on, we weighted input from a trusted group of power users. They knew the space and gave direct, actionable feedback. It helped us catch weak connections and keep the signal clean.

Plugging the graph into dynamic monitoring. Trigger alerts when new documents strengthen risk signals for a known site. We already started work on query-driven workflows and narrative explanations on top of the graph engine.