Case Study: Cronus Initiative Review

This case study shows how Second Opinion helped identify blind spots in a new initiative before any code was written.

Context

Cronus is a genealogical database platform built on Neo4j. The initiative was set up with:

• 4 epics (Core DB, FamilySearch Integration, Testing, Documentation)
• 19 tickets for MVP
• Technical stack decided (Neo4j + Python/FastAPI)
• Schema designed (Person, Event, Place, Source nodes)

Before starting implementation, we ran a Second Opinion challenge review.

The Request

{
  "context": "Building a genealogical database called Cronus. Requirements: store family relationship data, complex graph queries (ancestors, descendants, common ancestors), GEDCOM import/export, future FamilySearch.org API integration, Hancock authentication, reusable as generic graph relationship engine.",

  "proposal": "Technical Stack: Neo4j Community Edition, Python + FastAPI, Jetta SSO + Hancock, python-gedcom library. Schema: Person/Event/Place/Source nodes with PARENT_OF/CHILD_OF/SPOUSE_OF relationships. Constraints: API-first, schema separation, 70% test coverage. Build order: DNS, Neo4j, schema, API scaffold, auth, CRUD, queries, GEDCOM, deploy.",

  "mode": "challenge"
}

What It Found

Critical Security Issues

Issue	Why It Matters
Multi-tenant isolation	Neo4j Community lacks row-level security - users could access other users' family data
No encryption at rest	Family history data is sensitive
GEDCOM sanitization	Imported files could contain malicious content
No rate limiting	Complex graph queries could DOS the system

Performance Gaps

Issue	Recommendation
Bidirectional edges double storage	Consider single direction with query adaptation
No caching strategy	Add Redis for frequent ancestry lookups
No pagination	Large result sets will timeout
GEDCOM imports can be massive	Need chunking/streaming

Data Integrity Missing

• No validation rules for dates, names, relationships
• No duplicate person detection/merging strategy
• No soft delete vs hard delete decision
• No handling of uncertain/incomplete data (common in genealogy)

Edge Cases Not Covered

Edge Case	Notes
Same-sex marriages	Relationship model must support
Adoption, step-relationships	Multiple relationship types per edge
Cultural naming conventions	Patronymics, matronymics
Privacy for living persons	Common genealogy requirement
Pedigree collapse	Circular relationships from cousin marriages

Dependency Risk

"python-gedcom library hasn't been updated in years - risky dependency"

This was a blind spot. We recommended the library without checking its maintenance status.

The Decision

Instead of blocking the MVP, we:

1. Acknowledged the findings - All valid concerns
2. Prioritized for Phase 2 - Created a Hardening epic with 10 tickets
3. Identified MVP blockers - Tenant isolation is critical, others can wait

Phase 2 Hardening Epic Created

Priority	Ticket
Critical	Multi-tenant data isolation
High	Input validation & GEDCOM sanitization
High	Rate limiting
High	Neo4j backup strategy
Normal	Monitoring & observability
Normal	Living person privacy rules
Normal	Redis caching
Normal	Audit python-gedcom dependency
Normal	Duplicate person detection/merging
Low	Audit logging

Key Insights

1. Pre-implementation review is valuable

Running Second Opinion before writing code surfaced issues that would have been expensive to fix later. Tenant isolation in particular would require significant rework if discovered post-MVP.

2. Domain expertise matters

The tool identified genealogy-specific concerns (pedigree collapse, living person privacy) that a general architecture review might miss. The challenge mode actively looks for domain edge cases.

3. Dependency auditing

We recommended python-gedcom based on functionality, not maintenance status. The Second Opinion flagged this as a risk worth investigating.

4. Not everything blocks MVP

The review found ~25 issues. Instead of analysis paralysis, we:

• Created tickets for tracking
• Prioritized by criticality
• Proceeded with awareness

Outcome

Initiative now has 5 epics instead of 4:

1. Core DB & API (MVP - ready)
2. FamilySearch Integration (blocked on API approval)
3. Testing & QA (backlog)
4. Documentation (backlog)
5. Hardening & Security (Phase 2) - 10 tickets from this review

The Second Opinion tool paid for itself by identifying tenant isolation as a critical concern before any code was written.

Try It Yourself

Before starting your next initiative, run:

mcpammer_second_opinion(
  context="[what you're building and why]",
  proposal="[your technical approach]",
  mode="challenge"
)

Create tickets from the findings. You'll thank yourself later.

Related

• Second Opinion Tools - Full tool documentation
• Cronus Overview - The project this reviewed
• Initiatives - How initiatives are structured