The Principle: Default First
Every class of information the team handles has a default classification. The transparency matrix enforces the correct default and documents every exception.
The correct default reverses what most teams practice. Most teams treat individual data as public (performance discussed openly, compensation shared casually, personal circumstances common knowledge) and process as opaque (how decisions are made, what criteria applied, what reasoning stood behind an outcome). The transparency matrix inverts this: process is public; persons are private.
The Three Classifications
Public by default. Information that strengthens the team's structural integrity by being visible — processes auditable, decisions contestable, standards enforceable.
Auditable on request. Information that is not routinely published but is available to the person involved and to the integrity officer when auditing decisions. This classification balances transparency with minimal exposure.
Protected by design. Information that remains opaque unless a specific, documented exception authorizes exposure. The default is that this information is accessible only to the person and designated stewards (manager, integrity officer).
The Full Matrix
Table 2.3B.2-1 — Organizational structure and roles
| Information | Default | Rationale |
|---|---|---|
| Org chart and reporting relationships | PUBLIC | Clarity on authority and communication paths |
| Role definitions, scope, and responsibilities | PUBLIC | Clarity on boundaries and expectations |
| Entry criteria and career pathways | PUBLIC | Fairness and accessibility to opportunities |
| Performance expectations by role | PUBLIC | People should know the standard they are measured against |
Table 2.3B.2-2 — Decision-making
| Information | Default | Rationale |
|---|---|---|
| Decision authorities and decision rights matrix | PUBLIC | Clarity on where authority rests |
| Appeal processes | PUBLIC | People should know their recourse |
| Criteria for major decisions (hiring, promotion, architecture) | PUBLIC | Decisions should be principled and contestable |
| Individual decision reasoning | AUDITABLE | Available if challenged; not routinely published |
Table 2.3B.2-3 — Financial information
| Information | Default | Rationale |
|---|---|---|
| Team budget and spending by category | PUBLIC | Resource allocation transparency |
| Payoff table (role/contribution to compensation mapping) | PUBLIC | Transparency on how compensation is determined |
| Individual compensation level | AUDITABLE (by person) | The person can verify against the payoff table |
| Compensation distribution (anonymized: ranges, medians, ratios) | AUDITABLE | Integrity officer audits fairness without exposing individuals |
| Individual bonus/stock grants, salary history, negotiation history | PROTECTED | Personal financial details |
Table 2.3B.2-4 — Performance and evaluation
| Information | Default | Rationale |
|---|---|---|
| Performance review schedule and cycle | PUBLIC | Predictability and fairness |
| Team metrics and aggregated output | PUBLIC | Team health without individual exposure |
| Individual performance outcomes | AUDITABLE (by person and manager) | The person deserves to know how they are assessed |
| Performance review text, peer feedback, incident reports | PROTECTED (by person only) | Personal development data; sharing is surveillance |
| Performance improvement plans | AUDITABLE (general criteria) | Person should know the standard; detailed plan is protected |
Table 2.3B.2-5 — Personnel decisions
| Information | Default | Rationale |
|---|---|---|
| Why position is being created/filled, job description, hiring timeline | PUBLIC | Transparency on business decisions |
| Candidate pipeline demographics (aggregated) | AUDITABLE | Integrity officer audits for bias |
| Why someone was promoted | AUDITABLE (by person) | Confirmation that criteria were met |
| Promotion criteria and timeline | PUBLIC | Clarity and fairness |
| Feedback on rejected candidates, reasons for non-promotion or termination | PROTECTED | Protecting dignity; available to person on request |
| Exit process and terms | PUBLIC | Clarity on what leaving involves |
Table 2.3B.2-6 — Technical, process, and audit
| Information | Default | Rationale |
|---|---|---|
| Architecture decisions, trade-offs, and rationale | PUBLIC | Team should understand technical direction |
| Team charter, amendments, and process changes | PUBLIC | Structural transparency |
| Audit schedule, scope, and aggregate results | PUBLIC | Accountability and improvement visibility |
| Specific audit findings identifying individuals | PROTECTED (unless person consents) | Audit is for learning, not exposure |
| Violation patterns (aggregate) | AUDITABLE | Helps assess whether design is working |
Table 2.3B.2-7 — Privacy and personal data
| Information | Default | Rationale |
|---|---|---|
| What personal data the team collects and why | PUBLIC | Informed consent on data collection |
| How long personal data is retained | PUBLIC | Clarity on privacy expectations |
| Individual health, mental health, family situation | PROTECTED (by person only) | Strictest privacy category |
| Accommodation requests, reasons for absence | PROTECTED (by manager only) | Personal circumstance data |
Exception Logging
Every exception to the default classification is logged with six elements:
Exception ID. Unique identifier for tracking.
What and why. What information is being exposed and why the exception is justified.
Authorization. Who approved the exception.
Scope. Who gets access — limited to the minimum necessary.
Duration and sunset. When the exception expires and access is automatically revoked.
Appeal. If the person whose data is affected objects, the recourse mechanism.
The exception log is itself auditable. Quarterly, the integrity officer reviews: are exceptions being logged? Are sunsets being enforced? Are denied exceptions documented? A pattern of exceptions accumulating in one category signals that the default is not working and should be revised — rather than managing endless individual exceptions.
Quarterly Privacy Attestation
The integrity officer conducts a quarterly spot-check:
Sample ten random information items and verify default classification is honored. Review the exception log for completeness and sunset enforcement. Verify that protected information is not stored in shared locations, team wikis, or unencrypted communications. Survey team members: do they know what personal data is collected, who has access, and what would happen if they objected? Test recourse by creating a test exception and verifying the objection process functions.
The attestation report is published with findings and remediation actions.
Change Log
- 19 Mar 26 — Consolidated the original nine information categories into seven. Replaced the example and the exception-log listing with prose description. Removed a redundant implementation-steps section.