On AI, Guardrails, and why what we write in Confluence and Jira matters more than it ever did.

In the first post in this series, I wrote about AI already being in the building - in every function, in every tool, drawing from whatever context it can find. And I introduced two ideas: UX Guardians (the shift in how we think about our role) and Guardrails (the mechanism we build to make sure AI tools work from the right product knowledge, not a guess).

This post is about the part I left open: where does that knowledge actually live, what does it take to build a Guardrail that actually works, and what happens to the output AI generates?

The short answer to the first question is: it lives where it already should - in Confluence, Jira, and JPD. But AI changes what those tools are for, and it changes how seriously we take what we put in them. The second and third questions take longer to answer properly, and they’re where most of the real skill in this role actually lives.

The knowledge problem, stated plainly

Every product team I’ve worked with has some version of this problem: the real knowledge - the research that shaped the product, the decision log behind the edge case, the design rationale that explains why we built it this way and not that way - lives in someone’s head, a folder no one navigates to, or a doc that was accurate eighteen months ago.

And that’s just the upstream knowledge. The downstream signal layer - product usage data, feature adoption rates, the support tickets that reveal where users are quietly struggling, the behavioural patterns that show the gap between what we designed and what people actually do - is even harder to keep current and accessible. It sits across dashboards, analytics tools, support queues, and monthly reports that rarely make it back into the places where decisions get made.

UX sits at the intersection of both. We’re the function that analyses what we know about users before we build, and what the product is actually doing to users after we ship. That combination is the most complete view of product reality anyone on the team has. It’s also the most underused source of AI context in most teams right now.

It gets away from you. Teams move fast, tickets get closed, reports get filed, and the institutional knowledge quietly decouples from the tools people are actually working in day to day.

That was always a problem. With AI in every function’s toolkit, it becomes a critical one.

If your Confluence pages are thin, your AI’s context is thin. If your Jira tickets are written as shorthand that only makes sense if you were in the room, your AI is working from shorthand. If your JPD product discovery work isn’t connected to live usage data and the support patterns that preceded it, you’re asking AI to make decisions with half the picture. And it will. Confidently.

What the loop actually looks like

Here’s the model I’m working toward - and it has a human in the middle of it by design.

Step 1: Build the Guardrails from what we already know

Before AI is useful in any function, the right context has to exist in a form it can use. That means working with each function to make sure the foundational knowledge is in the right place - Confluence for research syntheses, design rationale, product principles, decision logs, personas, usage analysis, and support pattern summaries; Jira for tickets with enough context to be meaningful outside a sprint ceremony; JPD for the discovery layer connected to both research and post-ship signals.

That much is the “what.” The harder part is the “how” - and I want to be specific about it, because getting this step wrong quietly undermines everything downstream of it.

Building a Guardrail is a design skill, not a data dump. A few things I’ve learned doing this that I’d want any of us to internalise:

• Specificity beats volume. Handing an AI tool every research report we’ve ever written isn’t a Guardrail - it’s noise with good intentions. A tightly scoped set of the right documents outperforms a large loosely-related pile, every time. Part of the job is deciding what’s relevant enough to include and being willing to leave things out.

• Say what “good” looks like, not just what’s true. A document that lists facts about our users is useful. One that also says “when in doubt, prioritise clarity over completeness for this user group” is far more useful, because it gives the AI a principle to apply to situations the facts alone don’t cover. The best Guardrails carry judgment, not just data.

• Write for the gaps, not just the knowns. Think about what happens when an AI tool hits a question the documentation doesn’t answer. Left unaddressed, it will improvise - confidently, and not always well. Good context-building anticipates the gap and either fills it or explicitly flags it as “escalate, don’t guess.”

• Structure is not optional. A well-written paragraph buried in an unstructured wall of text is nearly as inaccessible to an AI tool as it is to a colleague skimming a doc for the first time. Headers, explicit labels, a clear “this is the conclusion” marker - the same scanability we’d want in anything written for humans matters just as much here, arguably more, because the AI doesn’t have the option of asking someone to clarify.

I learned the first of these the hard way. Early on, I built a Guardrail for a particular product area by including everything I could find - every research report, every related ticket, months of material. The output that came back was technically accurate and completely useless: it hedged on everything, because there was no signal for what actually mattered most among all that material. I’d mistaken volume for context. The fix wasn’t adding more - it was cutting hard, down to the handful of documents that captured current thinking, plus one line stating the priority when things conflicted. The output got sharper immediately. I’d built a library when the tool needed a briefing.

One more question belongs in this step, and it’s substantial enough that it gets its own post later in this series: is this information safe to include at all? Specific, detailed, reflective of real users and real decisions is exactly what makes something a good Guardrail - and exactly what makes it worth protecting. More on how I think Guardians should reason about that in Post 4.

These aren’t new documents we’re creating from scratch. They’re the documents we were already supposed to be writing - and in UX’s case, the reports and analyses we were already producing. AI just makes the cost of not writing them properly, and not writing them well, much higher than it used to be.

Step 2: AI works with the context we’ve built

Each function uses AI tools inside their own workflow - engineering in their coding environment, PMs drafting briefs and summaries, PMMs generating copy and messaging. The Guardrails point those tools toward the right Confluence spaces, Jira project data, and JPD discovery work for their product.

The output is faster, more contextually grounded, and less likely to introduce terminology, patterns, or assumptions that contradict what the product team already knows.

This is where the productivity gain is real: not AI replacing the work, but AI doing the first pass with actual product context instead of generic pattern-matching. And it’s also where the quality of Step 1 shows up directly - a well-built Guardrail gets a usable answer fast; a poorly built one means everyone who touches that context pays for it, repeatedly, until someone fixes it.

Step 3: The Guardian reviews before it commits

Here’s the step that doesn’t get skipped.

AI output - a generated brief, a synthesised insight, a component suggestion, a batch of copy - does not go directly back into the source of truth. It goes to the Guardian first.

It’s tempting to describe this step as “fact-check it.” That undersells what’s actually involved. A Guardian reviewing AI output is making four separate judgment calls, and conflating them is where the role goes wrong:

• Is this accurate? The baseline check - does it match what the team actually knows.

• Is this well-scoped? Even accurate output can be too broad, too narrow, or quietly answering a slightly different question than the one that was asked.

• Is this genuinely new, or does it just sound confident? AI is very good at producing plausible synthesis from thin material. Telling “real insight” apart from “fluent restatement” is the hardest judgment call in the role, and the one most people skip by default.

• Where does this belong? A good insight filed in the wrong place - a ticket instead of a Confluence page, or vice versa - is nearly as useless as a wrong insight, because the next person looking for it won’t find it.

Most people, left unprompted, only do the first check. That’s not being a Guardian. That’s proofreading.

This curation step is not a bottleneck. It’s the quality gate. Without it, AI outputs start feeding back into AI inputs, the source of truth degrades quietly, and within a few cycles you have confident, fast, wrong.

The Guardian is what prevents that loop from compressing into noise.

Step 4: The source of truth gets better over time

What’s committed back to Confluence, Jira, and JPD is better than what was there before — because it’s been tested against AI output, reviewed by a human who knows the product, and written in a form that’s explicit enough to survive the next AI interaction.

The Confluence page that documents a user research finding gets more precise. The Jira ticket template evolves to include the fields that actually matter for AI context. The JPD discovery record grows richer as the Guardian routes the right insights back in.

Over time, the source of truth becomes self-improving not because AI writes it, but because the Guardian loop forces the team to be more explicit about what they know than they would otherwise bother to be.

What this means for the reports and tickets we create

This is the part worth sitting with.

The research report you write isn’t just a deliverable for a stakeholder presentation anymore. It’s context for every AI-assisted decision your PM makes for the next six months. The usage analysis you run each month isn’t just a snapshot for a team meeting. It’s the behavioural evidence layer that tells AI what users actually do, not what we assumed they would do. The support ticket pattern you surface isn’t just a signal for the next roadmap conversation. It’s the failure map that stops AI from generating solutions to the wrong version of the problem.

The question isn’t just “did I write this?” It’s “did I write this well enough that AI can use it correctly without me in the room?”

That’s a higher bar. It means:

• Research reports need explicit, extractable conclusions not just methodology and findings but a clear “this is what this means for the product” layer that AI can reference without interpretation

• Usage analysis needs to be documented, not just presented insights that only exist in a slide deck or a meeting summary can’t be Guardrails; they need to live in Confluence in a form that’s searchable, structured, and connected to the product area they describe

• Support ticket patterns need to be synthesised and routed individual tickets are noise; the pattern across them is signal. The Guardian’s job is to read that signal, synthesise it, and write it back into the knowledge base where it belongs connected to the relevant JPD opportunity or the relevant Confluence product page

• Confluence pages need to be living documents, updated when decisions change and when post-ship reality contradicts pre-ship assumptions

• Jira tickets need enough context to stand alone - the “everyone knows what this means” shorthand breaks the moment AI is working from it

• JPD work needs to connect the dots between discovery, research, design decisions, delivery, and the usage data that came after because AI working from a disconnected slice of that chain will fill the gaps itself, and it won’t fill them the way you would

None of this is extra work for its own sake. It’s the work that was always worth doing - AI just made it impossible to defer.

Why trust between functions is now structural

When each function’s AI tools are drawing from a shared pool of institutional knowledge and when each function’s Guardian is contributing back to that pool, the quality of your AI outputs becomes a collective responsibility.

If the research synthesis in Confluence is out of date, the PM’s AI brief will be wrong. If the Jira tickets are written as shorthand, the engineering AI will build to incomplete context. If the JPD discovery work isn’t connected to real usage data, the strategic layer is operating on assumption.

This is dependency, and it’s a different kind of dependency than we’re used to. A wrong conclusion in a stakeholder presentation gets caught in the room. A weak Guardrail can travel for months before anyone traces a downstream problem back to its source - quietly shaping decisions across functions, with no one quite sure why the outputs feel slightly off. Being trusted to build and review Guardrails means being trusted with judgment other people can’t easily audit in the moment. That’s worth taking seriously, and worth being honest with the team about how much trust that actually is.

The Guardians, in every function, are the people who maintain that trust operationally. They’re the ones who review before committing, who flag when the source of truth is drifting, who say “this AI output is wrong and here’s why,” and who take the time to write it back properly so the next interaction is better than the last.

The through-line

AI doesn’t replace the knowledge. It amplifies whatever knowledge exists. If the knowledge in your Confluence, Jira, and JPD is good, accurate, current, explicit, connected, AI makes your team faster and more coherent. If it’s thin, siloed, or stale, AI makes those problems bigger and faster.

The Guardrails aren’t a technical setup. They’re a commitment to the quality of shared knowledge, built with real skill and reviewed with real judgment. And the Guardians aren’t a new job title. They’re the people who take that commitment seriously, in every function, every sprint.

This is the second post in the UX Guardians series. Start with the first post →