The six-layer model
Patterson’s org chart has four tiers above the code — enterprise, sub-organization, department, team — and two below it that belong to the developer rather than to the organization: the repository and the user.
| # | Layer | Owner | Claude Code mechanism | Demonstrated here |
|---|---|---|---|---|
| 1 | Enterprise | Patterson Companies | managed-settings.d/10-enterprise.json |
Yes |
| 2 | Sub-organization | Dental, Vet | managed-settings.d/20-suborg.json |
Yes |
| 3 | Department | Engineering, Marketing | managed-settings.d/30-department.json |
Yes |
| 4 | Team | an individual team | managed-settings.d/40-team.json |
Yes |
| 5 | Repository | the repo’s maintainers | .claude/settings.json (checked in) |
No |
| 6 | User | the developer | ~/.claude/settings.json |
No |
Layers 5 and 6 are described but not shipped. .claude/settings.json is project settings “checked
into source control and shared with your team” and ~/.claude/settings.json is user settings that
“apply to all projects” (CC-settings § Settings files). Neither is Patterson’s to write from a
central catalog.
The precedence runs opposite to the org chart
Section titled “The precedence runs opposite to the org chart”This is the part that surprises people. Layers 1 through 4 do not sit at four different precedence
levels. They all live inside a single precedence slot — the managed tier — which is the highest
of all five scopes and “cannot be overridden by any other level, including command line arguments”
apart from a short list of security-sensitive exceptions (CC-settings § Settings precedence).
| Precedence | Scope | Which of the six layers |
|---|---|---|
| 1 (highest) | Managed settings | Layers 1-4, merged into one effective policy |
| 2 | Command line arguments (--settings) |
none |
| 3 | Local project settings (.claude/settings.local.json) |
none |
| 4 | Shared project settings (.claude/settings.json) |
Layer 5 |
| 5 (lowest) | User settings (~/.claude/settings.json) |
Layer 6 |
Source: CC-settings § Settings precedence.
So the organizational hierarchy is not expressed by precedence at all. It is expressed by merge order inside one scope — which is why the whole demonstration turns on constraint 1 below.
Between scopes 3 to 5, array-valued settings such as permissions.allow are “concatenated and
deduplicated, not replaced”, so a lower-priority scope can add entries without overriding a higher
one; fallbackModel and a managed availableModels are the stated exceptions (CC-settings
§ Settings precedence, “Array settings merge across scopes”).
The same six layers on the other two platforms
Section titled “The same six layers on the other two platforms”| Layer | Claude Code | VS Code | GitHub Copilot |
|---|---|---|---|
| 1 Enterprise | managed-settings.d/ fragment |
Copilot managed settings policies (ChatEnabledPlugins, ChatExtraMarketplaces, ChatStrictMarketplaces) |
Enterprise policies exist; enterprise instructions do not |
| 2 Sub-org | managed-settings.d/ fragment |
[TBD: not specified in VSC-enterprise] — no per-tier fragment mechanism documented |
Organization policies and organization custom instructions |
| 3 Department | managed-settings.d/ fragment |
[TBD: not specified in VSC-enterprise] |
[TBD: not specified in GHC-precedence] — no tier between organization and repository |
| 4 Team | managed-settings.d/ fragment |
[TBD: not specified in VSC-enterprise] |
[TBD: not specified in GHC-precedence] |
| 5 Repository | .claude/settings.json |
.claude/settings.json or .github/copilot/settings.json |
.github/copilot-instructions.md, .github/instructions/**/*.instructions.md, AGENTS.md |
| 6 User | ~/.claude/settings.json |
VS Code user settings | Personal instructions (GitHub.com only) |
Sources: CC-settings § Settings files; VSC-enterprise § Manage agent plugins and marketplaces;
VSC-plugins-norm § Convergence point; GHC-precedence § Precedence of custom instructions;
GHC-cascade § How do policies work.
The honest reading of that table: only Claude Code can express four organizational tiers. VS Code and Copilot each collapse tiers 1 through 4 into one org-level control surface. Patterson should treat the four-tier model as a Claude Code capability that the other two platforms approximate, not as a shape all three share.
Source of truth: docs/architecture/layered-settings.md in the patterson-corp repository.