When AI Rules Cross Organizational Boundaries
Most AI rules stay within one organization. But some scenarios require cross-org sharing: a parent company with subsidiaries (the parent defines security standards that all subsidiaries must follow), an agency managing multiple clients (the agency's quality standards apply to all client projects — see the agency case study), partner organizations collaborating on a shared platform (both partners need consistent API conventions), and an open source organization distributing rules to community contributors (the project's conventions shared with all contributors).
The cross-org challenge: each organization has its own: git hosting (different GitHub orgs, different GitLab instances), access controls (different permissions, different team structures), technology stacks (different frameworks, different languages), and governance (different approval processes for rule changes). The cross-org sync: must respect these boundaries while delivering shared rules to all organizations.
The cross-org model: a shared ruleset (maintained by the parent/agency/coordinator) distributed to receiving organizations. The receiving org: gets the shared rules + adds their own organization-specific rules. The shared rules: read-only in the receiving org (changes go through the coordinator). The org-specific rules: fully owned by the receiving org. This model: provides consistency (shared rules) with autonomy (org-specific rules).
Step 1: Cross-Org Distribution Architecture
Option 1 — Git-based sharing: the shared rules live in a git repository accessible to all organizations. For GitHub: a public repo (if the rules are not sensitive) or a repo shared via GitHub's organization-to-organization collaboration features. For GitLab: a shared group or project. Each receiving org: clones or forks the shared repo, adds their org-specific rules, and pulls updates from the shared repo periodically. This model: uses familiar git workflows. No additional infrastructure needed.
Option 2 — npm package sharing: the shared rules published as an npm package (@parent-org/ai-rules). Each receiving org: installs the package (pnpm add -D @parent-org/ai-rules). The postinstall: copies the shared rules to the project root. Org-specific rules: in a separate section of the CLAUDE.md (not managed by the package). This model: uses familiar npm workflows. Version pinning: ensures each org controls when they adopt updates.
Option 3 — RuleSync cross-org sharing: RuleSync supports sharing rulesets between organizations. The parent org: publishes a shared ruleset. The receiving org: subscribes to the shared ruleset (read-only). RuleSync: handles distribution, versioning, and adoption tracking across organizations. Org-specific rules: maintained as separate rulesets in each receiving org, composed with the shared ruleset. AI rule: 'Git-based: simplest, no extra tools. npm: familiar to JS/TS teams. RuleSync: most feature-rich (versioning, tracking, composition). Choose based on organizational tooling.'
The parent org publishes @parent-org/ai-rules to a private npm registry. Each subsidiary: pnpm add -D @parent-org/ai-rules. The postinstall: copies the shared rules. The subsidiary: adds their own rules in a separate section. Updates: pnpm update @parent-org/ai-rules. The version: pinned in the lockfile. This workflow: identical to how subsidiaries already consume shared libraries from the parent org. No new tools. No new concepts. Just another npm package.
Step 2: Cross-Org Governance
Who controls the shared rules: the coordinating organization (parent company, agency, or lead partner). They: maintain the shared ruleset, publish updates, communicate changes, and accept feedback from receiving orgs. Receiving organizations: follow the shared rules, add their own org-specific rules, provide feedback on shared rules, and adopt updates at their own pace (within an agreed window).
Change communication across orgs: shared rule changes must be communicated to all receiving orgs. Communication protocol: announce the change 2 weeks before deployment (email to receiving org tech leads), provide the changelog (what changed, why, and impact), allow a feedback period (1 week for receiving orgs to raise concerns), and deploy after the feedback period. The protocol: more formal than within-org communication because cross-org changes affect teams you do not manage directly.
Adoption windows: receiving orgs need time to adopt shared rule changes. Agreed window: 30 days for minor changes, 90 days for major changes. The window: starts when the change is announced. Within the window: the receiving org is expected to update. After the window: the coordinating org may follow up. The window: balances timeliness (rules should be current) with autonomy (receiving orgs manage their own schedules). AI rule: 'Cross-org governance: more formal than within-org. Longer timelines. More communication. More respect for autonomy. The shared rules: a partnership, not a mandate.'
Within one org: a rule change can be announced and deployed in the same day (the team sees the Slack message and pulls the update). Across orgs: different teams, different schedules, different time zones, different priorities. A same-day deployment: catches receiving orgs off guard. Tech leads: did not review the change. Teams: surprised by different AI output. Trust: damaged. The 2-week advance notice: gives every receiving org time to review, prepare, and adopt. Cross-org: always slower and more formal than within-org.
Step 3: Security and Access Control
Access control: the shared rules repository or package: readable by all receiving orgs. Writable: only by the coordinating org. Receiving orgs: cannot modify the shared rules directly (they propose changes to the coordinating org). For git-based sharing: branch protection on the shared repo (only the coordinating org can merge to main). For npm: only the coordinating org publishes to the package registry. For RuleSync: the shared ruleset has org-level write permissions.
Sensitive rules: some shared rules may contain organization-specific details (internal API endpoints, proprietary architecture patterns). These: should be in the org-specific rules, not the shared rules. The shared rules: generic enough to be applicable across organizations. If a shared rule references an internal service: replace with a placeholder ('use the organization's authentication service' instead of 'use auth.internal.parent-company.com').
Audit trail: for compliance-driven organizations (fintech, healthcare, government): the cross-org rule distribution must be auditable. Who changed the shared rules? When? Who approved? Which receiving orgs adopted the change? When? RuleSync: provides this audit trail natively. Git-based: use git log and the adoption tracking workflow. npm: use package version history and lockfile tracking. AI rule: 'Compliance-driven organizations: need audit trails for cross-org rule distribution. Choose a distribution method that provides: change history, approval records, and adoption tracking.'
Shared rule: 'All API endpoints require authentication.' Good — applies to every organization. Shared rule: 'Use auth.internal.parent-company.com for authentication.' Bad — the subsidiary has a different auth service. The shared rule: should specify the convention (authentication required) without specifying the implementation detail (which auth service). The implementation detail: in the org-specific rules. This separation: makes shared rules universally applicable while org-specific rules handle the local details.
Cross-Org Sync Summary
Summary of syncing AI rules across multiple organizations.
- Scenarios: parent-subsidiary, agency-client, partner collaboration, open source community
- Model: shared rules (read-only, from coordinator) + org-specific rules (owned by each org)
- Distribution: git repo (simplest), npm package (familiar to JS teams), RuleSync (most features)
- Governance: coordinator controls shared rules. Receiving orgs provide feedback + adopt on schedule
- Communication: 2-week advance notice, changelog, 1-week feedback period, then deployment
- Adoption windows: 30 days for minor changes, 90 days for major. Balances timeliness with autonomy
- Security: shared rules writable only by coordinator. Org-specific details in org rules, not shared
- Audit: change history, approval records, adoption tracking. Required for compliance-driven orgs