Lemtika: Evidence-First AI Websites

Understand before generating

Most website generators start with a template or a prompt. Lemtika starts with the business itself. A user pastes a Google Maps link. The product reads the public listing, reviews, photos, hours, category, and contact details, then researches what customers consistently value before deciding what the website should say.

The architecture separates research from presentation. Research records the full picture, including criticism and uncertainty. Presentation may use only supported positive and neutral findings. The public website can describe the business clearly without pretending every review was positive, while the owner retains the harder evidence privately.

A zero-prompt product

Users do not write briefs, select templates, or configure publishing. After a quick listing preview and sign-in, the workflow gathers the evidence, curates usable photos, drafts the site, and publishes it. A progress screen tracks the work, and an email delivers the live link if the user leaves.

The system scales the page to the available data. A business with richer evidence can earn a fuller narrative. A sparse listing produces fewer sections. If no usable review evidence exists, the system builds a clean page from verified listing facts and skips unsupported story claims along with the model calls that would create them. Sparse data results in concise content, not placeholder copy or a public error.

The observation ledger

Reviews are too broad and ambiguous to serve as individual units of truth. The research pipeline splits each one into discrete observations: an evaluation, a fact of use, or practical know-how. Every observation retains its source review, verbatim quote, sentiment, and open-ended aspect. Non-English evidence may receive a display translation, but the original remains the verification target.

All downstream work queries this ledger. Code calculates support counts, sentiment balance, freshness, conflicts, and confidence directly from stored observations. Aspects remain open during extraction so a clinic, café, gym, and law office are not forced into the same rigid taxonomy. Clustering consolidates the vocabulary only after the business has supplied it.

Recall first, precision second

One large synthesis prompt looked simpler but missed subtle signals in dense review sets. I replaced it with a propose–curate–verify workflow. Focused proposal calls search locally for possible findings to maximize recall. A global curation pass reviews the candidates with representative evidence, merges duplicates, enforces each insight type, and demotes findings that are true but too thin.

The split turns a vague quality problem into explicit jobs. Proposal optimizes recall. Curation optimizes precision. Mechanical checks validate references and counts. An independent adversarial model judges whether the cited words support the conclusion. A failure re-runs the affected item instead of the entire report.

Models chosen by job

I did not choose one flagship model for the whole product. Extraction, classification, clustering, synthesis, adversarial review, narrative planning, and copywriting have different error costs and context shapes. I evaluated each step with its own candidate set, token budget, reasoning level, concurrency limit, repair policy, and fallback chain.

Candidates were replayed against both straightforward and vocabulary-diverse businesses. I measured observation recall, citation accuracy, invalid outputs, downstream rejection, latency, throttling, and total pipeline cost rather than the advertised price of one call. A cheaper synthesis candidate was rejected after it ran much slower, created substantially more weak candidates, and increased the downstream work. A slightly dearer extraction and validation pairing produced a denser ledger with fewer lost reviews. In those tests, the cheapest call was not the cheapest system.

Fabrication blocked in layers

Preventing fabrication requires layered checks. Code confirms that every quote is present in its source review. Counts are derived from citations rather than written by the model. Full positive, neutral, and negative tallies travel with each claim so one true quote cannot hide the other side. Positive claims are blocked when their aspect is net negative.

Semantic support still requires judgment, so an independent model reviews each surviving insight using only the claim, its evidence, and the complete tally. Website planning may reference only eligible insights and approved media. Copy passes format, digit, and source checks before a page-level reviewer inspects the assembled result. If a field still fails, the product suppresses it or uses a safe listing-based fallback.

The model roster is configuration

Model policy changes faster than the product contract. Lemtika keeps prompts in code because they are coupled to schemas and validators, while model choice and fallback policy live in versioned configuration. A configuration moves from draft to active as one complete set. Every run locks to the version it starts with.

Each attempt records the selected model, upstream provider, outcome, tokens, reported cost, and duration. If cost data is missing, the system records the billed attempt and fails closed. This keeps model changes auditable and reversible without relying on an unversioned environment-variable switch.

Recovery is part of the workflow

Because the pipeline spans data vendors, model providers, object storage, a database, and publishing, every stage is designed for interruption. Raw vendor responses are saved before processing, each stage writes its output before advancing, and idempotent keys let a recovered run continue from stored state. The orchestrator manages scheduling and checkpoints without becoming the only record of an in-flight run.

The same pattern applies after publishing. New reviews can refresh the research and produce proposed website changes, but they never rewrite the live site directly. The owner accepts or dismisses each suggestion. Automation handles the reading and drafting. The person representing the business keeps publishing control.

How I built it

The production system followed the same evidence standard as the product. I started with product laws and real review corpora, built a replayable experiment pipeline, measured alternatives, and only then ported the settled workflow into the application. Features were decomposed into testable slices, implemented test-first, and passed through independent review loops and production smoke tests.

Lemtika is live across the customer app, research and generation services, website renderer, owner controls, billing, localization, operations, and generated public sites. I cannot yet claim that it improves a business's traffic or revenue. What has shipped is the harder prerequisite: a production AI workflow whose public words can be traced back to what real customers said.