<?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</title><link>https://makingdatabehave.com/</link><description/><atom:link href="https://makingdatabehave.com/feed.xml" rel="self"/><lastBuildDate>Wed, 22 Jul 2026 14:20:41 +0100</lastBuildDate><item><title>Unreviewed Output Is Provisional Output</title><link>https://makingdatabehave.com/refresh-cadence/2</link><description>&lt;p&gt;Frequent pipeline runs can create provisional output faster than controls, consumers and recovery processes can accept it.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Rob Wilson</dc:creator><pubDate>Wed, 22 Jul 2026 00:00:00 +0100</pubDate><guid>tag:makingdatabehave.com,2026-07-22:/refresh-cadence/2</guid><category>refresh-cadence</category><category>data-engineering</category><category>dataops</category><category>data-architecture</category><category>data-governance</category><category>data-quality</category></item><item><title>Why Treasury Liquidity Looks Like a Digital Twin Problem</title><link>https://makingdatabehave.com/treasury/1</link><description>&lt;p&gt;Treasury liquidity behaves like a time-dependent network: usable cash depends on where value sits, which routes remain available and whether it can arrive before it is needed.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Rob Wilson</dc:creator><pubDate>Wed, 22 Jul 2026 00:00:00 +0100</pubDate><guid>tag:makingdatabehave.com,2026-07-22:/treasury/1</guid><category>treasury</category><category>data-engineering</category><category>dataops</category><category>data-architecture</category><category>treasury</category><category>liquidity</category></item><item><title>Refresh Cadence Is a Design Decision</title><link>https://makingdatabehave.com/refresh-cadence/1</link><description>&lt;p&gt;Choose pipeline cadence from source change, consumption, recovery and cost rather than treating frequent execution as a default.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Rob Wilson</dc:creator><pubDate>Fri, 19 Jun 2026 00:00:00 +0100</pubDate><guid>tag:makingdatabehave.com,2026-06-19:/refresh-cadence/1</guid><category>refresh-cadence</category><category>data-engineering</category><category>dataops</category><category>data-architecture</category><category>data-governance</category><category>data-quality</category></item><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>Design for Determinism</title><link>https://makingdatabehave.com/governance-by-design/1</link><description>&lt;p&gt;Deterministic pipelines make historical outputs reconstructable by pinning inputs, logic, reference data and lineage to each run.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Rob Wilson</dc:creator><pubDate>Tue, 26 May 2026 00:00:00 +0100</pubDate><guid>tag:makingdatabehave.com,2026-05-26:/governance-by-design/1</guid><category>governance-by-design</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>