Pharma intelligence, connected.

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

• Sites. Manufacturing facilities tracked across regions and authorities.
• Inspection findings. Observations, 483s, and warning letters tied to sites.
• 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.

Each entity included relevant metadata, and every connection had provenance tracking and confidence weighting. We used GPT-4o to identify potential relationships, LangChain to process and chunk lengthy documents, and Neo4j for graph storage and traversal. I collaborated with the engineering team on schema design and worked on the user experience to help people explore these relationships without feeling overwhelmed.

# 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)

Average outbound links per node, by source type. Dense interconnections were the goal — sparse graphs surface nothing.

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

Most of Redica’s users aren’t searching for PDFs. They’re trying to answer questions.

• 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 used the graph context and source text to give a useful answer, with references. No magic. Just fast access to information that mattered.

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 now has a clear, scoped summary that regulatory teams can scan quickly. If the original language wasn’t English, we translated it. If it lacked metadata, we filled it in with topic and geography. We gave users a reason to open the 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 identify meaningful connections that weren’t apparent through keyword matching alone. For example, an FDA observation about inadequate process control could be linked to EMA guidance on aseptic processing. They covered similar regulatory themes but used different terminology. Traditional search might miss these connections, but the model could identify the conceptual relationships.

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, linked documents, and guidance. Then it assembles a briefing that’s actually readable. Structured. Reviewable. Editable.

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
Site         → Topic        → Document          // 85%
Manufacturer → Enforcement  → Topic             // 70%
Topic        → Guidance     → Regulator         // 60%

We limited default traversal depth for common queries and precomputed relationship paths for the most used node types. Redis handled caching. This kept UX responsive without oversimplifying the graph.

We had regulatory experts from top pharma companies on staff. They reviewed relationships directly. If a link didn’t hold up, it was removed. We didn’t pad counts or chase novelty. The graph had to reflect reality.

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.