Information Classification¶
This policy defines how information handled by Devonshire Digital and its ventures is classified, so that contributors and AI agents can judge what is safe to write into version-controlled documentation, what belongs elsewhere, and what must never be committed at all.
Classification levels¶
Public¶
Information intended for, or already released to, the general public. Safe to publish in this repository, on a company website, or in marketing material.
Examples: published brand guidelines, public product descriptions, open documentation intended for customers, this repository's non-sensitive governance content (once the repository's visibility decision is finalized — see open-questions.md).
Internal¶
Information intended for use within Devonshire Digital and its ventures, not for external publication, but not damaging if narrowly seen by trusted parties (e.g. contractors, advisors).
Examples: internal strategy notes, draft roadmaps, internal process documentation, most of the content in this repository as currently scoped (private, no remote).
Confidential¶
Sensitive business information whose disclosure could cause competitive or reputational harm. Access should be limited to those who need it.
Examples: unreleased product specifications with competitive value, detailed financial models, vendor contract terms, unreleased pricing strategy, internal risk assessments.
Restricted¶
The highest sensitivity level. Disclosure could cause significant harm to the company, a venture, or a person. Restricted information must never be committed to this repository, regardless of the repository's visibility settings.
Examples include, but are not limited to:
- Passwords.
- API keys and auth tokens.
- Private customer data (names, emails, addresses tied to real individuals).
- Personal financial data.
- Health information.
- Payment information (card numbers, bank details).
- Unreleased security vulnerability details.
Rules¶
- Restricted information never goes into this repository, in any file, commit message, issue, or example — including example/sample data. Use clearly fictional placeholder data instead (see docs/ai/prohibited-behaviors.md).
- Confidential information requires judgment. Default to keeping detailed competitive or
financial specifics out of version-controlled documentation unless there is a clear reason
they need to live there, and mark such documents'
applies_toand any access notes clearly. - When in doubt, classify upward (treat information as more sensitive, not less) and escalate to the Security and Privacy Reviewer role if unsure.
- Real customer information is never used in examples. See docs/ai/prohibited-behaviors.md — use fictional, clearly labeled example data only.
- If Restricted information is discovered already committed to the repository, treat it as a security incident per SECURITY.md, not as a routine edit — rewriting history to remove secrets is a Security and Privacy Reviewer decision, not something an AI agent does unilaterally.
Related¶
- risk-register.md — tracks classification-related risks (e.g. future handling of customer data).
- docs/ai/prohibited-behaviors.md — agent-facing prohibitions including "adding credentials or secrets" and "storing customer information in documentation."
- SECURITY.md — how to report a suspected exposure.