Use Cases

Get started

Because CognitivessAI is a plain HTTP + JSON API, it drops into any workflow — a script, a service, a microcontroller, or an existing enterprise pipeline. Below are full, production-shaped examples built only on the /v1/chat/completions endpoint + Structured Outputs (no RAG, no embeddings, no vision needed):

  • Energy — automatic meter reading: validate the index, detect fraud/anomalies, write the customer message.
  • Government / ANAF — invoice processing for eFactura (RO eInvoicing): OCR → extract fields → validate VAT math → classify → flag anomalies → structured JSON for ERP and the ANAF SPV upload.
  • Email / petition triage (primărie, minister, suport) — classify + route + draft reply.
  • Legal — contract review: extract clauses, flag risky ones, risk score.
  • Insurance — claim triage + fraud signal + preliminary payout.
  • Retail — catalog normalization: messy supplier titles → structured attributes.
  • Telecom — outage ticket triage → NOA queue.
  • Finance — transaction categorization + merchant normalization.

The same pattern maps directly to water/gas meters, parking sensors, cold-chain logistics, agriculture soil probes, vending-machine telemetry, eTVA reconciliation, RO eTransport e-AWBs, or receipt-to-expense entry — anything where a raw value/document is captured and you want validation + a human-readable decision.

Automatic Meter Reading (AMR) for an electricity provider
Field devices capture the meter index; Cognitivess-1 cleans the value, computes consumption, flags anomalies (rollback, impossible spike, tamper), and emits a structured record ready for billing + a Romanian customer notification.

What the model actually does

Cognitivess-1 is text-in / text-out — it does not run OCR or read the meter port itself. The raw index is acquired on the device (digital read from a smart meter, or local OCR from a camera). The model is the reasoning layer on top of that raw value:

  • Normalize & validate the index (fix ambiguous digits like 6/0/8 from a dirty OCR, reject obvious garbage).
  • Compute consumption = current index − previous index.
  • Anomaly reasoning: negative delta (meter rollback / tamper), impossible spike (×10 vs history → fraud or misread), index below last month.
  • Classify the reading type and confidence.
  • Generate a short, customer-facing message in Romanian for the monthly notification.
  • Return everything as validated JSON via Structured Outputs — ready to insert into your billing DB.

Architecture

  ┌──────────────────────┐     ┌──────────────────────┐
  │  Smart meter (P1 /   │     │  Legacy analog meter │
  │  Modbus / DLMS)      │     │  + ESP32-CAM / Pi cam│
  │  → digital index     │     │  → local OCR (digits)│
  └──────────┬───────────┘     └──────────┬───────────┘
             │   index (raw)              │  digits (raw, noisy)
             └──────────────┬─────────────┘
                            ▼
                ┌────────────────────────┐
                │  Edge gateway (Pi)     │  cron / systemd every N min
                │  + previous index +    │
                │    customer context    │
                └───────────┬────────────┘
                            │  POST /v1/chat/completions  (response_format: json_schema)
                            ▼
                   ┌──────────────────┐
                   │   Cognitivess-1   │  validate · delta · anomaly · message
                   └─────────┬────────┘
                             │  JSON (validated)
              ┌──────────────┼───────────────┐
              ▼              ▼               ▼
        billing DB      MQTT/Teams      customer SMS/email
        (index, kWh)    (alert on       (Romanian message
                         anomaly)        generated by the model)

Two acquisition paths

# Smart meter exposes the index over P1 (DSMR), Modbus TCP, or DLMS/IEC 62056.
# Here: Modbus TCP holding register holding the cumulative kWh index.
from pymodbus.client import ModbusTcpClient

def read_index():
    mb = ModbusTcpClient("192.168.1.50")
    r = mb.read_holding_registers(0x0200, 2)   # 32-bit counter, 2 regs
    raw = (r.registers[0] << 16) | r.registers[1]
    return str(raw)                          # e.g. "00148203"
# Legacy analog dial meter: ESP32-CAM or Pi cam captures a photo,
# OCR runs locally on the gateway (tesseract / a small vision model). Cognitivess
# then cleans the noisy digit string (e.g. "OO1482O3" -> "00148203").
import subprocess

def read_index():
    subprocess.run(["raspistill", "-o", "/tmp/meter.jpg", "-t", "1"])
    out = subprocess.check_output(["tesseract", "/tmp/meter.jpg", "stdout",
                                   "-c", "tessedit_char_whitelist=0123456789"])
    return out.decode().strip()             # noisy, e.g. "OO1482O3"

The reasoning call (Structured Outputs)

The gateway sends the raw index + context (previous index, last consumption, customer type) and forces a JSON schema back. temperature low for deterministic validation.

import os, json
from openai import OpenAI

client = OpenAI(api_key=os.environ["COG_KEY"], base_url="https://api.cognitivess.com/v1")

SCHEMA = {
  "type": "json_schema",
  "json_schema": {
    "name": "meter_reading",
    "strict": True,
    "schema": {
      "type": "object",
      "properties": {
        "index_clean":      {"type": "string"},   # normalized, digits only
        "index_value":     {"type": "integer"},  # as integer kWh
        "consumption_kwh": {"type": "integer"},  # delta vs previous
        "anomaly":         {"type": "boolean"},
        "anomaly_type":    {"type": "string", "enum": ["none", "rollback", "spike", "below_previous", "ocr_unreadable"]},
        "confidence":      {"type": "number"},    # 0..1
        "customer_message": {"type": "string"},  # ro, ≤ 2 propoziții
      },
      "required": ["index_clean", "index_value", "consumption_kwh", "anomaly", "anomaly_type", "confidence", "customer_message"],
      "additionalProperties": False,
    },
  },
}

def analyze(raw_index, prev_index, last_kwh, customer_type):
    r = client.chat.completions.create(
        model="Cognitivess-1",
        messages=[
            {"role": "system", "content": """Ești motorul de validare al unui sistem AMR pentru o firmă de electricitate.
Curăță indexul brut (corectează confuzii OCR: O→0, I/l→1, S→5), calculează consumul
= index_curent − index_anterior, detectează anomalii (rollback, consum imposibil > 10×
față de istoric, index sub luna trecută, OCR ilizibil). Generează un mesaj scurt în
română pentru client. Răspunde DOAR în schema JSON cerută."""},
            {"role": "user", "content": json.dumps({
                "raw_index": raw_index, "previous_index": prev_index,
                "last_consumption_kwh": last_kwh, "customer_type": customer_type,
            }, ensure_ascii=False)},
        ],
        max_tokens=512,
        temperature=0.1,
        response_format=SCHEMA,
    )
    return json.loads(r.choices[0].message.content)

Schedule + dispatch

Run the gateway on a cron / systemd timer. Persist to billing, raise an alert on anomaly, and push the model's message to the customer channel.

import paho.mqtt.client as mqtt

mqttc = mqtt.Client(); mqttc.connect("mqtt.local", 1883)

def process_meter(meter):
    raw  = read_index()
    res  = analyze(raw, meter["prev_index"], meter["last_kwh"], meter["type"])

    db.execute("INSERT INTO readings VALUES (?,?,?,?,?)",        # billing
               (meter["id"], res["index_value"], res["consumption_kwh"], res["anomaly_type"], res["confidence"]))

    if res["anomaly"]:
        mqttc.publish("grid/anomaly", json.dumps({"meter": meter["id"], **res}))   # → Teams/NOA
    if res["confidence"] >= 0.8:
        send_sms(meter["phone"], res["customer_message"])                 # notify client

# cron entry: */15 * * * * COG_KEY=... /opt/amr/gateway.py

Example model output for a noisy analog read "OO1482O3" with previous index 147910 and last month 320 kWh:

{
  "index_clean": "00148203",
  "index_value": 148203,
  "consumption_kwh": 293,
  "anomaly": false,
  "anomaly_type": "none",
  "confidence": 0.92,
  "customer_message": "Indexul înregistrat pe luna curentă este 00148203, cu un consum de 293 kWh, în limite normale."
}

Same meter but raw "00146999" (below previous) → "anomaly": true, "anomaly_type": "below_previous" and an alert on grid/anomaly — no customer SMS is sent until a technician re-reads.

Why an LLM here (and not just if/else)

  • Noisy OCR on legacy meters isn't a clean rules problem — the model reasons about likely digit confusions given the meter's dial position and history.
  • Anomaly explanation: a hard threshold catches spikes, but the model also writes why in natural language for the NOA/operator ticket, in Romanian, with the right tone for the customer channel.
  • One pipeline, many meter types: analog dial, digital LCD, smart-meter counters — the same prompt + schema adapts, no per-meter regex maintenance.

Feasibility & cost notes

  • Tokens: each call is tiny (prompt ≈ 150 tokens, output ≤ 512). At CognitivessAI pricing, validating 10 000 meters/month costs well under a few USD — see Models.
  • Determinism: temperature=0.1 + strict JSON schema ⇒ the output is parseable every time; guard with a json.loads + schema re-check before writing to billing.
  • Don't gate critical control on the LLM: disconnection / billing issuance stays on your deterministic business rules; the model only validates, classifies, and writes messages.
  • Batch: collect readings on the gateway and send one request per meter — or pack several meters into one call with an array schema to cut round-trips.
  • Edge reliability: cache the last good reading; if CognitivessAI is unreachable, store the raw index and re-run validation when connectivity returns.

Same skeleton — acquire raw value → Cognitivess-1 validates + explains → structured JSON downstream — fits a water utility (leak = spike), a parking operator (plate OCR + dwell-time message), or a cold-chain logger (temp excursion diagnosis). Swap the schema and the system prompt; the device + API plumbing stays identical.

Invoice compliance for ANAF eFactura (RO eInvoicing)
A business or accounting firm receives invoices as PDF scans / email attachments / phone photos. Local OCR turns each into text; Cognitivess-1 extracts the fields, validates the VAT math, classifies the document, flags anomalies, and emits a structured JSON record — the basis for the ERP entry and the ANAF eFactura (SPV, UBL 2.1 / RO_CIUS) upload.

What the model does here

Cognitivess-1 is text-only, so it never opens the PDF — OCR happens locally (Tesseract / pdftoppm). Fed the raw OCR text, the model:

  • Extracts emitent CUI/CIF, beneficiar CUI, serie + număr factură, dată emiterii, data scadenței, baza de impozitare + cota TVA + TVA (per cotă), total factură, IBAN, bancă, monedă.
  • Validates the math: baza × cotă = TVA per linie; Σ(bază + TVA) = total factură.
  • Classifies tip document: factură cu TVA normală, taxare inversă, scutită, chitanță, aviz, storno.
  • Flags anomalies: cotă TVA invalidă (RO: 19 / 9 / 5 / 0), total care nu se potrivește, CUI cu format invalid, lipsă serie/număr, storno fără factură de referință.
  • Returns validated JSON via Structured Outputs — plus o notă umană scurtă în română.

Architecture

  PDF scan / email attachment / photo
                │  (local OCR: tesseract / pdftoppm)
                ▼
         raw text (noisy, mixed layout)
                │  POST /v1/chat/completions   (response_format: json_schema)
                ▼
          ┌─────────────────┐
          │   Cognitivess-1   │  extract · math check · classify · anomaly
          └────────┬────────┘
                   │  JSON (validated)
        ┌──────────┼──────────────┐
        ▼          ▼              ▼
   ERP / contab.  ANAF eFactura   anomaly queue
   (insert)       (SPV, UBL 2.1   (human review:
                  / RO_CIUS XML)  re-scan / corectează
                  doar după       înainte de upload)
                  re-verificare
                  deterministă

1) Local OCR → raw text

# PDF -> imagine -> text. Pentru poze/facturi tipărite, direct tesseract pe imagine.
import subprocess

def ocr_invoice(path):
    if path.endswith(".pdf"):
        subprocess.run(["pdftoppm", "-png", "-r", "300", path, "/tmp/pg"])
        path = "/tmp/pg-1.png"
    txt = subprocess.check_output(["tesseract", path, "stdout", "-l", "ron+eng"])
    return txt.decode()                # text brut, layout variabil, cu erori OCR

2) Extraction + validation (Structured Outputs)

import os, json
from openai import OpenAI

client = OpenAI(api_key=os.environ["COG_KEY"], base_url="https://api.cognitivess.com/v1")

SCHEMA = {
  "type": "json_schema",
  "json_schema": {
    "name": "invoice", "strict": True,
    "schema": {
      "type": "object",
      "properties": {
        "doc_type":   {"type": "string", "enum": ["factura_tva", "taxare_inversa", "scutita", "chitanta", "aviz", "storno", "necunoscut"]},
        "emitent_cui": {"type": "string"},
        "beneficiar_cui": {"type": "string"},
        "serie_numar": {"type": "string"},
        "data_emiterii": {"type": "string"},
        "data_scadentei": {"type": "string"},
        "linii": {"type": "array", "items": {"type": "object", "properties": {
            "baza": {"type": "number"}, "cota_tva": {"type": "number"}, "tva": {"type": "number"}
          }, "required": ["baza", "cota_tva", "tva"], "additionalProperties": False}},
        "total_factura": {"type": "number"},
        "moneda": {"type": "string"},
        "math_ok": {"type": "boolean"},
        "anomaly": {"type": "boolean"},
        "anomaly_type": {"type": "string", "enum": ["none", "cota_invalida", "total_nepotrivit", "cui_invalid", "lipsa_serie", "storno_fara_ref", "ocr_ilizibil"]},
        "note": {"type": "string"},
      },
      "required": ["doc_type", "emitent_cui", "beneficiar_cui", "serie_numar", "data_emiterii", "data_scadentei", "linii", "total_factura", "moneda", "math_ok", "anomaly", "anomaly_type", "note"],
      "additionalProperties": False,
    },
  },
}

def process_invoice(ocr_text):
    r = client.chat.completions.create(
        model="Cognitivess-1",
        messages=[
            {"role": "system", "content": """Extragi datele unei facturi românești din textul OCR (corectează erori: O→0, l/I→1).
Calculezi TVA per linie = baza × cota / 100 și verifici că Σ(baza + TVA) = total_factura.
Cote valide RO: 19, 9, 5, 0. Clasifici tipul documentului. Marchează anomalii. Răspunde
DOAR în schema JSON cerută, fără text suplimentar."""},
            {"role": "user", "content": ocr_text[:8000]},
        ],
        max_tokens=1024, temperature=0.1, response_format=SCHEMA,
    )
    return json.loads(r.choices[0].message.content)

3) Deterministic re-check before ANAF (do not rely on the LLM alone)

Before anything goes to ANAF eFactura, re-verify the numbers with plain code and validate the CUI against ANAF's published control-key formula. The model flags issues; code is the gatekeeper.

def math_check(inv):
    calc = sum(round(l["baza"] * (1 + l["cota_tva"]/100), 2) for l in inv["linii"])
    inv["math_ok"] = abs(calc - inv["total_factura"]) < 0.02
    return inv["math_ok"]

def cui_checksum(cui):
    # Implementează cheia de control publicată de ANAF pentru CUI (fără prefixul RO).
    # Returnează True/False. Nu pune această logică pe seama modelului.
    ...

def route(inv):
    if not (math_check(inv) and cui_checksum(inv["emitent_cui"]) and not inv["anomaly"]):
        return enqueue_review(inv)          # omul reface / re-scanează
    insert_into_erp(inv)
    submit_to_anaf_efactura(to_ubl(inv))   # SPV, UBL 2.1 / RO_CIUS

Example: a smudged scan reads Serie FAC 1O23 · Baza 1.000,00 · TVA 19% · Total 1.190,0 → serie_numar: "FAC1023", math_ok: true, doc_type: "factura_tva", note: "Factură validă, 19% TVA, total 1190.00 RON." A storno without a reference invoice → anomaly_type: "storno_fara_ref" and is held for review, not uploaded.

Feasibility & guardrails

  • Text-only: the model reads OCR text, never the PDF itself. OCR quality is the real ceiling — at 300 DPI with ron+eng it's usually good enough; route low-confidence pages to a human.
  • Never submit to ANAF on LLM output alone: re-compute VAT and validate the CUI with deterministic code; the model proposes, code disposes.
  • Determinism: temperature=0.1 + strict schema ⇒ parseable every time; still wrap json.loads in a try/except and hold failures for review.
  • Volume & cost: one invoice ≈ a few hundred tokens. Processing 10 000 invoices/month is cheap at CognitivessAI pricing — see Models; most cost is actually your OCR step, not the model.
  • Layouts vary wildly between suppliers; the same prompt + schema handles them all — no per-supplier regex, which is the whole reason to use an LLM here instead of templates.
  • Same pattern fits: eTVA split-VAT reconciliation, RO eTransport e-AWB goods descriptions, receipt → expense entry for the virtual cashier (casierie virtuală). Swap the schema and the system prompt; the OCR → model → deterministic-check → submit pipeline is identical.
Email / petition triage (primărie, minister, suport)
A new "shape": free text → classify + route + draft reply — no device, no document. Every inbound email/petition is read by Cognitivess-1, classified, prioritised, routed to a department, and answered with a ready-to-review draft.
  • Classify category (plângere, factură, suport tehnic, vânzare, informație) + intent.
  • Prioritise urgency and route to the right department; flag requires_human.
  • Draft a polite Romanian reply the agent just reviews and sends.
from openai import OpenAI
client = OpenAI(api_key=COG_KEY, base_url="https://api.cognitivess.com/v1")

SCHEMA = {"type": "json_schema", "json_schema": {"name": "triage", "strict": True, "schema": {
  "type": "object",
  "properties": {
    "category": {"type": "string", "enum": ["plangere", "factura", "suport_tehnic", "vanzare", "informatie", "altul"]},
    "intent": {"type": "string"},
    "urgency": {"type": "string", "enum": ["low", "medium", "high"]},
    "department": {"type": "string", "enum": ["relatii_clienti", "facturare", "tehnic", "comercial", "legal"]},
    "confidence": {"type": "number"},
    "requires_human": {"type": "boolean"},
    "draft_reply": {"type": "string"}
  },
  "required": ["category", "intent", "urgency", "department", "confidence", "requires_human", "draft_reply"],
  "additionalProperties": False}}}}

r = client.chat.completions.create(
    model="Cognitivess-1",
    messages=[
        {"role": "system", "content": "Clasifici un email/petiție în română, stabilești urgența și departamentul, și scrii un draft de răspuns politicos (max 3 propoziții). Răspunde DOAR în schema JSON."},
        {"role": "user", "content": email_body[:4000]},
    ],
    max_tokens=512, temperature=0.2, response_format=SCHEMA,
)

Guardrail: never auto-send replies for plângere or high urgency — route those to a human and use draft_reply only as a starting point. The model triages; a human approves outbound communication.

Contract review (clauses + risk flags)
Paste a contract (or OCR it) → Cognitivess-1 extracts the key clauses, flags the risky ones, and returns a structured review record. Same document → JSON shape as the invoice case.
  • Extract parties, term, renewal, jurisdiction, payment terms, termination notice.
  • Flag risky clauses: auto-renewal, excessive penalties, foreign jurisdiction, unlimited liability, exclusivity — each with a risk_reason.
  • Score overall risk_score 0–100 + short summary.
SCHEMA = {"type": "json_schema", "json_schema": {"name": "contract", "strict": True, "schema": {
  "type": "object",
  "properties": {
    "parties": {"type": "array", "items": {"type": "string"}},
    "effective_date": {"type": "string"},
    "term_months": {"type": "integer"},
    "renewal": {"type": "string", "enum": ["auto", "manual", "none"]},
    "jurisdiction": {"type": "string"},
    "currency": {"type": "string"},
    "termination_notice_days": {"type": "integer"},
    "clauses": {"type": "array", "items": {"type": "object", "properties": {
        "name": {"type": "string"}, "summary": {"type": "string"},
        "is_risky": {"type": "boolean"}, "risk_reason": {"type": "string"}
      }, "required": ["name", "summary", "is_risky", "risk_reason"], "additionalProperties": False}},
    "risk_score": {"type": "integer"},
    "summary": {"type": "string"}
  },
  "required": ["parties", "effective_date", "term_months", "renewal", "jurisdiction", "currency", "termination_notice_days", "clauses", "risk_score", "summary"],
  "additionalProperties": False}}}}

# mesaj user = textul contractului (sau OCR-ul lui); max_tokens suficient pt clauze
r = client.chat.completions.create(model="Cognitivess-1",
    messages=[{"role": "system", "content": "Extragi clauzele cheie dintr-un contract în română/engleză și marchezi clauzele riscante (renovare auto, penalități excesive, jurisdicție străină, liability nelimitat, exclusivitate). Răspunde DOAR în schema JSON."},
              {"role": "user", "content": contract_text[:12000]}],
    max_tokens=2048, temperature=0.1, response_format=SCHEMA)

Guardrail: this is decision support, not binding legal advice — re-check dates/amounts deterministically and have a lawyer confirm before acting on a flagged clause. Long contracts may need chunking (split by section, merge results).

Insurance claim triage + fraud signal
Free-text claim description → Cognitivess-1 extracts the facts, surfaces fraud signals, and proposes next steps and a preliminary payout. The underwriter keeps the final decision.
  • Extract claim type, incident date/location, facts, injuries, estimated damage, police report presence.
  • Fraud signals: inconsistencies, large amount with no proof, stale incident, duplicate-looking facts → fraud_likelihood.
  • Propose next steps + a preliminary recommended_payout (or null if it needs investigation).
SCHEMA = {"type": "json_schema", "json_schema": {"name": "claim", "strict": True, "schema": {
  "type": "object", "properties": {
    "claim_type": {"type": "string", "enum": ["auto", "locuinta", "viata", "sanatate", "travel", "altul"]},
    "incident_date": {"type": "string"}, "location": {"type": "string"},
    "facts": {"type": "array", "items": {"type": "string"}},
    "injuries": {"type": "boolean"},
    "has_police_report": {"type": "boolean"},
    "estimated_damage_amount": {"type": "number"},
    "fraud_signals": {"type": "array", "items": {"type": "string", "enum": ["inconsistent_facts", "large_amount_no_proof", "stale_incident", "possible_duplicate", "none"]}},
    "fraud_likelihood": {"type": "string", "enum": ["low", "medium", "high"]},
    "recommended_payout": {"type": ["number", "null"]},
    "next_steps": {"type": "array", "items": {"type": "string"}},
    "note": {"type": "string"}
  },
  "required": ["claim_type", "incident_date", "location", "facts", "injuries", "has_police_report", "estimated_damage_amount", "fraud_signals", "fraud_likelihood", "recommended_payout", "next_steps", "note"],
  "additionalProperties": False}}}}

# user content = descrierea daunei (text liber) + eventual istoricul politei

Guardrail: the final payout is set by the underwriter + your policy rules, never by the model. recommended_payout is a triage hint; route fraud_likelihood: high claims to the investigations team automatically.

Retail catalog normalization (messy supplier titles → structured)
Supplier feeds give you garbage titles like SmrtPHN X15 Pro 256GB Blck 6.7". Cognitivess-1 cleans them into structured, filterable attributes — cheaply, across thousands of SKUs.
  • Normalize brand, model, clean name, category, and a free-form attributes object (size, color, capacity, voltage…).
  • Batch: send N titles in one call with an array schema → N structured results, cutting round-trips.
  • Flag ambiguities ("Blck" = black) and low-confidence rows for human review.
# Batch: o lista de titluri murdare -> o lista de produse structurate
titles = ["SmrtPHN X15 Pro 256GB Blck 6.7\"", "Tshirt M barbtsc rosu bumbac", "Bormashina 18V 2Ah fara acumulator"]

SCHEMA = {"type": "json_schema", "json_schema": {"name": "catalog", "strict": True, "schema": {
  "type": "object", "properties": {
    "items": {"type": "array", "items": {"type": "object", "properties": {
        "brand": {"type": "string"}, "model": {"type": "string"},
        "name_clean": {"type": "string"}, "category": {"type": "string"},
        "attributes": {"type": "object", "additionalProperties": {"type": "string"}},
        "confidence": {"type": "number"},
        "ambiguities": {"type": "array", "items": {"type": "string"}}
      }, "required": ["brand", "model", "name_clean", "category", "attributes", "confidence", "ambiguities"],
      "additionalProperties": False}}
  }, "required": ["items"], "additionalProperties": False}}}}

r = client.chat.completions.create(model="Cognitivess-1",
    messages=[{"role": "system", "content": "Curăți titluri de produse murdare de la furnizori în atribute structurate (corectează typos: Blck→Black, barbtsc→bărbați). Răspunde DOAR în schema JSON cu un item per titlu, în ordine."},
              {"role": "user", "content": "\n".join(titles)}],
    max_tokens=2048, temperature=0.1, response_format=SCHEMA)

Feasibility: a few tokens per SKU; thousands of SKUs cost very little (see Models). Enforce a known category whitelist deterministically after the model returns; route confidence < 0.7 rows to a human curate queue.

Telecom ops — outage ticket triage
Customer reports come in as free text (chat, SMS, app). Cognitivess-1 triages each into an outage suspect, affected area, likely cause, and a suggested action — feeding your NOA queue.
  • Detect whether it's a network outage vs a single-customer issue; estimate the affected area.
  • Suggest a likely cause and action; escalate true for severity high; draft a customer-facing update.
  • De-duplicate against an open ticket id if recognisable.
SCHEMA = {"type": "json_schema", "json_schema": {"name": "telecom_triage", "strict": True, "schema": {
  "type": "object", "properties": {
    "issue_type": {"type": "string", "enum": ["pana_retea", "semnal", "facturare", "echipament", "portabilitate", "altul"]},
    "outage_suspected": {"type": "boolean"},
    "affected_area": {"type": "string"},
    "severity": {"type": "string", "enum": ["low", "medium", "high"]},
    "likely_cause": {"type": "string"},
    "duplicate_of": {"type": ["string", "null"]},
    "suggested_action": {"type": "string"},
    "escalate": {"type": "boolean"},
    "customer_message": {"type": "string"}
  },
  "required": ["issue_type", "outage_suspected", "affected_area", "severity", "likely_cause", "duplicate_of", "suggested_action", "escalate", "customer_message"],
  "additionalProperties": False}}}}

# user content = raportul liber al clientului; pasezi si lista id tichete deschise pt deduplicare

Guardrail: don't auto-execute field actions (dispatch, mass-SMS) on model output — use it to rank/cluster the NOA queue and draft the public update. Correlate outage_suspected with real network telemetry before declaring an incident.

Finance — transaction categorization + merchant normalization
Bank/POS descriptions are noisy (POS*ALX SRL BUC 23.05 14:32). Cognitivess-1 normalizes the merchant and categorizes the transaction in bulk — feeding your accounting and spend-analytics.
  • Normalize merchant name + map to a category whitelist (groceries, utilities, travel, salary, fees…).
  • Detect recurring/subscription patterns for spend insights.
  • Batch many transactions in one call (array in → array out).
# tx = [{"id":..,"raw":"POS*ALX SRL BUC 23.05","amount":-123.4,"date":"2026-05-23"}, ...]
SCHEMA = {"type": "json_schema", "json_schema": {"name": "tx", "strict": True, "schema": {
  "type": "object", "properties": {
    "items": {"type": "array", "items": {"type": "object", "properties": {
        "id": {"type": "string"},
        "merchant_clean": {"type": "string"},
        "category": {"type": "string", "enum": ["groceries", "utilities", "travel", "salary", "fees", "entertainment", "other"]},
        "is_recurring": {"type": "boolean"},
        "likely_subscription": {"type": "boolean"},
        "confidence": {"type": "number"}
      }, "required": ["id", "merchant_clean", "category", "is_recurring", "likely_subscription", "confidence"],
      "additionalProperties": False}}
  }, "required": ["items"], "additionalProperties": False}}}}

r = client.chat.completions.create(model="Cognitivess-1",
    messages=[{"role": "system", "content": "Normalizezi descrierea bancară a comerciantului și categorizezi tranzacția. Un item per tranzacție, în ordine, păstrând id-ul. Răspunde DOAR în schema JSON."},
              {"role": "user", "content": json.dumps(tx, ensure_ascii=False)}],
    max_tokens=2048, temperature=0.1, response_format=SCHEMA)

Feasibility: feed data comes from your banking/ERP export (CSV/JSON), not a device. Final accounting categorization is confirmed by your chart-of-accounts rules; the model just normalizes the messy text and proposes categories. is_recurring is a hint — confirm by grouping over time deterministically.

Common shape

Every case above is the same pipeline on top of /v1/chat/completions + Structured Outputs:

raw input (sensor | OCR | free text | DB/CSV export)
        │  POST /v1/chat/completions   { response_format: json_schema, temperature: 0.1, strict: true }
        ▼
   Cognitivess-1  →  extract / classify / validate / reason / draft text
        │  validated JSON
        ▼
 deterministic re-check + business rules  →  ERP / DB / ANAF / NOA queue / customer channel
        │
  human-in-the-loop for anything high-stakes or low-confidence

Swap the JSON schema and the system prompt per domain; the transport, determinism guardrails, and cost profile stay identical. That's the whole point — one text model, many regulated and operational workflows, no RAG/embeddings/vision required.