Use cases

flinq earns its place by moving a metric a buyer already tracks. This page maps each endpoint to the outcome it produces and the KPI that proves it, so you can tell quickly whether flinq fits a problem you have. Each case links to a runnable recipe in Examples.

LV to catalog matching

The core case in European tendering, shown here in its German form. A free-form bidding line in a bill of quantities (a Leistungsverzeichnis in Germany, a DPGF in France, a Computo Metrico in Italy) has to be matched against a neutral standard catalog (in Germany the Standardleistungsbuch) or a manufacturer’s products. Today this is done by hand, line by line, against catalogs.

• Endpoint: /v1/extract to parse the tender, then /v1/rerank as the matcher; for larger pools, /v1/search in hybrid mode keeps exact codes honest. The recipe shows the extract plus rerank shape.
• Outcome: type a line item in your own words and get the matching catalog entry or product in seconds instead of paging through catalogs.
• KPI: top-1 and top-5 match accuracy. The hybrid lexical leg keeps exact codes and units (DN 100, C25/30, XC4) honest so the right line lands at the top.

Runnable recipe: LV matching.

Retrieval-augmented generation (RAG)

Ground a generator in your own construction documents instead of letting it invent answers. flinq retrieves the relevant long-form position details; a generator writes the grounded answer from that context alone.

• Endpoint: /v1/embeddings or /v1/chunk to index the corpus, your own vector store plus /v1/rerank to retrieve at query time; /v1/search covers the stateless case. The recipe shows the pgvector shape.
• Outcome: answers grounded in your specifications and bidding texts, in your working language, with no hallucinated line items.
• KPI: recall@k, the share of questions whose supporting passage is in the retrieved top-k. Retrieval quality caps everything downstream, so this is the number to watch.

flinq and the generator are both OpenAI-compatible, so the whole pipeline is one SDK and two base_urls. Runnable recipe: RAG over construction data.

Cost prediction

Use embeddings as features. A short building description becomes a flinq vector, and a small regressor maps that vector to a cost in euros per square meter of gross floor area. No feature engineering and no schema: the embedding already carries the domain semantics.

• Endpoint: /v1/embeddings as the feature extractor for a downstream model.
• Outcome: an early-stage cost estimate from a plain-language description, with no manual feature pipeline.
• KPI: MAE (mean absolute error in EUR/m²) and Spearman rank correlation against ground-truth costs. This is the BauSatz cost-regression task.

Runnable recipe: Early-phase cost prediction.