<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Making Data Systems Behave - failure-latency</title><link>https://makingdatabehave.com/</link><description/><atom:link href="https://makingdatabehave.com/failure-latency/feed.xml" rel="self"/><lastBuildDate>Wed, 22 Jul 2026 14:15:24 +0100</lastBuildDate><item><title>Reducing Failure Latency in the System You Already Have</title><link>https://makingdatabehave.com/failure-latency/6</link><description>&lt;p&gt;Reduce failure latency in an existing pipeline one recurring failure at a time, without waiting for a platform rebuild.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Rob Wilson</dc:creator><pubDate>Thu, 11 Jun 2026 00:00:00 +0100</pubDate><guid>tag:makingdatabehave.com,2026-06-11:/failure-latency/6</guid><category>failure-latency</category><category>data-engineering</category><category>dataops</category><category>data-architecture</category><category>data-governance</category><category>data-quality</category></item><item><title>Governance by Design: Evidence as a Side Effect</title><link>https://makingdatabehave.com/failure-latency/5</link><description>&lt;p&gt;Pipelines produce governance evidence naturally when controls change behaviour, states are named and every exception leaves a usable run record.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Rob Wilson</dc:creator><pubDate>Thu, 04 Jun 2026 00:00:00 +0100</pubDate><guid>tag:makingdatabehave.com,2026-06-04:/failure-latency/5</guid><category>failure-latency</category><category>data-engineering</category><category>dataops</category><category>data-architecture</category><category>data-governance</category><category>data-quality</category></item><item><title>Implementation Patterns for Reducing Failure Latency</title><link>https://makingdatabehave.com/failure-latency/4</link><description>&lt;p&gt;Reduce failure latency with cheap structural gates, contextual checks, explicit exception states, ownership and publication controls.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Rob Wilson</dc:creator><pubDate>Thu, 28 May 2026 00:00:00 +0100</pubDate><guid>tag:makingdatabehave.com,2026-05-28:/failure-latency/4</guid><category>failure-latency</category><category>data-engineering</category><category>dataops</category><category>data-architecture</category><category>data-governance</category><category>data-quality</category></item><item><title>Data Contracts as Executable Boundary Definitions</title><link>https://makingdatabehave.com/failure-latency/3</link><description>&lt;p&gt;Data contracts reduce failure latency when they turn boundary expectations into executable checks that can change what the pipeline does next.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Rob Wilson</dc:creator><pubDate>Thu, 21 May 2026 00:00:00 +0100</pubDate><guid>tag:makingdatabehave.com,2026-05-21:/failure-latency/3</guid><category>failure-latency</category><category>data-engineering</category><category>dataops</category><category>data-architecture</category><category>data-governance</category><category>data-quality</category></item><item><title>Shift Left Isn't Enough: Validation Belongs at Boundaries</title><link>https://makingdatabehave.com/failure-latency/2</link><description>&lt;p&gt;Place each validation check at the first pipeline boundary with enough context to trust the result and change what happens next.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Rob Wilson</dc:creator><pubDate>Thu, 14 May 2026 00:00:00 +0100</pubDate><guid>tag:makingdatabehave.com,2026-05-14:/failure-latency/2</guid><category>failure-latency</category><category>data-engineering</category><category>dataops</category><category>data-architecture</category><category>data-governance</category><category>data-quality</category></item><item><title>Failure Latency: Why Pipelines Discover Bad Data Too Late</title><link>https://makingdatabehave.com/failure-latency/1</link><description>&lt;p&gt;Failure latency measures how long a detectable data problem remains hidden and shows where pipeline controls should surface it sooner.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Rob Wilson</dc:creator><pubDate>Thu, 07 May 2026 00:00:00 +0100</pubDate><guid>tag:makingdatabehave.com,2026-05-07:/failure-latency/1</guid><category>failure-latency</category><category>data-engineering</category><category>dataops</category><category>data-architecture</category><category>data-governance</category><category>data-quality</category></item></channel></rss>