You wrote the guideline. “Only use approved packages from the internal registry.” Clean, clear, enforceable.

Then someone added three new packages to the registry last Tuesday. Your guideline doesn’t know. It’s still enforcing against a list you pasted in two months ago.

Your governance is only as current as the last time someone manually updated it. And nobody ever updates it.

This is the quiet failure mode of static enforcement. The rule is right. The data behind it is wrong. And every scan, every PR check, every compliance report is running against yesterday’s reality.

Today, we’re fixing that.

Every Hardcoded List Is a Lie Waiting to Happen

Think about what lives inside your guidelines right now.

• A list of approved npm or pip packages, copied from a registry snapshot
• A set of internal API routes, pulled from a service catalog that changes weekly
• Approved configuration flags, exported from a feature flag system that your platform team updates constantly
• Allowed database connection strings, maintained in a shared config that drifts every sprint

Every one of these is a snapshot. A frozen moment. And the second your source of truth changes – a new service goes live, a package gets deprecated, a config flag gets retired – your guideline is enforcing fiction.

The irony is brutal: the more actively your engineering org evolves, the faster your governance falls behind. The best teams suffer the most from this problem because they move the fastest.

This isn’t a theoretical risk. It’s happening right now in your codebase. Code is passing checks that should fail. Code is failing checks it should pass. And nobody knows, because the guideline looks right – it’s just pointing at stale data.

Configuration drift is a major source of refactoring and slow release cycles across engineering organizations. And Gartner has found that 99% of cloud security failures are the customer’s fault, primarily due to misconfigurations. The data is clear: when your source of truth drifts from reality, bad things happen.

Governance That Talks to Your Live Systems

This is the core idea behind Dynamic Context Providers: your guidelines should never enforce against hardcoded data when a live source of truth exists.

Dynamic Context Providers let you connect an external data source directly to any guideline. Instead of pasting a static list into a guideline description, you point the guideline at the system that owns that data. Every time the guideline runs – on a PR check, on a repo scan, on a compliance audit – it fetches the latest context from your actual source of truth.

Your approved package list lives in your internal registry? The guideline asks the registry directly.

Your API routes live in a service catalog? The guideline queries the catalog at evaluation time.

Your config flags are managed in LaunchDarkly or a custom system? The guideline pulls the current flag set before it evaluates a single line of code.

No copy-pasting. No manual syncing. No stale snapshots. Your governance talks to your live systems, every single time it runs.

Setting It Up Takes Minutes, Not Migrations

You can configure a Dynamic Context Provider directly in the Pandorian UI when creating or editing any guideline. There’s no infrastructure to deploy, no webhooks to wire up, no YAML to write.

Here’s what you define:

• Title – A descriptive name so your team knows what this provider does (e.g., “Approved Config Flags” or “Internal API Routes”)
• Command – The exact command Pandorian executes to fetch the data, like a curl request to your internal API, configuration server, or package registry
• Grep – An optional regex filter applied to the command output, so only the specific data you need is passed as context to the guideline evaluation
• Timeout – The maximum seconds Pandorian waits for your source to respond before timing out, keeping your pipeline fast even if an external system is slow

That’s it. Four fields. Your guideline is now connected to a live data source, and every evaluation pulls fresh context automatically.

What This Looks Like in Practice

Package governance that stays current. You have a guideline that says “Only use approved packages.” Instead of maintaining a hardcoded list that’s outdated the moment a new package is approved, the Dynamic Context Provider fetches the current approved list from your internal registry every time the guideline runs. A developer adds a newly approved package? It passes immediately. No waiting for someone to update a doc.

API route enforcement that evolves with your architecture. Your service catalog is the source of truth for internal API endpoints. A Dynamic Context Provider queries it directly, so your guideline always knows which routes are valid, which are deprecated, and which were just added last hour. Your codebase context is always accurate.

Config flag validation that never goes stale. Your platform team manages feature flags in a central system. A Dynamic Context Provider pulls the active flag set at evaluation time, ensuring your guidelines catch references to retired flags and recognize newly created ones – without anyone touching the guideline itself.

Allowed infrastructure patterns that reflect reality. Database connection strings, allowed cloud regions, permitted Terraform modules – anything managed in a central system can be connected. Your coding standards enforcement reflects your infrastructure as it actually is, not as it was when someone last had time to update a wiki page.

From Static Rules to a Living Governance System

Static guidelines made sense when codebases changed slowly and teams were small enough that tribal knowledge could fill the gaps. That world is gone.

Today, engineering orgs run hundreds of services, deploy dozens of times a day, and use AI agents that ship code faster than any human can review. Research shows that roughly 41% of all code written today is AI-generated, with 92% of developers using AI tools in their workflow. In that world, a governance system that relies on manually maintained lists isn’t just incomplete – it’s actively misleading.

Dynamic Context Providers represent a fundamental shift in how governance works. Your guidelines stop being static documents that describe what was true. They become live queries that enforce what is true. Right now. Every time.

Your governance should be as dynamic as the systems it governs. Now it is.

Written by Daniel Avital – CEO & Co-Founder at Pandorian.

Related Reading

• Code Review vs. Codebase Governance: Why Speed Isn’t the Same as Control
• New Feature: Turn Your Agent Skills Files into Powerful CI Enforcement Rules
• New Feature: Turn Your Incident Reports into Powerful Code Guardrails Instantly
• New Feature: Turn Confluence and Docs into Live Code-Wide Guardrails
• Why Codebase Context Matters
• How To Enforce Your Engineering Standards Across Your Codebase
• Why You Should Be Versioning Guidelines Like Code
• Explore the Pandorian Platform