Data Governance

Status: v0.1 Public Draft
Current data posture: Synthetic public examples only; no real evidence intake

This policy defines the data principles that bind the public specification and constrain any future operational platform. It does not serve as a production privacy notice or establish that a particular legal role, jurisdiction, or transfer mechanism has been approved. The Independence and Institutional Firewall controls purpose and access separation between benchmark operations and LockedIn training, employment, staffing, recruiting, sales, and services.

1. Principles

1. Collect the least data needed for a declared benchmark purpose.
2. Separate public specification data from private operational evidence.
3. Obtain specific authority, consent, or other applicable lawful basis before processing.
4. Default evidence to private and disclosure to opt-in.
5. Do not train models on candidate or customer artifacts by default.
6. Keep raw content out of append-only event logs.
7. Make permitted uses, retention, deletion, providers, and recipients legible.
8. Preserve correction, challenge, withdrawal, and appeal paths.
9. Treat references, customer facts, and contribution records as multi-party data.
10. Do not infer that a private career or sparse public footprint means low capability.

2. v0.1 public-repository rule

This repository may contain only:

• public project documentation and governance records;
• public standards citations;
• contributor information intentionally submitted for publication;
• conspicuously synthetic people, organizations, deployments, evidence, observations, and results;
• aggregate test output that cannot be linked to a real person or customer.

It must not contain real candidate evidence, customer artifacts, references, identity records, private repositories, or production telemetry.

3. Proposed data classes

Future systems must classify at least:

Labels must drive authorization, storage, retention, export, logging, model-provider, and deletion rules.

4. Consent and permitted use

A future ConsentGrant must identify:

• data subject and authorizing party;
• purpose and permitted processing;
• data categories and evidence sources;
• permitted reviewers, providers, recipients, and regions;
• publication choices;
• model-training permission, defaulting to denied;
• effective date, expiration, withdrawal method, and policy version;
• consequences of withdrawal that are required for integrity or law.

Consent for evaluation is not consent for public profile publication, research, product training, marketing, or employer disclosure. Those purposes require separate authority.

An evidence submitter must have rights to provide the material. A candidate cannot unilaterally authorize disclosure of customer secrets or another person’s private information.

5. Purpose limitations

Evidence may be used only for the specific evaluation, verification, correction, appeal, security, or approved research purpose named in policy and consent.

Prohibited secondary uses include:

• unrelated advertising or lead generation;
• staffing, recruiting, placement, employment, sales, customer-success, or training use without separate subject authority and an approved purpose boundary;
• training a model without specific permission and governance approval;
• selling candidate or reference data;
• exposing one customer’s or candidate’s evidence to another;
• developing employment cutoffs outside a validated, legally reviewed use;
• using private evidence to imply endorsement or marketing participation.

Aggregate research must undergo purpose, sample, disclosure, and re-identification review before publication.

6. Minimization and evidence separation

Raw artifact content belongs in a private encrypted object boundary, not a transactional profile table, search index, event log, analytics stream, support ticket, or model prompt archive by default.

Evaluator packets should contain the minimum pseudonymous fields and short-lived read-only artifact handles required for the assigned task. Providers must not receive names, employers, schools, or other prestige/identity fields unless they are necessary to the construct and approved for that evaluation.

Public profiles receive disclosure-filtered projections only.

7. Retention and deletion

Before collecting a data category, the operator must publish or provide a versioned retention schedule stating:

• active retention period;
• backup and derived-copy handling;
• review and expiration triggers;
• deletion or cryptographic-erasure method;
• legal-hold behavior;
• audit metadata retained after deletion;
• responsibility and verification evidence.

No default number of days is asserted in v0.1 because operational, legal, research, and security requirements have not been reviewed.

Append-only history is reconciled with deletion as follows:

• raw personal and artifact content never enters immutable events;
• events use pseudonymous references, policy versions, and digests;
• withdrawal or deletion creates a tombstone event;
• encryption-key destruction or verified object deletion removes content access;
• minimized audit metadata may remain only where justified and documented;
• public credentials and profiles reflect suspension, withdrawal, expiry, or revocation promptly.

8. Data-subject participation

Future participants must be able to:

• understand what data is used and for what purpose;
• view material claims and eligible conclusions about them;
• correct factual errors;
• challenge attribution, verification, or contradictory evidence;
• withdraw optional publication and future processing;
• request deletion subject to disclosed exceptions;
• obtain the applicable appeal path;
• ask for an accommodation or alternate demonstration.

Identity and fraud controls must not require public disclosure.

9. References and third-party attestations

References must receive a claim-specific request rather than an open-ended invitation to provide personal commentary. The system must document identity verification, relationship, consent, permitted use, disclosure choice, and confidence.

Reference identity and free-form notes are private by default. A public profile may state that a claim was corroborated without naming the reference or customer.

10. Providers, transfers, and training

Before using a cloud, model, analytics, identity, storage, or verification provider, the operator must document:

• provider purpose and data categories;
• retention and model-training terms;
• subprocessors and processing regions;
• security and deletion capabilities;
• contractual restrictions and incident duties;
• available customer-controlled, local, or no-retention modes;
• an exit and portability plan.

Candidate and customer artifacts are not used for model training by default. An exception requires specific rights, separate consent where applicable, a documented benefit and risk assessment, governance approval, held-out evaluation design, and an opt-out path where legally and scientifically valid.

11. Access and audit

Access must be least-privilege, case-scoped, time-bounded, conflict-checked, and logged. Bulk export, support access, break-glass access, and administrative impersonation require separate control and review.

Training, recruiting, staffing, sales, engagement, and customer-success roles receive no candidate-private benchmark evidence or hidden result access by default. A subject-authorized public verification object may be shared for a declared purpose; that authorization does not expose the underlying evidence or create preferred benchmark treatment.

Audit events must identify the actor or service, action, purpose, policy version, authorization, time, and affected pseudonymous object. They must not copy raw evidence into logs.

12. Public profiles and credentials

Publication is opt-in and field-level. A subject may choose whether to display result class, domain profile, confidence, coverage, evidence summaries, specialization, and history within the release policy.

Future credentials must support status and revocation and should evaluate selective disclosure. A public verification URL must not expose private evidence or enable unrestricted enumeration.

No official profile or credential exists in v0.1.

13. Research governance

Research data use requires:

• a defined question and analysis plan;
• rights and consent compatible with that purpose;
• minimization and de-identification appropriate to re-identification risk;
• subgroup and small-cell disclosure controls;
• approved access, environment, retention, and publication plan;
• separation of exploratory and confirmatory analysis where claims depend on it;
• disclosure of sample limitations and conflicts.

A small pilot cannot support broad predictive, fairness, percentile, or population claims.

14. Activation gates

Real-data processing is blocked until the operator has approved and tested:

• legal roles, privacy notice, consent, participant terms, and data-rights workflow;
• data inventory, classification, flow, retention, deletion, and legal-hold schedules;
• tenant isolation, authorization, encryption, key management, and audit;
• provider and cross-border assessments;
• incident and breach response;
• artifact isolation and the controls in SECURITY.md;
• reviewer confidentiality, conflicts, and access review;
• named and tested role/data separation across training, employment, staffing/recruiting, sales, evidence custody, assessment, issuance, appeal, and publication;
• research governance and publication controls.

Related documents: SPEC.md · BENCHMARK_CARD.md · INDEPENDENCE_FIREWALL.md · CONFLICT_OF_INTEREST.md · SECURITY.md · APPEALS.md