<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title><![CDATA[StreamPath NexLab]]></title>
  <link>./</link>
  <description><![CDATA[StreamPath NexLab is a Portland-based consultancy specialising in process audits, data pipeline reviews, and workflow design for operations-heavy organisations.]]></description>
  <language>en</language>
  <atom:link href="./feed.xml" rel="self" type="application/rss+xml" />
  <item>
    <title><![CDATA[How to run a process audit that finds real problems]]></title>
    <link>./notes/how-to-run-a-process-audit.html</link>
    <guid>./notes/how-to-run-a-process-audit.html</guid>
    <description><![CDATA[A process audit sounds straightforward: look at how work moves, find what is slow or broken, write it down. In practice, the hard part is not the analysis. It is getting to the real process rather than the one people think they are supposed to describe. This guide covers how we approach that problem.]]></description>
    <pubDate>2026-05-20</pubDate>
  </item>
  <item>
    <title><![CDATA[Silent failures in data pipelines and how to find them]]></title>
    <link>./notes/data-pipeline-silent-failures.html</link>
    <guid>./notes/data-pipeline-silent-failures.html</guid>
    <description><![CDATA[The most dangerous data pipeline problems are not the ones that throw an error. They are the ones that complete successfully and return a wrong answer. A join that silently drops 3% of rows. A schedule that stopped refreshing two weeks ago. A transform that handles nulls differently depending on the source system. These failures are hard to find because nothing breaks visibly.]]></description>
    <pubDate>2026-04-11</pubDate>
  </item>
  <item>
    <title><![CDATA[Workflow design for teams that have outgrown their process]]></title>
    <link>./notes/workflow-design-growing-teams.html</link>
    <guid>./notes/workflow-design-growing-teams.html</guid>
    <description><![CDATA[There is a point in most growing teams where the process that worked at ten people stops working at twenty-five. It is not a sudden break. It is a slow accumulation of workarounds, informal tools, and decisions that used to be obvious and now need to be explained. By the time it becomes a crisis, the team has usually been compensating for months.]]></description>
    <pubDate>2026-03-05</pubDate>
  </item>
  <item>
    <title><![CDATA[Why your team makes the same decision differently every time]]></title>
    <link>./notes/decision-frameworks-operations.html</link>
    <guid>./notes/decision-frameworks-operations.html</guid>
    <description><![CDATA[If you have ever noticed that the same type of decision gets made differently depending on who is in the room, the problem is rarely that some people are making it wrong. It is that the logic for making it correctly is in someone's head rather than on paper. That is a documentation problem, and it is fixable.]]></description>
    <pubDate>2026-02-18</pubDate>
  </item>
  <item>
    <title><![CDATA[When to hire an outside consultant and when not to]]></title>
    <link>./notes/when-to-hire-a-consultant.html</link>
    <guid>./notes/when-to-hire-a-consultant.html</guid>
    <description><![CDATA[This is a question we get asked, sometimes directly and sometimes sideways. The honest answer is that outside help is useful in specific situations and not useful in others. Knowing the difference saves time and money on both sides.]]></description>
    <pubDate>2026-01-28</pubDate>
  </item>
</channel>
</rss>
