DEV Community: Kaan Demir

A timeout is an unknown outcome: handling live AI acknowledgements

Kaan Demir — Tue, 27 Oct 2026 09:00:00 +0000

When an external service does not answer, retrying can feel like the obvious recovery step. But a missing acknowledgement does not prove that the service failed to act. If the action generates paid live video, sending it again can produce another effect while the first one is still in progress.

Inscribi Director’s public bridge makes that uncertainty explicit. An audience vote on Monad testnet determines a direction for a live video. The server records the direction; the stage browser owns the provider connection and reports what happens next. The implementation is useful to study because it separates several events that a single completed flag could obscure.

Separate the facts you can observe

Finalizing a vote establishes which option won. It does not establish that the video provider accepted the new prompt, produced a matching chunk or presented that chunk on the audience’s display.

The bridge records the round, selected option, prompt and increasing prompt version together. A direction is saved in a waiting state before it becomes available to the stage. Processing the same round again returns its existing entry. While an earlier direction remains unresolved, the bridge does not create the next one.

Observation	State recorded	What it establishes
A round result arrives	A persisted waiting direction	The application has a direction to send
Provider reports `prompt_applied`	Applied	The provider acknowledged that version
Provider reports rejection	Rejected	That direction is no longer pending
A matching chunk is reported	First-chunk timing; applied if previously waiting	Output for that prompt version was reported
No reply arrives	Still waiting	The outcome remains uncertain
Operator abandons the direction	Abandoned	The application may deliberately continue

Keeping work identity separate from delivery attempts is the transferable part. A repeated notification about a round should not quietly become a new command with a new identity.

Preserve uncertainty instead of hiding it in a retry

The bridge does not automatically resend a direction after a missing acknowledgement. This favors avoiding a duplicate generation command, at the cost of sometimes requiring operator intervention. The operator can abandon a waiting direction so the show can continue.

Applied, rejected and abandoned entries are terminal for acknowledgement handling. A late response does not rewrite a final decision. A stale prompt-version error is treated as rejection. These rules make the result of delayed messages easier to reason about than a generic “try again” button.

This is application-level duplicate handling. It is not proof of absolute exactly-once execution across the server, browser and provider. Abandoning an entry also does not prove that a remote effect was cancelled; it records how the local workflow will proceed.

A matching chunk offers another piece of evidence. The stage reports its prompt version, playback duration and buffer depth. If the corresponding entry is still waiting, that report can settle it as applied. The bridge records when the chunk is expected to start after the existing buffer has played.

That timestamp is derived from browser reports, not a measurement that a person watched the screen. A later chunk does not move the recorded first-chunk presentation time. Separating provider acceptance from playback timing keeps the user interface from promising a visible result too early.

The reviewed test source covers duplicate rounds, late replies and presentation timing. Those test definitions are evidence of the intended contract; this article does not claim a newly completed live-event rehearsal.

Give session recovery its own rules

The session manager addresses a different boundary: who owns the active stage session and when a paid session may be opened. It tracks the stage owner, provider-session claim, attempts, duration and budget. Heartbeats make the disappearance of the stage browser an explicit event.

On restart, a persisted live session becomes interrupted instead of automatically opening another paid session. Recovering stored state and resuming external activity are separate decisions. A file that says “live” is insufficient evidence that the provider connection still exists or that starting again is financially equivalent.

The price constants in the repository are implementation assumptions at that revision. They are not current provider pricing, and a locally recorded end is not a final invoice. A new integration still needs to reconcile its lifecycle with the provider’s actual stop behavior and billing.

For a similar integration, define these four things before implementing retries:

A stable identity for work that can be observed more than once.
The record persisted before the external action becomes available.
An explicit state for an outcome that cannot yet be established.
The actor and evidence allowed to resolve that state.

Then exercise lost replies, late replies, browser loss and process restart as distinct cases. The useful property is that uncertainty has a name in the implementation and an understandable consequence in the operator workflow.

Sources and original version

AI disclosure: This article was drafted by an AI agent from the linked source code. It does not report firsthand event observations, current provider prices or a new live-system benchmark.

A CLIP score of 0.85 is not 85% listing accuracy

Kaan Demir — Tue, 20 Oct 2026 09:00:00 +0000

A number named confidence_score can look more authoritative than the experiment behind it. In a marketplace filter, a high image-text similarity score does not prove that the seller is honest, that an appliance works or that the photographed item is available.

Eşya Bul’s public verifier provides a concrete example. It compares a listing image with a small set of descriptions using CLIP, then keeps the listing if the best positive score exceeds 0.85. Reading the code helps separate a useful visual filtering operation from a much broader trust claim.

Identify the actual question

The inspected revision loads openai/clip-vit-base-patch32. It builds candidate product groups from an existing category tag and title keywords. For a refrigerator, the positive description is a photograph of a refrigerator; alternatives include parts, repair services and a broken fridge.

For each candidate group, the code sends the image and descriptions to the model, applies softmax to the image logits and takes the score of the first, positive description. If more than one group is considered, it keeps the group with the highest positive score. The retained result includes that group and the score.

The narrow question is: which of these supplied descriptions best matches this photograph? That can help remove a replacement handle from a search for a complete refrigerator. It cannot establish ownership, working condition, delivery reliability or payment safety. Those require different evidence.

Category selection matters too. An inaccurate title or tag can make the model compare the image against the wrong alternatives. There is no general-purpose verification step hiding behind the word “verified” in the output filename.

Keep the denominator in view

Softmax normalizes a set of logits into shares that sum to one. The denominator depends on the candidates included in that particular comparison. Add a strong alternative and the positive candidate’s share can fall even when its own logit stays unchanged.

Here is a self-contained illustration:

from math import exp

def positive_share(logits):
    top = max(logits)
    weights = [exp(value - top) for value in logits]
    return weights[0] / sum(weights)

print(round(positive_share([4, 1, 0]), 3))     # 0.936
print(round(positive_share([4, 1, 0, 4]), 3))  # 0.484

These are invented logits for an arithmetic demonstration, not model outputs or a benchmark. The example shows why a threshold cannot be interpreted without its candidate design. It does not show how accurate CLIP is on refrigerator listings.

There is another comparison to handle carefully: the verifier selects the highest positive score across product groups with different alternatives. Each score was normalized within its own group. A larger number in one group is not automatically a calibrated probability comparable to every other group.

OpenAI’s model card discusses sensitivity to category design and the need to evaluate a model in its intended context. Fine-grained distinctions and non-English use also have limitations. In this implementation, Turkish title keywords select groups, while the CLIP descriptions are English. Those two stages deserve separate error analysis.

Evaluate the decision the product actually needs

Start with a label definition small enough for humans to apply consistently. “The image shows a complete refrigerator rather than a replacement part” is much more testable than “this is a safe listing.”

Outcome	Example	Why it needs a separate label
Visual match	A complete appliance	Find useful listings rejected by the filter
Visual mismatch	A handle or repair advertisement	Find unwanted listings accepted by the filter
Ambiguous	A collage containing an appliance and loose parts	Preserve uncertainty rather than force a clean label
Technical failure	An image cannot be downloaded	Separate network failures from model decisions

The current script skips missing images, failed downloads and rejected classifications before writing its final list. A shorter output list therefore cannot establish better filtering. Add explicit outcome reasons before interpreting the disappearance of an item as model success.

For an evaluation, keep near-duplicate photographs from the same listing on one side of the development/evaluation split. Record disagreements between human reviewers. Compare false accepts and false rejects at several thresholds, broken down by product group. Freeze the candidate descriptions for each reported run so that another person can reproduce the comparison.

The appropriate threshold depends on the next action. A shortlist reviewed by a person may tolerate more false accepts to avoid hiding useful items. A decision that triggers an automated action can have a different error cost. No threshold is justified merely because its decimal representation resembles a familiar percentage.

The defensible claim supported by this code is preliminary filtering for visual category consistency. This article does not report a new benchmark or establish a reliable fraud detector.

Sources and original version

AI disclosure: This article was drafted by an AI agent from the linked code and documentation. The softmax example is illustrative; no new model evaluation was performed for this article.

A bilingual site needs a route model, not just a language switch

Kaan Demir — Thu, 15 Oct 2026 22:21:59 +0000

A language switch changes what a visitor sees. A route model decides what a visitor can share, where navigation leads and which language is present in the HTML before browser code runs.

For a small bilingual site, these decisions can live in one explicit mapping. The current kaahn.com implementation uses separate Turkish and English addresses and generates readable HTML for each. The useful engineering lesson is the relationship between content identity, language and URL. This is an implementation case study, not evidence of a ranking increase.

Give each page a stable identity

Consider an About page. Its Turkish address is /hakkimda/; its English address is /en/about/. Those are two language versions of the same subject. Switching from the English About page should lead to the Turkish About page, rather than restarting at the Turkish home page.

The same relationship is useful in navigation, breadcrumbs and a sitemap. Copying paths independently into each template makes it easy to update one place and leave an old address somewhere else. A shared mapping makes the relationship inspectable:

pages = {
    "about": {"tr": "/hakkimda/", "en": "/en/about/"},
    "projects": {"tr": "/projeler/", "en": "/en/projects/"},
}

seen = set()
for page, languages in pages.items():
    assert set(languages) == {"tr", "en"}, page
    for language, path in languages.items():
        assert path.startswith("/") and path.endswith("/"), path
        assert path not in seen, f"Duplicate route: {path}"
        seen.add(path)

assert pages["about"]["tr"] == "/hakkimda/"

This simplified example validates route shape, language coverage and collisions. It does not validate the translation itself. A publishing check still needs to confirm that the English page actually contains English prose, including its title, description and navigation labels.

The site’s production build extracts the shared header and footer, selects a page body, applies the corresponding translations and writes an HTML file at each address. Browser JavaScript can add interaction afterwards. The main heading and body do not depend on a language toggle running successfully.

Google describes crawling, rendering and indexing as distinct stages for JavaScript pages. Preparing stable content at build time makes the published file straightforward to inspect. It does not imply that every client-rendered application is unsuitable for search, or that replacing a framework guarantees better results.

Model two different relationships

A canonical URL identifies the preferred address for a page. A language alternative identifies another language version. Treating these as the same relationship creates confusing metadata.

For this site, the English About page has an English self-canonical. Both language versions declare the same Turkish and English alternatives. The Turkish page is the default-language alternative. A shortened example of the English page’s metadata is:

<link rel="canonical" href="https://kaahn.com/en/about/">
<link rel="alternate" hreflang="tr" href="https://kaahn.com/hakkimda/">
<link rel="alternate" hreflang="en" href="https://kaahn.com/en/about/">
<link rel="alternate" hreflang="x-default" href="https://kaahn.com/hakkimda/">

Google’s localized-versions guidance calls for reciprocal relationships. Inspecting only the English file is therefore insufficient. The Turkish file must identify both versions too, and every target should resolve to the intended page.

This also explains why a language switch should use the current page identity. Guessing an English address by adding /en/ would fail for translated slugs such as hakkimda and about. The mapping already knows the correct pair.

Treat publication as a contract

A successful generator run proves only that files were produced. The server must serve those files at their public addresses, and the relationships between them must remain correct.

Check	Expected result	Failure it exposes
Inspect the initial HTML	Heading, body and navigation are present	Content exists only in browser state
Open both language versions	Each points to both alternatives	A missing or mismatched language pair
Follow internal links	Final URLs preserve the intended language	Lost context or unnecessary redirects
Compare sitemap and published routes	Only published canonical addresses appear	Draft or obsolete addresses exposed

For scheduled content, the sitemap and navigation should use the same publication decision as the page generator. Otherwise a future article can leak into a sitemap before its page exists, or appear as a link that leads to a missing page.

The design fits a small portfolio with relatively stable content. Concurrent editing, per-user pages and updates that must appear within seconds introduce different requirements. Those requirements may justify a CMS or runtime rendering. Establishing page identity and language first makes that later change easier to reason about.

Sources and original version

AI disclosure: This article was drafted by an AI agent from the site’s implementation and the linked documentation. It does not report a search-ranking experiment.