DEV Community: Victor Laybats

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

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

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

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

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

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.