DEV Community: Victor Laybats

How a flight alert app decides a fare drop is real: trimmed medians, score gates and append-only snapshots

Victor Laybats — Tue, 27 Oct 2026 00:01:13 +0000

This article was created with the help of AI.

Originally published on flareflights.com. Last substantive review of the source page: 9 August 2026.

Flare is a flight alert app I build at IVRYN. Its public deal pages are generated from scan output, so we wrote down exactly which gates a fare must pass before it is shown, what the reference price is, and what the figures cannot prove. Here is that method.

Short answer

Flare is a fare-monitoring and discovery product. The public pages contain timestamped observations selected from the latest scan output. They are not a booking engine, travel agency quote or promise that a seat remains available.

How a fare enters the public collection

The upstream scanner combines fare candidates available to the product from multiple airline and flight-search data feeds. For the public collection, the generator applies the same explicit minimum gates to every candidate:

both the current amount and its comparison reference must be positive;
the measured drop must be at least 30%;
the Flare Deal Score must be at least 55;
a destination page enters with 7 distinct combinations and can remain during a 14-day grace window with 5 current combinations.
a departure-city page must contain at least 12 observations across 10 active destination pages.

The Deal Score is a prioritisation signal, not an external rating. It weighs the size and confidence of the deviation alongside itinerary characteristics such as stops, duration and trip shape. It does not make a fare “verified” merely by being high.

What “reference price” means

Where sufficient route history exists, the comparison value is based on a median of observed baseline prices. The scoring engine trims the outer 10% of those observations before taking the median, and it requires a minimum history before allowing the comparison to imply a large drop.

For some long-haul routes with limited history, the upstream engine can use a conservative distance-calibrated reference. That fallback carries lower confidence and cannot by itself qualify a fare for the system’s reserved mistake-fare band. A Flare reference is therefore a product measurement, not a universal market average or a price published by every airline.

Freshness and verification

The public deal collection is scheduled to rebuild every three hours. Each page prints its own UTC snapshot time. Some promising candidates can receive an additional live recheck upstream, but coverage varies and a public page does not claim that every row has the same verification status.

Airfares are volatile. Inventory, currency conversion, point of sale, passenger count, taxes and optional services can alter the final amount. A result can disappear between the page refresh and the reader’s search.

City and airport consolidation

Destination and departure pages group airport or metropolitan codes only when the city name and country match in Flare’s airport reference. Every fare card still prints the exact IATA codes used by its itinerary. Consolidation prevents near-duplicate city pages; it does not imply that two airports have the same access time, fees or practical value.

Row-level provenance

Each downloadable row records the source market and the UTC timestamp exposed by the upstream batch that contained the candidate, together with the later UTC publication time. This is batch-level provenance. The source payload does not expose a reliable provider identity for every row, so Flare does not publish or infer one. A source batch time must not be read as a provider quote time or a live verification time.

Versioning and reproducibility

Every published dataset is copied into a timestamped archive directory. Archive files are append-only: the generator refuses to replace a file with different bytes at an existing version URL. A SHA-256 checksum manifest lets a reader verify downloaded JSON, CSV, field definitions and citation text. The version index links every retained snapshot.

Measured answers from this dataset

Reuse rights

IVRYN grants reuse only for the Flare-authored compilation elements it owns. Underlying fare facts, feed rights, provider material, airline names and third-party database rights are not relicensed. Read the exact scope on the data reuse page and consult the machine-readable field dictionary.

How to use the information

Read the IATA codes, dates, trip type and stop count shown on the card.
Run a fresh search and compare the complete itinerary with the observation.
Confirm baggage, airport changes, self-transfers, cancellation rules and the final payable total.
Check passport, visa, transit, health and entry requirements with the relevant official authorities.

Publishing responsibility

These automated data pages are authored and maintained as product output by Flare, an IVRYN product. Travel guides follow the separate editorial policy. Questions or corrections can be sent to contact@flareflights.com.

Flare: https://flareflights.com/

How a nature app turns an 8-second video into a species suggestion, and where it stops

Victor Laybats — Tue, 27 Oct 2026 00:01:07 +0000

This article was created with the help of AI.

Originally published on naturego.app.

Nature GO is a free Android app that builds a nature dex from short videos. This is how it turns an 8-second clip into a species suggestion, and where it deliberately stops.

In short: you film the animal live in the app for about eight seconds while moving the phone the way the app asks. A server samples four frames, checks that they come from one real scene, then suggests a species with the visible evidence behind it. You confirm the suggestion before it enters your nature dex.

1. A live clip fills the dex, a photo only gets a name

Only video filmed in the app can add a species to the dex, so every entry is something you actually found. Since version 1.14 you can also pick a photo from your gallery: Professor Hazel, the app's AI, suggests a name, the photo counts as one of the day's analyses, and nothing is added to the dex. Before you record, the app gives one movement to make: keep the subject in frame and move the phone slowly to the left, or to the right. The direction is drawn at random for each clip and the challenge expires after ten minutes.

2. Four frames checked on the server

You choose whether to send each clip. The server decodes it, keeps four frames spread across the recording and looks at three things: whether the frames show one coherent natural scene, whether the camera moved as asked, and whether there are signs of a screen or a printed picture, such as borders, pixels or moiré. These checks are informative, not forensic: a clip is refused only when a screen or print is suspected and the frames do not hold together.

3. A suggestion with its evidence

The identification returns up to three candidates, from species to genus or family, each with a confidence level and the visible features it relies on, for example a bill colour, a wing pattern or the shape of a leaf. When the evidence is thin, the answer stays at genus level or says it is uncertain instead of guessing. A clip is accepted when a living subject is named and at least three of the four frames differ. You review the suggestion before you confirm it, and only confirmed, server-verified captures fill the catalogue of 151 species.

4. Why a clip can come back without an answer

Not enough evidence: no living subject could be named. Film closer and steadier, with the whole animal in frame.
Frames too still: fewer than three different frames, for example a video of a still image.
Screen or print suspected: the frames look like a screen or a printed page and do not form a coherent scene.
New clip needed: the challenge has expired, the clip was already used or it is larger than 16 MB. Record a new one.
Analysis paused: no connection, the daily limit is reached or the service is busy. The clip stays pending.

5. What we measured

On 21 October 2026 we ran the identification engine on eight reference photos from Wikimedia Commons, outside the video flow of the app. It named the five snakes to the exact species: western diamondback rattlesnake, ball python, corn snake, Indian cobra and common garter snake. For the three spiders it found the right genus: two answers stopped at genus level (widow spiders, recluse spiders), and the third proposed a species of the right genus with low confidence, Argiope trifasciata for a wasp spider (Argiope bruennichi). Eight photos are a small sample, not an accuracy rate.

6. Limits

An identification is a suggestion, not a guarantee. Nature GO never says whether a plant, fungus or animal is edible, venomous or safe. It needs an internet connection, and analysis pauses when the daily limit is reached: 3 analyses a day for free, 10 with Nature GO Plus while the service has capacity. Notes and place labels stay on your phone and are never sent for analysis.

At a glance

Price: free on Android, with 3 analyses a day. Optional Nature GO Plus: 10 analyses a day while the service has capacity, 30, 90 and 365-day field reports and a text export.
Account: none to create. Notes and place labels stay on the phone.
Catalogue: 151 species in 5 drawers: 42 birds, 45 plants, 34 insects, 15 mammals and 15 others (frogs, lizards, snails, spiders, fungi).
Safety: it never says whether a plant, fungus or animal is edible, venomous or safe.

Nature GO on Google Play: https://play.google.com/store/apps/details?id=com.ivryn.wildkeep

The full page, with the FAQ and the species guides: https://naturego.app/how-nature-go-identifies/

What a crawler can retrieve from nine small product sites: robots, sitemaps, JSON-LD and llms.txt

Victor Laybats — Mon, 26 Oct 2026 00:01:32 +0000

This article was created with the help of AI.

When you run several small product sites, it is easy to assume that robots rules, sitemaps, structured data and language annotations are all in place. We checked instead, once, on all nine public sites of the IVRYN portfolio, and published the result as a dated snapshot.

What was collected

One automated pass, without authentication, fetched each public homepage, robots.txt, the root sitemap, the blog sitemap and llms.txt. It parsed the XML locations, the JSON-LD types, the hreflang values and the root-path crawler rules. The observation is dated 2026-08-14 (00:22 UTC).

Observed results

Site	Home	Declared URLs	Schema types	Languages	OAI-SearchBot	GPTBot	ClaudeBot	llms.txt
IVRYN	200	29	Organization, WebPage, WebSite	en, es, fr, x-default	allowed	allowed	allowed	200
IMRYN	200	52	FAQPage, Organization, SoftwareApplication, WebSite	en, es, fr, x-default	allowed	allowed	allowed	200
Datvero	200	37	Organization, SoftwareApplication, WebSite	en, fr, x-default	allowed	allowed	allowed	200
Cascads	200	77	FAQPage, Organization, SoftwareApplication, VideoObject, WebPage, WebSite	en, es, fr, x-default	allowed	allowed	allowed	200
Reef	200	33	FAQPage, MobileApplication, Organization, WebPage, WebSite	en, es, fr, x-default	allowed	allowed	allowed	200
Flare	200	458	FAQPage, MobileApplication, Organization, WebPage, WebSite	en, es, fr, x-default	allowed	allowed	allowed	200
Sealed	200	26	FAQPage, MobileApplication, Organization, WebPage, WebSite	en, fr, x-default	allowed	allowed	allowed	200
Crucible CLUB	200	13	Organization, WebPage, WebSite	en, fr, x-default	allowed	allowed	allowed	200
Victor Laybats	200	35	FAQPage, Person, ProfessionalService, WebPage	en, es, fr, x-default	allowed	allowed	allowed	200

In short: 9 of 9 homepages returned HTTP 200, 9 of 9 roots allowed OAI-SearchBot, and the sitemaps declared 760 unique URLs in total.

Versioning

The dated directory is immutable by convention. CSV and JSON files come with checksums, so a later snapshot can be compared line by line. The current URL may be refreshed by a future observed snapshot.

What this does not tell you

This is a complete census of one owner-operated portfolio, not a representative sample of websites, startups or production stacks. It describes retrievable public artefacts at one point in time. It does not measure search placement, backlink authority, audience, adoption, revenue or the probability of citation by a search or AI system.

A crawler being allowed does not mean it visited, indexed, ranked or cited a page. A sitemap declaration is not proof of indexation.

Data and method

The CSV, JSON, field dictionary and reproduction notes are on the original page: Nine-site public web transparency snapshot. Protocol references: RFC 9309 (Robots Exclusion Protocol), the Sitemaps XML protocol and Schema.org Dataset.

Do you run a similar check on your own sites, and which field would you add?

26 questions to ask before joining a builder residency or hacker house

Victor Laybats — Mon, 26 Oct 2026 00:01:14 +0000

This article was created with the help of AI.

A beautiful house and a focused month are not enough information for a travel or financial commitment. Builder residencies, hacker houses and coliving cohorts for founders are easy to like from a landing page, and much harder to check before you send a deposit or book a flight.

I wrote this checklist for Crucible CLUB, a builder residency project at IVRYN, from its public participation methodology and from the decision-critical gaps that any cohort-specific offer must resolve. It gives prospective participants, organisers and journalists a shared set of 26 questions. Every item asks for evidence rather than awarding a score, and the framework is independent of the status of any current Crucible cohort (cohort details are still pending).

Operator

BRD-01. The legal or responsible operator is named. A participant needs to know who accepts money and carries obligations. Evidence to record: Record the operator name, registration or legal status and service address.

BRD-02. A monitored contact and escalation route are provided. Questions and urgent issues need more than a social profile. Evidence to record: Test the ordinary and urgent contact routes.

Status

BRD-03. Application status and decision dates are current. An open label can become misleading when dates have passed or a cohort has started. Evidence to record: Capture the page, timestamp and stated decision timeline.

BRD-04. Exact arrival, departure and program dates are stated. Travel and accommodation decisions depend on unambiguous dates and time zones. Evidence to record: Record dates, check-in windows and time zone.

Venue

BRD-05. The city and venue status are confirmed. A concept image or provisional city is not a confirmed accommodation booking. Evidence to record: Request the address or a documented disclosure of when it will be supplied.

BRD-06. Room allocation, occupancy and accessibility are described. Shared-room assumptions materially affect fit, privacy and cost. Evidence to record: Record bed type, room sharing, bathrooms, stairs and accessibility constraints.

BRD-07. Capacity and minimum viable cohort are disclosed. A residency can change or cancel if too few or too many people join. Evidence to record: Record maximum capacity, minimum cohort and the consequence if unmet.

Money

BRD-08. The total price, currency and taxes are stated. A headline price may omit taxes, deposits or mandatory extras. Evidence to record: Request an itemized total in the payment currency.

BRD-09. Included and excluded services are itemized. Accommodation, food, transport, workspace and activities should not be inferred. Evidence to record: Create an inclusion and exclusion list.

BRD-10. Payment recipient, schedule and method are verifiable. The payee should match the responsible operator or a disclosed agent. Evidence to record: Record invoice issuer, payee, due dates and payment protection.

BRD-11. Cancellation, refund and organiser-cancellation terms are supplied before payment. A participant needs to understand losses under each cancellation scenario. Evidence to record: Save the terms version accepted at payment.

Travel

BRD-12. Visa and work-authorisation responsibility is explicit. A residency invitation does not determine immigration or work rights. Evidence to record: Check current official authority guidance for the participant’s nationality and activity.

BRD-13. Insurance expectations and exclusions are explicit. Travel, health, equipment and cancellation risks may require different cover. Evidence to record: Record required cover and who bears uninsured costs.

Safety

BRD-14. Emergency contacts and evacuation procedures exist. Shared accommodation in an unfamiliar place needs a practical incident plan. Evidence to record: Request emergency numbers, exits, assembly point and hospital route.

BRD-15. Health, accessibility and accommodation needs have a private route. Participants need a way to discuss needs without public disclosure. Evidence to record: Test the confidential request and response process.

Community

BRD-16. House rules cover guests, noise, substances and shared spaces. Common expectations reduce avoidable conflict in a live-work house. Evidence to record: Review the cohort-specific house rules before acceptance.

BRD-17. Conflict, harassment and removal procedures are defined. A community promise needs a safe route for complaints and proportionate action. Evidence to record: Record reporter options, decision owner and consequences.

Privacy

BRD-18. Photography and public-content participation require separate agreement. Joining a residency is not consent to marketing or documentary content. Evidence to record: Review release wording and the opt-out path.

BRD-19. Confidential projects and intellectual property remain under participant control. Proximity should not force disclosure or transfer of project rights. Evidence to record: Review confidentiality and intellectual-property clauses.

Work

BRD-20. The expected work rhythm and mandatory activities are stated. A participant cannot assess fit without knowing the balance of focus and group time. Evidence to record: Record mandatory sessions, quiet hours and uninterrupted blocks.

BRD-21. Each participant controls their project and milestone. Selection should not imply employment, investment or transfer of decision rights. Evidence to record: Review the agreement and milestone process.

Selection

BRD-22. Selection criteria and conflicts of interest are described. Applicants should understand what is assessed and whether sponsors influence selection. Evidence to record: Record criteria, reviewers and material relationships.

Claims

BRD-23. Testimonials identify the cohort and have publication permission. A quote without context or consent cannot establish a repeatable outcome. Evidence to record: Verify the speaker, cohort, approved wording and date.

BRD-24. Launch, revenue, funding and partnership claims link to a verifiable record. Residency association should not be confused with causation or endorsement. Evidence to record: Request the public artifact and participant-approved attribution.

BRD-25. Outcomes state starting point, time horizon and limitations. Without a baseline and timeframe, progress claims are easy to overread. Evidence to record: Record milestone, observed deliverable, later result and external factors.

Decision

BRD-26. Unresolved questions are listed before payment or travel. A visible open-questions list prevents enthusiasm from becoming assumed fact. Evidence to record: Publish or retain a dated decision log with owner and due date.

Limits

This is a due-diligence aid, not legal, immigration, tax, medical, insurance or financial advice. It does not verify a venue, operator or cohort and it does not guarantee safety or project outcomes. Time-sensitive details must be checked directly with the organiser and relevant authorities before commitment.

The checklist is published under CC BY 4.0, with CSV and JSON downloads and checksums, on the original page: Builder Residency Due-Diligence Checklist v1.0.

If you have run or joined a residency, which question would you add?

The Kelly criterion for traders: formulas, a worked example and the limits

Victor Laybats — Sun, 25 Oct 2026 07:38:18 +0000

This article was created with the help of AI.

Originally published on IMRYN, where the interactive calculator runs in the browser. Reviewed 2026-10-24.

The Kelly criterion gives the fraction of capital that maximises long-run logarithmic growth. For a trade that either wins R times the amount risked or loses it, the Kelly fraction is f = p - (1 - p) / R, where p is the win probability.

Example: a 55 % win rate with a 2:1 win/loss ratio gives f = 0.55 - 0.45 / 2 = 32.5 %. Most practitioners stake a fraction of Kelly, because the inputs are estimates and full Kelly swings hard.

The calculator has three modes: win rate and win/loss ratio, partial loss (gain and loss fractions), and investment (return and volatility). Everything is calculated in your browser, nothing you type is sent anywhere, and the source code and tests are on GitHub under MIT.

Worked example

Win rate 55 %, win/loss ratio 2:

full Kelly 32.5 %
half Kelly 16.25 %
quarter Kelly 8.125 %

Expected log growth per trade: 9.86 % at full Kelly, 7.50 % at half Kelly.

Continuous form with 8 % expected return, 3 % risk-free rate and 20 % volatility: 125 %, which means leverage.

Formula

Binary outcome, general form (Kelly 1956): f = p / l - q / g, where p is the win probability, q = 1 - p, g is the fraction of the stake gained on a win and l the fraction lost on a loss.
Trading form with a full loss of the amount risked (l = 1) and payoff ratio R = average win / average loss: f = p - q / R.
Expected log growth per bet at fraction f: G(f) = p ln(1 + g f) + q ln(1 - l f). Betting twice the Kelly fraction brings growth back to about zero.
Continuous approximation for an investment: f = (mu - r) / sigma^2, with mu the expected return, r the risk-free rate and sigma the volatility, all annual. A result above 100 % implies leverage.

Limits

p and R are estimates. A small error in the win rate moves the Kelly fraction a lot, and an overestimated edge leads to over-betting, which lowers growth and deepens drawdowns.
The formula assumes independent repeated bets with known odds. Trades are often correlated, fat tailed and affected by costs and slippage.
Fractional Kelly (half or quarter) reduces volatility and the chance of ruin at the cost of slower growth.
The continuous form assumes a symmetric return distribution.

Questions

What is a good Kelly fraction? There is no universal value. Full Kelly maximises long-run log growth only if the inputs are exact. Many traders use half or quarter Kelly to absorb estimation error.

What if the Kelly result is negative? A zero or negative result means the inputs show no edge: the criterion says not to take the bet.

Is Kelly the amount to risk or the position size? In the trading form it is the fraction of capital put at risk on a trade that loses the full amount risked at the stop. Convert it into units with the position size calculator.

Sources

Kelly, J. L. (1956), A New Interpretation of Information Rate, Bell System Technical Journal 35(4), 917-926
Kelly criterion, Wikipedia (formulas f = p/l - q/g and f = (mu - r)/sigma^2)

Educational calculator, not financial advice. It does not know your situation, costs, taxes or the real distribution of your returns. Past or estimated figures do not predict future results.

Try the Kelly criterion calculator on IMRYN

Which countries are in Europe? What Wikidata told us while building a daily quiz

Victor Laybats — Sun, 25 Oct 2026 00:02:01 +0000

This article was created with the help of AI.

Last night we added a daily Europe quiz, in six languages, to our Wikidata trivia pages: the country highlighted on a map, its capital, its flag, with every wrong answer also taken from Europe. The question we thought would take five minutes was the first line of the spec: which countries count as European?

Here is what Wikidata answered, and the rules we ended up writing down.

Continent (P30) is a property, not a definition

Our country list is every sovereign state (wd:Q3624078) with its continent statements (wdt:P30). For most countries there is exactly one value. The query below, run on 25 October 2026, returns the exceptions:

SELECT ?c ?cLabel (COUNT(DISTINCT ?cont) AS ?n) WHERE {
  ?c wdt:P31 wd:Q3624078 .
  ?c wdt:P30 ?cont .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
} GROUP BY ?c ?cLabel HAVING (?n > 1)

It lists Turkey and Kazakhstan (Europe and Asia), Russia with three values (Europe, Asia and Eurasia), four Pacific states recorded in both "Oceania" and "Insular Oceania", which we merge, and the Russian Empire, a historical item that we filter out. So the real question is three countries: Russia, Turkey and Kazakhstan.

The borderline cases you might expect are not borderline in the data. Georgia and Cyprus have Europe as their only continent. Armenia and Azerbaijan have Asia only.

Wikidata is right to keep several values for the three transcontinental states. A quiz still has to decide. Our rule: a country is in the Europe quiz if Europe is its only continent, or if it spans several continents and its capital lies in Europe. That puts Russia in (Moscow) and leaves Turkey (Ankara) and Kazakhstan (Astana) out. The rule is written on the page, in each language, because someone will ask. The result is 46 countries.

Wrong answers have to stay on the continent

A flag question with Norway as the answer and Bolivia as a decoy is not a question. Every capital, flag and map question draws its three decoys from the same 46 countries. That works because the pool is large enough: even the flag family, the smallest, keeps 40 countries.

Why 40? Six European countries have more than one current flag file in P41 (no end date): Belgium, Bulgaria, Hungary, Spain, Switzerland and Vatican City. Our generator only asks about a flag when there is exactly one, so those six are left out of flag questions and stay in capital and map questions.

Germany's 16 states: two have no capital at all

We added a quiz on the German Länder at the same time (wd:Q1221156). Three surprises:

Berlin and Hamburg have no capital statement (P36). They are city-states, so the state and the city are one item. A capital question would show the answer in the question anyway.
Bremen's item is "Freie Hansestadt Bremen", the state, whose capital is the city of Bremen, a different item. We display the state as "Bremen" and skip its capital question for the same reason as above.
Bavaria has two current flags, the lozenge flag and the striped flag, both official. Here we keep one (the first by file name) rather than drop the state, because 16 is already a small pool.

With 16 items, a day's quiz asks 16 questions, each state once, and rotates the question type so a state does not come back with the same question the next day.

The query that timed out

Our first Länder query asked for labels of the state and of its capital in one go, using the usual OPTIONAL label pattern with a fallback to the mul label. It returned HTTP 504 twice. The bare query (items, capital, flag, locator map) returns in under a second, and the labels in six languages come back from a second query over a VALUES list. For small classes, two light queries beat one clever one.

Labels are not display names

Portuguese labels (we use the Brazilian ones first) gave "República da Irlanda" for Ireland and "Cidade de Bruxelas" for Brussels. Both are correct and both look odd as quiz choices. We keep a short override table for display names, the same way we already show "China" rather than "People's Republic of China".

Try it

Europe quiz: English, French, Spanish, German, Italian, Portuguese
Bundesländer-Quiz (German)
How the questions are generated: method page

The facts come from Wikidata (CC0) and the images from Wikimedia Commons. If you have a better rule for transcontinental countries, I would like to hear it.

30 execution controls for algorithmic trading systems, each tied to evidence and a failure mode

Victor Laybats — Sat, 24 Oct 2026 06:43:44 +0000

This article was created with the help of AI.

Originally published on IMRYN Research, 14 August 2026, by Victor Laybats.

A practical register for reviewing systematic execution infrastructure without treating a policy statement, dashboard or successful run as proof that a control works: 30 explicit control checks in 6 review categories, 17 suggested critical priorities. Every row pairs a control objective with evidence an evaluator could inspect and a concrete failure the control is intended to surface. The register deliberately avoids pass or fail claims about any implementation.

Governance

ID	Control	Evidence	Failure surfaced	Scope	Priority
GOV-01	Named accountable owner	An approved owner and deputy are recorded for each algorithm.	No accountable decision-maker during a change or incident.	Before deployment	critical
GOV-02	Bounded operating scope	Permitted accounts, instruments, venues, sessions and order types are versioned.	The algorithm acts outside its reviewed operating envelope.	Before deployment	critical
GOV-03	Versioned algorithm inventory	Each active algorithm has an identifier, purpose, owner, version and deployment state.	Operators cannot establish which logic is live.	Continuous	high
GOV-04	Material-change policy	The team defines, detects, reviews and approves material changes before release.	A significant change bypasses the intended review path.	Change	critical
GOV-05	Independent challenge	Risk, compliance or another independent reviewer can challenge release evidence.	Development assumptions remain untested by a separate function.	Change	high

Data integrity

ID	Control	Evidence	Failure surfaced	Scope	Priority
DATA-01	Authoritative source map	Every decision input names its authoritative source, unit, timezone and fallback.	Conflicting sources silently drive different decisions.	Before deployment	high
DATA-02	Freshness boundary	A maximum acceptable age is defined and visible for each time-sensitive input.	Stale data is accepted as current.	Runtime	critical
DATA-03	Schema and range validation	Malformed, missing and implausible values fail explicit validation.	Bad input reaches decision logic without a controlled stop.	Runtime	critical
DATA-04	Clock synchronization check	Clock source, drift tolerance and alerting are documented and tested.	Event ordering and latency evidence become unreliable.	Runtime	high
DATA-05	Replayable input record	A bounded record can reconstruct the inputs used for a reviewed decision.	An incident cannot be reproduced without relying on memory.	After execution	high

Pre-trade risk

ID	Control	Evidence	Failure surfaced	Scope	Priority
RISK-01	Instrument and venue allowlist	Orders are rejected unless the instrument and destination are explicitly permitted.	An unintended market or product receives an order.	Runtime	critical
RISK-02	Order size and notional limits	Hard per-order quantity and notional ceilings are enforced before transmission.	A malformed or extreme order leaves the system.	Runtime	critical
RISK-03	Position and exposure limits	Projected exposure is checked at the relevant account and aggregate levels.	Individually valid orders create an invalid aggregate exposure.	Runtime	critical
RISK-04	Price collars	Order prices are checked against a documented reference and tolerance.	A stale or malformed price creates an extreme instruction.	Runtime	critical
RISK-05	Message-rate controls	Order, cancel and replace rates have hard limits and tested behavior.	A loop overwhelms a venue, gateway or downstream control.	Runtime	critical

Execution lifecycle

ID	Control	Evidence	Failure surfaced	Scope	Priority
EXEC-01	Idempotent order intent	A stable intent identifier prevents duplicate transmission after retry or reconnect.	The same decision creates multiple live orders.	Runtime	critical
EXEC-02	Decision-to-order trace	Decision, risk result, transmitted instruction and venue response share a trace key.	An order cannot be tied back to its initiating decision.	Runtime	high
EXEC-03	Acknowledgement timeout	A bounded wait state and escalation path exist for missing venue acknowledgement.	The system assumes an unknown order is absent or complete.	Runtime	critical
EXEC-04	Explicit state machine	Accepted, rejected, resting, partial, filled, cancel-pending and cancelled states are distinct.	Ambiguous lifecycle state drives an unsafe next action.	Runtime	critical
EXEC-05	Venue isolation	A degraded venue can be restricted without disabling unaffected routes by accident.	One venue failure propagates uncontrolled behavior across routes.	Runtime	high

Human control

ID	Control	Evidence	Failure surfaced	Scope	Priority
HUM-01	Rapid disable mechanism	Authorized operators can stop new activity in a small, documented number of steps.	The algorithm continues while operators search for a control.	Runtime	critical
HUM-02	Cancel and exposure procedure	The runbook separates stopping new orders, cancelling open orders and managing exposure.	A stop command leaves unmanaged orders or exposure.	Incident	critical
HUM-03	Role and entitlement separation	Release, limit changes and emergency actions use least privilege and named roles.	One compromised or mistaken identity has unnecessary authority.	Continuous	critical
HUM-04	Override audit trail	Every override records actor, time, prior value, new value, reason and approval.	Temporary exceptions become invisible permanent behavior.	Runtime	high
HUM-05	Escalation thresholds	Conditions for review, automatic restriction and executive escalation are pre-defined.	Teams improvise authority during a fast-moving event.	Incident	high

Operations and evidence

ID	Control	Evidence	Failure surfaced	Scope	Priority
OPS-01	Health and dependency view	Market data, gateways, venues, storage and control services have distinct health states.	A green aggregate status hides a critical dependency failure.	Runtime	high
OPS-02	Actionable alert ownership	Each material alert has a severity, owner, response time and tested destination.	An alert exists but no one is responsible for acting.	Runtime	high
OPS-03	Order and position reconciliation	Internal records are periodically compared with authoritative external state.	Silent divergence persists between local and venue or broker state.	Runtime	critical
OPS-04	Incident timeline	Significant events preserve configuration, inputs, decisions, controls, orders and interventions.	Post-incident review lacks a coherent sequence.	Incident	high
OPS-05	Post-incident action closure	Findings receive an owner, due date, verification test and closure evidence.	The same control weakness recurs without a verified fix.	After incident	high

Source synthesis

The categories were synthesized from public supervisory guidance and operational incident-review practices, then normalized into implementation-neutral review questions.

Primary references:

Use and limits

This register is educational. It is not a compliance mapping, certification, investment recommendation or claim about the controls implemented by IMRYN. A firm must determine applicable legal requirements and calibrate controls to its markets, systems and risk appetite.

A documented control is not an effective control until its enforcement, failure behavior, ownership and evidence have been tested.

Data

Register as CSV, JSON and field dictionary
Method and scope
GitHub mirror
License: CC BY 4.0

Suggested citation: Victor Laybats for IMRYN Research (2026), "Systematic execution control evidence register", version 2026-08-14, https://imryn.com/blog/execution-control-checklist/2026-08-14/

Related on IMRYN: the human approval constraint explains why the final execution step remains intentionally reviewable, and the free position size calculator turns a risk per trade and a stop into units.

How long until a missed heartbeat is flagged? A reproducible detection timing table

Victor Laybats — Sat, 24 Oct 2026 06:42:52 +0000

This article was created with the help of AI.

Originally published on Datvero Research. Author: Victor Laybats, IVRYN.

When a scheduled workflow (n8n, Make, Zapier or a plain cron job) stops sending its heartbeat, how long does it take before a monitor marks it late, then down? We derived the answer from the detector implementation itself instead of guessing: a reproducible timing table, with the source fingerprint published next to it.

The detector checks every 60 seconds, marks a workflow late after 1.5 times its expected interval and down after 2 times its expected interval.

Detection timing by expected heartbeat interval

Each range covers all 60 whole-second offsets between a stored heartbeat and the detector's recurring check. Threshold comparisons are strict, so a check exactly on the threshold does not transition state.

Expected heartbeat	Late threshold	Late observed range	Late p95	Down threshold	Down observed range	Down p95
1 min	1 min 30 s	1 min 31 s to 2 min 30 s	2 min 27 s	2 min	2 min 01 s to 3 min	2 min 57 s
5 min	7 min 30 s	7 min 31 s to 8 min 30 s	8 min 27 s	10 min	10 min 01 s to 11 min	10 min 57 s
10 min	15 min	15 min 01 s to 16 min	15 min 57 s	20 min	20 min 01 s to 21 min	20 min 57 s
30 min	45 min	45 min 01 s to 46 min	45 min 57 s	60 min	60 min 01 s to 61 min	60 min 57 s
60 min	90 min	90 min 01 s to 91 min	90 min 57 s	120 min	120 min 01 s to 121 min	120 min 57 s

Implementation rule: late when elapsed > expected × 1.5, down when elapsed > expected × 2, evaluation every 60 s.

How the table was produced

Extract. The generator reads the current detector source and extracts its check interval and status multipliers.
Enumerate. It evaluates every whole-second scheduler phase from 1 through 60 seconds for each configured example interval.
Record. It records earliest, median, p95 and latest transition time for late and down states.
Fingerprint. The output stores the repository commit, source path, dirty state and SHA-256 of the tested implementation (source SHA-256 d1ff53f470a80addc76384515fca0e17567588e44c550b903f7bc01ae1940321, version 2026-08-14T00:48:39.865Z).

Interpretation and limits

This is implementation evidence, not a production response-time promise. Actual notification time includes more systems than the detector threshold.

This table is derived from a source-code snapshot and is not a production latency measurement or service-level agreement.
Whole-second scheduler phases are sampled. Sub-second phase offsets are not enumerated.
Network transit, database latency, process stalls, alert rendering and delivery-channel latency are excluded.
The model starts from the last stored heartbeat timestamp and assumes the detector continues to run every configured check interval.
The results do not measure third-party workflow reliability or customer outcomes.

Data and reproduction

The structured dataset, row-level CSV, schema, reproduction note and integrity hashes contain no customer or workflow records.

The original compilation, authored method and generated timing table are licensed under CC BY 4.0.

Suggested citation: Laybats, Victor. "Heartbeat monitoring detection envelope." Datvero Research, IVRYN, 9 Aug. 2026. https://datvero.com/research/heartbeat-detection-envelope/2026-08-14T00-48-39-865Z/index.html

If you are setting up the schedule itself, our free cron expression explainer reads a 5 or 6 field expression and lists the next runs in your time zone.

How we keep a social media scheduler from double-posting: a 200-process contention test

Victor Laybats — Fri, 23 Oct 2026 18:13:00 +0000

This article was created with the help of AI.

A social media scheduler has one job it must never get wrong: publish a post once. If two workers wake up for the same scheduled item at the same moment, a naive scheduler posts twice, and a duplicate on a client's account is worse than a late post.

In Cascads, a multi-brand social media cockpit, the guard is a durable claim: for one content item and one network key, exactly one process may call the provider while the claim is active. We wanted evidence that this holds under real contention, not just a passing unit test, so we measured it.

Method

Each round follows the same five steps:

Create a new temporary ledger for the round.
Start 8 independent Node.js processes and hold them at a common barrier.
Release the barrier so every process contests the same item and platform key.
Count callback marker files, which are written only inside the provider stub.
Require one delivered state, 7 blocked contenders and one callback in every round.

We ran 25 rounds, so 200 simultaneous attempts in total. The tested source is lib/publication-claims.js; the study page records its commit, its SHA-256 and whether it had uncommitted changes at test time.

Result

Every round satisfied the invariant. Across the 200 attempts, 25 workers reached the provider stub and 175 contenders were rejected before the side effect: 25 callbacks for 25 rounds, 0 duplicate callbacks and 0 unexpected worker outcomes.

What this does and does not show

This is narrow evidence about one local concurrency boundary. It is not evidence of customer outcomes, platform acceptance or distributed exactly-once delivery. In particular:

It is a controlled single-host process-contention study, not a production traffic sample.
The provider callback is a local deterministic stub: no social network API was called.
It does not test multi-host setups or distributed filesystems.
It covers the shared X and YouTube claim module through the X branch only.

If you build a scheduler, a queue consumer or anything that triggers an external side effect, this kind of barrier test is cheap to write and catches the race that unit tests never see.

Data

The summary, round-level results, schema and checksums are public under CC BY 4.0: the study page on cascads.com and the dataset in the IVRYN open research repository. No customer content, account identifier or credential is included.

A production readiness matrix for n8n and AI workflows: 32 checks

Victor Laybats — Fri, 23 Oct 2026 17:46:27 +0000

This article was created with the help of AI.

A workflow is not production-ready because the happy path ran once. This matrix lists thirty-two checks for n8n workflows and AI agents. Each one asks for evidence you can inspect and a failure test you can actually trigger before deployment, so it stays useful when tools, model providers and infrastructure change.

Rows marked all apply broadly, rows marked n8n refer to platform-level review, and rows marked ai cover non-deterministic output, tool use and agent authority.

Ownership and scope

OWN-01 Named workflow owner (critical, scope all). Evidence: Owner, deputy and business approver are recorded. Failure test: No one has authority to decide during failure.
OWN-02 Observable success condition (high, scope all). Evidence: A measurable output, acceptance rule and review window are written down. Failure test: A successful execution is mistaken for a useful outcome.
OWN-03 Stop conditions (critical, scope all). Evidence: The workflow defines inputs and states that must block automation. Failure test: Automation continues through ambiguity or unsafe context.
OWN-04 Dependency inventory (high, scope all). Evidence: APIs, models, credentials, queues, databases and human steps are listed. Failure test: A hidden dependency fails without an owner or fallback.

Inputs and data

IN-01 Authenticated trigger (critical, scope all). Evidence: Public triggers use appropriate authentication or a documented public-access decision. Failure test: An unauthorized caller starts a sensitive workflow.
IN-02 Schema validation (critical, scope all). Evidence: Required fields, types, sizes and allowed values are checked before processing. Failure test: Malformed input causes unsafe branching or downstream errors.
IN-03 Untrusted-content boundary (critical, scope ai). Evidence: External text and files are treated as data, not instructions. Failure test: Injected content changes tool or model behavior.
IN-04 Data minimization (high, scope all). Evidence: Only fields necessary for the workflow are collected and retained. Failure test: Sensitive data is exposed without operational need.
IN-05 Authoritative source rule (high, scope all). Evidence: Conflicts between systems resolve to a named source of truth. Failure test: Different runs produce inconsistent decisions from conflicting data.

Execution and recovery

FLOW-01 Idempotency key (critical, scope all). Evidence: Repeated triggers and retries cannot duplicate the external effect. Failure test: A timeout or replay creates duplicate records or messages.
FLOW-02 Bounded retry policy (critical, scope all). Evidence: Only transient failures retry, with a cap, delay and terminal path. Failure test: A persistent failure loops, increases cost or repeats side effects.
FLOW-03 Explicit timeout (high, scope all). Evidence: Every remote dependency has a timeout shorter than the workflow budget. Failure test: One call holds the workflow indefinitely.
FLOW-04 Error workflow (critical, scope n8n). Evidence: Unhandled failures reach a tested error path with useful context. Failure test: The execution stops silently or alerts without diagnostic data.
FLOW-05 Partial-failure policy (critical, scope all). Evidence: The design states when to stop, compensate, queue or continue. Failure test: Continue-on-error hides a missing critical step.
FLOW-06 Dead-letter path (high, scope all). Evidence: Terminal failures are retained for bounded, authorized replay. Failure test: Failed work is lost or retried blindly.
FLOW-07 Manual recovery runbook (high, scope all). Evidence: A person can identify state, avoid duplicates and resume safely. Failure test: Recovery requires ad hoc database or workflow edits.

AI behavior

AI-01 Representative evaluation set (critical, scope ai). Evidence: Typical, edge, ambiguous and refusal cases are versioned. Failure test: A prompt change ships without behavioral comparison.
AI-02 Structured output validation (critical, scope ai). Evidence: Model output is parsed against a strict schema before use. Failure test: Malformed or invented fields reach downstream actions.
AI-03 Least-capability tools (critical, scope ai). Evidence: The agent receives only the tools and parameters required for its task. Failure test: A manipulated or mistaken choice has excessive impact.
AI-04 Human approval for material actions (critical, scope ai). Evidence: External, financial, sensitive or irreversible actions require proportionate approval. Failure test: A plausible but wrong output directly changes external state.
AI-05 Model and prompt version (high, scope ai). Evidence: Model, parameters, prompt and tool manifest are identifiable per execution. Failure test: A behavioral regression cannot be attributed or reproduced.
AI-06 Cost and loop ceiling (critical, scope ai). Evidence: Token, step, time and tool-call ceilings stop runaway execution. Failure test: An agent loop consumes unbounded budget or API capacity.

Security and privacy

SEC-01 Least-privilege credentials (critical, scope all). Evidence: Each credential exposes only necessary operations and environments. Failure test: A node compromise grants broad account access.
SEC-02 Secret hygiene (critical, scope all). Evidence: Secrets stay in credential storage or controlled environment configuration. Failure test: Keys leak into workflow JSON, logs or error messages.
SEC-03 Risky-node review (high, scope n8n). Evidence: Code, shell, file, database and community nodes receive explicit review. Failure test: A powerful node expands the attack surface unnoticed.
SEC-04 Log redaction (critical, scope all). Evidence: Tokens, personal data and confidential payloads are removed or minimized in traces. Failure test: Debug evidence becomes a data leak.
SEC-05 Retention and deletion rule (high, scope all). Evidence: Execution data has a documented retention period and deletion process. Failure test: Sensitive payloads remain indefinitely.

Operations

OPS-01 Deployment version and rollback (critical, scope all). Evidence: A release is identifiable and a prior safe version can be restored. Failure test: An incident cannot be contained without rebuilding from memory.
OPS-02 Health versus outcome metrics (high, scope all). Evidence: Availability, error rate, latency, cost and output quality are measured separately. Failure test: HTTP success hides wrong or low-quality output.
OPS-03 Actionable alerts (high, scope all). Evidence: Alerts have severity, owner, destination, threshold and response expectation. Failure test: Noise masks a material failure.
OPS-04 Synthetic failure test (critical, scope all). Evidence: Timeout, bad input, rate limit and downstream outage paths are exercised. Failure test: The fallback exists only on the canvas and fails when needed.
OPS-05 Periodic access and audit review (high, scope n8n). Evidence: Credentials, webhooks, nodes, versions and inactive workflows are reviewed. Failure test: Old access and exposed triggers accumulate silently.

Use and limits

The matrix is a review aid, not a security certification, warranty or substitute for a project-specific legal, privacy or compliance assessment. Not every check applies to every workflow.

A green execution status proves that the engine completed a path. It does not prove that the output was correct, authorized or useful.

References

The versioned matrix, with CSV and JSON downloads, is on victorlaybats.com and mirrored in the IVRYN open research repository. If you run n8n or agents in production, I would like to know which check you would add.

What broke when we generated daily trivia from Wikidata

Victor Laybats — Fri, 23 Oct 2026 15:48:46 +0000

This article was created with the help of AI.

I wanted daily quizzes whose answers anyone can check, so every question on our trivia pages is generated from a Wikidata fact, and every answer links back to its Wikidata item. Twenty questions a day, capitals, flags, rivers, literary works, films, events, championship winners.

The quiz part was easy. The data part was not. Here is what broke, measured on 23 October 2026, and what we changed.

1. Nearly one famous person in five had no English or French label

Since 2024 Wikidata stores many proper names once, under a label for all languages (mul), instead of repeating them in every language. A query that asks for lang(?label) = "en" silently drops those items.

On a sample of the 200 most-read people of our card catalogue, 36 had no English or no French label: George Washington, Barack Obama, William Shakespeare and Novak Djokovic among them. Juneau, the capital of Alaska, only had the mul label, so Alaska disappeared from our US states quiz.

The fix is a fallback chain:

OPTIONAL { ?x rdfs:label ?fr  FILTER(lang(?fr)  = "fr") }
OPTIONAL { ?x rdfs:label ?en  FILTER(lang(?en)  = "en") }
OPTIONAL { ?x rdfs:label ?mul FILTER(lang(?mul) = "mul") }
BIND(COALESCE(?fr, ?mul, ?en) AS ?labelFr)
BIND(COALESCE(?en, ?mul) AS ?labelEn)

2. Scanning a whole class times out

The public SPARQL service stops a query after 60 seconds. "Every mountain with its elevation" or "every novel with its author" ended in an HTTP 504 or in a truncated JSON body, depending on the load of the service.

What works: start from a list of known items. We map our most-read Wikipedia articles to their Wikidata ids through the Wikipedia API (prop=pageprops&ppprop=wikibase_item, 50 titles per call), then query them with VALUES ?x { ... } in batches of 100 ids. We also write the output after each kind of fact, so one failure no longer loses the others.

3. The Nile was 2,850 km long

Many items carry several values for one property. The Nile has 6,650 km with a preferred rank and also 2,850 km with a normal rank. The Amazon has 6,400 km with a preferred rank and four other values, from 3,690 to 6,992 km. A median of all values makes "which river is the longest?" wrong.

?x p:P2043 ?st .
?st psn:P2043/wikibase:quantityAmount ?length ;
    wikibase:rank ?rank .
FILTER(?rank != wikibase:DeprecatedRank)

We keep preferred-rank values when they exist, drop items whose remaining values disagree by more than 12 %, and only compare four rivers when the first is at least 15 % longer than the second. The Nile and the Amazon, about 4 % apart, are never the two candidates of the same question.

4. True in Wikidata, unfair in a quiz

Pop songs often record a single co-writer as composer: Wikidata gives RedOne for Poker Face, which he wrote with Lady Gaga. We removed music.
"Discoverer" also applies to places: Persepolis would be credited to a Spanish diplomat. Anything with coordinates is out of the discoveries.
Franchises keep their current name for past titles: Super Bowl XI (1977) is won by the Las Vegas Raiders, who were the Oakland Raiders then. American leagues only use editions from 2000.
Oceania exists twice (Oceania and Insular Oceania), which left Tuvalu without a continent. We merge them.
Capitals with an internationally disputed status are never asked, and are marked in the list of capitals.
A wrong answer is never a prefix of the right one, so "Rugby" never sits next to "Rugby union".

5. Commons refuses 320 px thumbnails

Flags and locator maps are Wikimedia Commons thumbnails. A width of 320 px returns HTTP 400 with "Use thumbnail sizes listed on https://w.wiki/GHai", while 120, 250, 330 and 500 px are served:

import hashlib, urllib.parse

def thumb(name, width=330):
    n = name.replace(" ", "_")
    h = hashlib.md5(n.encode()).hexdigest()
    q = urllib.parse.quote(n)
    ext = ".png" if n.lower().endswith(".svg") else ""
    return f"https://upload.wikimedia.org/wikipedia/commons/thumb/{h[0]}/{h[:2]}/{q}/{width}px-{q}{ext}"

The result

Sixteen quiz pages, twenty questions a day each, every answer with its source. The cleaned fact set is open data (CC0) on GitHub, and the full write-up with the French version is on our site.

If you build on Wikidata, I would love to hear about the quirks I missed.

DEV Community: Victor Laybats

How a flight alert app decides a fare drop is real: trimmed medians, score gates and append-only snapshots

Short answer

How a fare enters the public collection

What “reference price” means

Freshness and verification

City and airport consolidation

Row-level provenance

Versioning and reproducibility

Measured answers from this dataset

Reuse rights

How to use the information

Publishing responsibility

How a nature app turns an 8-second video into a species suggestion, and where it stops

1. A live clip fills the dex, a photo only gets a name

2. Four frames checked on the server

3. A suggestion with its evidence

4. Why a clip can come back without an answer

5. What we measured

6. Limits

At a glance

What a crawler can retrieve from nine small product sites: robots, sitemaps, JSON-LD and llms.txt

What was collected

Observed results

Versioning

What this does not tell you

Data and method

26 questions to ask before joining a builder residency or hacker house

Operator

Status

Venue

Money

Travel

Safety

Community

Privacy

Work

Selection

Claims

Decision

Limits

The Kelly criterion for traders: formulas, a worked example and the limits

Worked example

Formula

Limits

Questions

Sources

Which countries are in Europe? What Wikidata told us while building a daily quiz

Continent (P30) is a property, not a definition

Wrong answers have to stay on the continent

Germany's 16 states: two have no capital at all

The query that timed out

Labels are not display names

Try it

30 execution controls for algorithmic trading systems, each tied to evidence and a failure mode

Governance

Data integrity

Pre-trade risk

Execution lifecycle

Human control

Operations and evidence

Source synthesis

Use and limits

Data

How long until a missed heartbeat is flagged? A reproducible detection timing table

Detection timing by expected heartbeat interval

How the table was produced

Interpretation and limits

Data and reproduction

How we keep a social media scheduler from double-posting: a 200-process contention test

Method

Result

What this does and does not show

Data

A production readiness matrix for n8n and AI workflows: 32 checks

Ownership and scope

Inputs and data

Execution and recovery

AI behavior

Security and privacy