Introduction

Modern AI engineering often treats the large language model as both brain and interface, a combination that introduces non-determinism, hallucinations, and unpredictable schema drift. Isolyne Part 4 flips this assumption by positioning the LLM as a sensory organ rather than the core decision-maker.

What Happened

Isolyne was designed with a strict architectural rule: the LLM handles only one task-converting unstructured developer chat into a typed JSON object. Using Gemini 1.5 Flash for its sub-400ms latency and native structured output, the system restricts the model to extraction alone, leaving business logic, database writes, and conflict resolution to the deterministic CQRS kernel.

The extraction boundary is enforced through a single API call with a fixed temperature of 0.1 and a rigid JSON schema. This constrains the model's output to syntactically valid JSON, which is then validated inside the application to catch any semantic mismatches.

To prevent topic fragmentation, recent team topics are injected into the prompt context. If Alice mentions Postgres and Bob mentions MongoDB, the model reuses the established Database key, allowing the downstream set-theory detector to flag the conflict instantly.

Casual or non-technical messages are handled by instructing the model to return UNKNOWN for both fields. The parser detects this and returns null, ensuring noise-free timelines.

Network reliability is addressed with a lightweight fetchWithRetry wrapper featuring exponential backoff and timeout abortion, ensuring stable API calls even on unreliable mobile or conference networks.

Why This Matters

By scoping the LLM to clean extraction, Isolyne turns messy conversation into high-value, structured data. Every extracted topic choice pair is logged alongside the raw user input, enabling verbatim signal tracing and structured export as architectural decision records (ADRs).

This structured data fuels Isolyne Pro features via RevenueCat, including expanded radar card insights and clean Markdown ADRs ready for GitHub or Jira. The approach also ensures that when API quotas are exhausted or connectivity drops, the system can gracefully degrade, as explored in Part 5.

Key Takeaways

  • The LLM operates as a sensory organ, limited to extraction and confined by a strict JSON schema.
  • Topic normalization prevents fragmentation by reusing established domain keys across concurrent decisions.
  • Non-decisions and banter are filtered out via UNKNOWN returns, keeping timelines clean.
  • Exponential-backoff networking ensures reliable extraction even on unstable connections.
  • Structured extraction directly powers Pro monetization features like signal tracing and ADR exports.

Conclusion

Isolyne Part 4 demonstrates that constraining an LLM to a single, well-defined extraction task—backed by native structured output and schema enforcement-yields deterministic, hallucination-resistant results. The pattern enables clean architectural decision tracking, supports premium data-preservation features, and sets the stage for offline-capable extensions in Part 5.