Independent venture · In development

YazarIS

Every order starts with a conversation.

An AI-assisted order assistant turning Turkish B2B messages into catalog-validated drafts, with human confirmation at the center.

Follow the order
Illustrated YazarIS supplier order desk with a Turkish business message and catalog-validated wholesale order draft.
Illustrated concept screen with fictional wholesaler data. It shows a proposed operator interface, not a live product screen.

TÜBİTAK BiGG / BİGGNITE

First stage passed.

A founder-reported accelerator milestone, recorded in the project documentation. It is not an investment or funding decision.

The problem

Natural language.
Operational consequences.

Wholesale orders arrive as shorthand, corrections and references to earlier messages. A plausible interpretation is not enough: the product, quantity and unit must match the business catalog.

The initial product direction is packaging and cleaning wholesalers in Kahramanmaraş: an operator pastes a message, reviews the draft and remains in control.

The engineering story

Understand.
Validate.
Confirm.

An understandable decision at every step.

  1. 01

    Intent before inference

    Distinguish a new order from a correction, cancellation or price question. Earlier context must never turn a cancellation into a fresh order.

    create_order · modify_order
    cancel_order · ask_price
  2. 02

    The catalog is the boundary

    Resolve products against the catalog and validate allowed units and quantities. Unclear requests become review or clarification states rather than silent guesses.

    draft → needs_review
    → needs_clarification
  3. 03

    One confirmation. An audit trail.

    The implemented SQLite store encrypts draft payloads and protects creation and confirmation against concurrent retries. Confirmation and its audit event share a transaction.

    SQLite · AES-GCM
    idempotency · audit

My role

Product intent.
Engineering discipline.

Founder & developer

My work connects the product scope with the underlying order contracts, catalog resolution, evaluation datasets and persistent draft lifecycle.

A key decision is to measure whether a draft is safe to accept, not merely whether a model returns valid JSON. The project records rejected model candidates and keeps synthetic, human and operational evidence separate.

Python 3.11+FastAPIPydanticSQLiteAES-GCMpytestRuffmypy

Evidence, with context

Designed to be checked.

640

Fictional catalog SKUs

60,000

Programmatically generated examples

69

Human-origin messages in an internal evaluation set

These describe development datasets, not customers, live orders or production accuracy. Historical resolver scores do not establish the quality of the current version.

Where the project stands

Built today

  • Typed order contracts, intent handling and catalog validation.
  • Encrypted draft storage, idempotent creation and transactional confirmation.
  • FastAPI boundaries and reproducible evaluation infrastructure.

Next product milestones

  • Complete decimal quantity handling in free text and model output.
  • Build the business API, operator interface and reviewed CSV/XLSX export.
  • Validate usefulness with real businesses before making adoption or production claims.

Private source. Clear scope.

This case study was checked against the private repository on 12 September 2026. The product is in development; a public demo and automatic ERP submission are not available.