Independent research

1. Papers

These are full manuscripts, not one-page project summaries. Each includes the method, limitations, references, and a downloadable PDF. The current PDFs are eight or nine pages long.

1. WP-01 · v0.2

   Tenant-Scoped Long-Term Memory in Conversational Agents: Architecture, Threat Model, and an Executable Evaluation Protocol

   Persistent memory changes the unit of failure in a conversational agent. Forgetting is visible; recalling another tenant's fact can look plausible while violating the boundary that makes the service trustworthy. The system examined here combines thread state, vector memory, and graph-grounded documentary retrieval. It defines four invariants: writes and reads must remain tenant scoped, responses must exclude facts owned by another tenant, and deletion must remove every retrievable trace. A checked-in runner maps those invariants to six probes. It creates two synthetic tenants, writes mutually exclusive facts, scores required and forbidden lexical evidence, and reports accuracy and latency against declared targets. The artifact establishes the protocol. It does not contain a versioned live run, so it cannot establish that the deployed runtime meets those targets. The result is an executable threat model and a plan for the missing experiments: paraphrase, contradiction, updates, delayed recall, deletion, and retrieval-layer ablation. Recall quality is not evidence of isolation: the right fact must appear, and the wrong tenant's fact must not.

   Research question

   Can a multi-tenant conversational agent recover durable user facts without exposing facts from another tenant, and can that claim be tested with an inspectable protocol?

   Evidence grade

   Grade P — protocol evidence, not an outcome claim

   Traceable facts

   Artifact: 2 tenants · 6 probes · 3 fact types · Decision rule: 6/6 correct and p95 ≤ 700 ms · Evidence boundary: No public live-run result · Source: Private revision 1470f8f17163

   Read full manuscript → · Download PDF ↓

2. TR-01 · v0.2

   Failure-Focused LLM-as-a-Judge Evaluation for a Transactional Conversational Agent: A 46-Case Repository Study

   An aggregate score can hide the defect that matters. In a saved 46-case run for a transactional restaurant assistant, 40 cases pass at a threshold of 75/100 and the mean score is 80. Yet all five payment cases fail; only one failure appears elsewhere. That concentration localizes the symptom at the payment boundary, though the artifact cannot prove which branch or persistence layer caused it. This report reconstructs the model-judge harness and audits what its scores can support. Cases labelled as security or resilience checks are only sent to the chatbot and judged for conversational plausibility; they never exercise the HTTP, rate-limit, retry, or circuit-breaker behavior named by the cases. The checked-in battery also contains cases absent from the saved output, and the result has no human calibration, repeated seeds, or independent end-to-end rerun. A partial local check on 4 August 2026 confirmed 79 assertions, but Vitest retained open handles and did not terminate cleanly. The saved scores are therefore treated as repository observations, not ground truth. A defensible next version would use deterministic assertions for state and security, reserve model review for open-ended dialogue, and calibrate that review against blinded human ratings.

   Research question

   Can a category-based model judge expose actionable failure clusters in a multi-turn transactional agent, and what must be added before its scores are reliable evidence?

   Evidence grade

   Grade R — repository result, not independently rerun end to end

   Traceable facts

   Saved run: 40/46 pass · mean 80/100 · Failure cluster: 5 payment · 1 FAQ · Runtime: 671.3 s · 28,010 judge tokens · Local check: 79 assertions passed; process hung

   Read full manuscript → · Download PDF ↓

3. RP-01 · v0.2

   Provenance-Constrained Multi-Stage LLM Extraction from Heterogeneous Product Catalogs: System Design and Benchmark Protocol

   Schema-valid JSON says nothing about whether a product came from the right row. A catalog parser can omit an item, merge two records, or attach a plausible price to the wrong source while satisfying every field type. The inspected pipeline separates document metadata, source-row reconstruction, and product normalization. Its final stage works in ten-row batches and must return the expected batch identity, row set, and page coverage before any product is persisted. Deterministic gates reject invalid provenance and defer ambiguous or non-normalizable output for review. At the recorded public revision, the complete local suite passed 569 tests across 20 files in 1.06 seconds. Those tests support the encoded validators and application behavior. They do not measure extraction accuracy. A separate performance file uses an in-memory array and provides no basis for claims about Convex, provider calls, or end-to-end throughput. The inspected artifacts contain no labelled corpus, single-pass baseline, raw prediction set, or accuracy result. What remains is a paired benchmark against a pinned single-pass condition on the same documents, reporting row recovery, field accuracy, source attribution, review burden, latency, and cost.

   Research question

   Does separating document understanding, source-row reconstruction, and product normalization improve reliability over a single-pass extraction prompt?

   Evidence grade

   Grade S/P — reproduced software evidence plus an unexecuted research protocol

   Traceable facts

   Local suite: 569/569 tests · 20 files · Duration: 1.06 s under Node 24.14.0 · Pipeline: 3 stages · 10-row batches · Accuracy: Not measured on a labelled corpus

   Read full manuscript → · Download PDF ↓

2. Evidence taxonomy

Code can show that a system exists. By itself, it cannot show that a research claim is true. The grades below state what each artifact supports.

3. Publication standard

A paper is ready for submission only when another person can inspect the question, environment, comparison, metrics, raw outputs, and failure conditions. The source data must be versioned and the reproduction path must work from a clean checkout. Before submission, I also want technical review by someone outside the project. Failed tests and unfinished experiments remain in the paper.

4. Authorship and tool disclosure

Language models assisted with software development, repository analysis, and editing. I chose the systems and source material, made the experimental decisions, checked the interpretations, and remain responsible for corrections and public claims. Owning a repository does not make me the author of someone else's contribution.