Claude Vision API calls for PDF page description returned empty strings with no error. The API returned HTTP 200 (success) but the text content was blank. Entire inscription pages were silently skipped during ingestion.

Claude's extended thinking (adaptive reasoning) consumes tokens internally before emitting any text. With the default max_tokens = 4096, the model exhausted the entire budget on internal reasoning and had zero tokens left to produce the description. No exception was raised — the call silently succeeded with empty output.

Set max_tokens ≥ 32,000 in all Vision API calls — giving extended thinking enough budget while still leaving the majority for actual output. Now a documented invariant in CLAUDE.md.

Without this fix, every image-heavy page — including stone inscription photographs — would have been ingested as empty chunks. The failure was completely invisible at ingest time; it would only have been discovered later when queries returned no results for known topics.

The most important primary sources — Epigraphia Indica, South Indian Inscriptions, Minakshi's Pallava dynasty study — are all legacy PDFs mixing Tamil and English. Without this fix, the knowledge base would have been built almost entirely from English secondary sources, severely undermining its scholarly value.

Pallava king names, temple names, and epigraphical terms are almost all IAST-transliterated Sanskrit or Tamil (Narasimhavarman, maṇḍapa, vimāna). An export system that cannot render these is useless for academic or stakeholder presentations.

Language models are trained to produce fluent, complete text. When presented with fragments containing gaps ([...], ***), the model's probability distribution strongly favours filling them with contextually plausible content — exactly what a scholar must not do.

Resolution: Extended the RAG answerer prompt with an explicit lacunose instruction — "Do NOT reconstruct or speculate about missing content. State: [uncertain — inscription damaged]." Also added grounding validation that flags invented Pallava king names or dates absent from the retrieved chunks.

In epigraphy, a fabricated reconstruction of a damaged king's name or regnal date can propagate as fact through secondary literature for decades. This is an AI safety problem specific to the humanities — the stakes of hallucination are historical record integrity, not just user inconvenience.

The Pallava Grantha script (6th–7th century CE) has no standardised Unicode block. Existing Grantha Unicode (U+11300) partially covers it, but many Pallava-specific glyph variants are absent from any standard. Without a stable encoding, characters cannot be stored, searched, or compared digitally.

Without this pipeline, Pallava inscriptions could only be stored as images (unsearchable) or as approximate IAST text (losing glyph distinctiveness). The five-layer system is the scholarly infrastructure that makes the entire knowledge base viable as a research tool. The Layer 2 PUA encoding has been submitted as part of a Unicode standardisation proposal.

The symptom was "Connection error" from Agent J — pointing to network issues. Only by tracing the process tree with Windows WMIC and inspecting each child process's own environment (not the start command) was it discovered that the API key was present in the start command string but never actually set in the child process environment.

Root cause: cmd /k "cd /d "c:\...\pallava-translator" && set ANTHROPIC_API_KEY=..." — the nested double-quotes cause cmd.exe to terminate the quoted string at the first inner ", never reaching the set command.

Once a file is committed to git, it lives in the pack objects permanently — even if you later add it to .gitignore and run git rm --cached. The working tree entry is removed, but every clone and push still transfers the full blob history.

git filter-branch rewrote history but left orphaned objects; garbage collection had not run yet, so pushes still transferred 8 GiB.

Final fix: Deleted the entire .git directory, ran git init, staged only the 165 code files, and pushed a fresh single-commit history. 1.87 MiB. The PNG files remain on disk — they are regenerated on demand during ingestion and have no place in version control.

Before LFS: EC2 deployment required manually copying 241 MB of ChromaDB files via scp after cloning — a fragile, error-prone step. After LFS: git clone fetches everything automatically. The app is fully operational immediately after clone, with no manual file transfers for the vector store.

The History Agent is intended to be public-facing eventually. A user could craft a malicious ingestion source (prompt injection via a poisoned PDF or URL) that instructs the History Agent to perform actions on their behalf. If the History Agent could directly call the Personal Agent — which has Gmail access — a prompt injection attack could silently send emails.

The hub-and-spoke topology means the History Agent has no code path to reach Gmail. Even if fully compromised, it cannot reach the Personal Agent's tools. The security boundary is enforced at the import level, not just by configuration.