Standing compliance rules that travel with the output

A compliance rule that lives in a system prompt travels only as far as that prompt. When the work moves to a different AI tool, a different session, or a different team member, the prompt doesn't follow — and neither does the compliance rule.

This is the portability problem for AI compliance. Most orgs handle it by having compliance rules in multiple places: embedded in the tools the compliance team controls, written in guides that non-compliance staff are supposed to follow, and informally communicated as things everyone is expected to know. The result: coverage that's complete in the ideal case and patchwork in practice.

The rule that governs all contexts

A standing compliance rule — say, a requirement that any customer communication about a financial product include a specific regulatory disclosure — applies regardless of which tool the writer is using, which session they're in, or whether they remembered to include the compliance guide.

When that rule is stored as a Memory Stack memory, tagged for the relevant users and contexts, it loads automatically. The writer using Claude loads it. The writer using ChatGPT loads it. The agent running automated communications loads it. The rule doesn't depend on the tool; it depends on the memory layer that every tool loads from.

This is the meaningful difference between a prompt-embedded rule and a memory layer rule: the former is scoped to a specific tool and session configuration; the latter follows the work wherever it goes.

Cross-tool compliance in mixed stacks

Enterprise teams run mixed AI stacks. Engineering uses one set of tools; legal and compliance use another; sales and marketing use a third. A compliance rule that needs to apply to all of them can't live in any one tool's configuration.

Memory Stack connects to Claude, ChatGPT, Cursor, and Copilot through native integration paths. A compliance rule stored in Memory Stack is available in all of them. When the legal team updates a disclosure requirement, the update propagates to every tool that loads the relevant rule — at session init speed, not at documentation refresh speed.

The team member using Cursor doesn't need to know that the disclosure requirement changed. They need to know it's in their context. The infrastructure ensures it is.

Versioning for compliance

Compliance rules change. Regulations update. Internal policies are revised. In a standard prompt-embedded setup, rule changes require prompt updates, which require the engineering cycle that governs prompt changes. By the time the rule propagates through that cycle, sessions that ran against the old rule may have produced output that's no longer compliant.

Memory Stack rules are versioned. Every update to a rule produces a new version with the timestamp and the author of the change. Session logs cite the rule ID and version that was active at session time.

This creates a compliance-ready audit trail: a session that ran before a rule update loaded version N; a session that ran after loaded version N+1. The distinction is auditable. The output produced under each version is traceable to the rule that governed it.

The scope question

Not every compliance rule applies to every context. Disclosure requirements for customer communications don't apply to internal engineering sessions. Data handling rules for PII don't apply to sessions that don't process personal data.

Memory Stack's tagging system handles scope: rules are tagged for the contexts, roles, and agent types where they apply. A disclosure rule tagged compliance:customer-comms loads for marketing and sales sessions; it doesn't load for engineering sessions. A PII handling rule tagged compliance:data-processing loads for sessions that work with customer data.

The scope is explicit and reviewable — a compliance team can see which rules apply to which contexts and verify that the coverage is correct. Gaps in the tagging are visible; coverage is not assumed.

The honest version

Rules loaded at session start govern the session. Sessions that run outside the Memory Stack integration — a team member who hasn't connected their tool, a new tool that doesn't yet have the integration configured — run without those rules loaded. Coverage is a function of integration breadth.

For compliance requirements that are absolute — there is no acceptable context where the rule doesn't apply — the coverage question needs to be managed at the onboarding level: every team member using AI tools for relevant work needs the integration configured. Memory Stack closes the portability gap; getting it in front of every relevant tool is an organizational configuration task.

Compliance rules that don't follow the work don't enforce themselves. The infrastructure that makes them portable — stored as versioned, attributed memories, loadable by any connected tool — is the difference between compliance that works at deployment scale and compliance that works only when someone remembered to include the right document.