World architecture
Each world owns its own layout, navigation, palette, and source posture, while shared guide data keeps orientation and next-step links consistent.
Work / Case study
garovartabedian.com — a self-funded research platform
I fund and maintain this passion project myself; it was not commissioned by a client. It is a live research platform: eight connected worlds, generated source data, source provenance, visual systems, and a shipping workflow that leaves the work verified, committed, pushed, and clean.
What it proves
- SurfaceEight connected research worlds: Scriptures, Jesus, The Apostles, The Writings, Church, Angels & Demons, Who Owns the Word?, and How We Know — plus the tools and source trail that make them usable.
- Core stackNext.js App Router, React, TypeScript, static JSON data, generated sitemap, and Vercel deployment.
- Data shapePublic-domain scripture texts, canon metadata, cross-references, search shards, Nave topics, early writings, church road data, and source records live as inspectable structured files.
- Proof standardNo traffic, revenue, adoption, or public-source claims. The visible proof is the live site, the source trail, the route behavior, and the verification record.
Architecture
The site is built as a product surface, not a pile of pages. The worlds have their own visual systems, but the durable behavior lives in shared data, typed route components, and common navigation/source primitives.
Static-first delivery
Research content is served from generated JSON and App Router pages so the site remains fast, crawlable, and deployable without a database.
Client islands where needed
Interactive readers, maps, timelines, ladders, search, and visual systems load client-side only where the user experience needs them.
SEO and discovery
Metadata, JSON-LD, canonical routes, robots, and sitemap entries expose the worlds, case studies, source page, canon shelves, and hosted early texts.
Data and generation
The Scripture world is the clearest example: source files are processed into static JSON, then the reader, search, topics, and canon shelves use that generated shape. The same pattern carries through the other worlds with smaller domain datasets.
- Scripture pipelineA Node pipeline downloads source files under their recorded licenses, normalizes book codes, emits verse JSON, cross-references, search shards, canon data, and a source manifest.
- Topic indexNave's Topical Bible is parsed into topic JSON, then references and internal topic links are checked before they become reader links.
- Content boundariesModern copyrighted translations are discussed in the ownership room but not hosted as scripture text.
- Static loadersShared JSON loaders cache fetches by path, so client rooms can load their data without duplicating fetch/cache behavior.
Computational Research & AI Dossier Suite
To demonstrate what happens when deep domain scholarship meets modern data engineering, the platform features five production-grade research engines — including one-click dossier generation optimized for Google NotebookLM™ and enterprise LLMs.
Universal NotebookLM Dossier Engine
Generates structured, multi-source Markdown research worksheets with YAML frontmatter, named source notes, and thematic prompts for Google NotebookLM source ingestion and Audio Overviews.
The Living Digital Hexapla
A parallel textual alignment engine synchronizing named Hebrew or Greek editions with Brenton, Douay-Rheims, King James, and World English Bible translations, with zero runtime database dependencies.
Computational Catena Aurea
A dense commentary graph linking scripture verses directly to patristic and classical witnesses, parsed into structured static JSON.
Diachronic Semantic Evolution
Interactive tracking of lexical drift and conceptual shifts across millennia of textual history, tracing how root meanings evolved through cultural eras.
Polyphonic Disputation Engine
A structured dialectical debate model rendering classical theological disputes as navigable argument-rebuttal trees with cited historical positions.
From Ancient Manuscripts to Enterprise Knowledge
The technical challenges of classical scholarship — multilingual variants, dense commentary graphs, and multi-era provenance — mirror the exact friction modern companies face when preparing internal knowledge for AI.
- Solving the 'Garbage In, Garbage Out' barrierGoogle NotebookLM and enterprise LLMs can produce errors when source material is messy or incomplete. The pipeline patterns developed here for ancient multilingual texts translate to corporate data: OCR cleanup, structured chunking, provenance notes, and reviewable dossier synthesis.
- Complex multi-source reconciliationJust as ancient polyglots align contradictory variants across Hebrew, Greek, and Latin, enterprise operations require reconciling disparate data models across ERPs, CRM tickets, SOP manuals, and vendor contracts.
- Audit-grade provenance and claim localityThe research worksheets name their hosted editions and cited works, label editorial notes, and ask readers to verify interpretive claims against the cited source before reuse.
- Zero-dependency static architecturesComplex knowledge systems do not always require brittle, expensive vector databases. High-density, pre-compiled static indexes deliver instant, serverless, and recruiter-safe reliability.
Credibility layer
The latest source pass made the trust model explicit. Readers can land on a human source page, see how each room handles evidence, and still find exact source links beside individual claims.
Source registry
A shared source-guidance module powers the human /sources page and the compact source-basis blocks on high-claim pages.
Claim locality
The pages keep links near the claims they support: rights-holder pages, public-domain translations, court records, artifacts, primary texts, and hosted scripture refs.
Wayfinding
World guides tell readers what kind of sources each room uses before they scroll into the detailed records.
Shipping discipline
The build process matters because this site is meant to be maintained by agents as well as by me. A completed pass is not complete until the checks pass, browser behavior is sane where UI changed, the work is committed, pushed, and the tree is clean.
- Required checksSource changes run lint, TypeScript, and production build before shipping.
- Route/UI checksVisual route changes get a local dev-server browser pass for content, source links, framework overlays, console/page errors, and mobile overflow.
- Git disciplineCompleted passes are staged deliberately, committed with a scoped message, pushed to the upstream branch, and checked for a clean worktree.
Truth boundaries
- BoundaryI fund and maintain this passion project myself; it was not commissioned by a client.
- BoundaryThe repository is private, so this case study does not present a public source-code link.
- BoundaryThe site is a live product artifact, not evidence of traffic, revenue, customers, or adoption.
- BoundaryHosted Scripture uses public-domain translations and attributed original-language editions under their recorded licenses; copyrighted modern translations are analyzed but not reproduced as hosted Scripture.
- BoundaryGenerated imagery and visual systems support the experience, but factual claims must still sit beside source links.
Where to look
Start with the live worlds if you want the research experience. Open the source trail if you want the evidence model. If your organization has a workflow, information system, or interface problem with similar complexity, start with how I work.