RUKAYAT-CODER · Oct 17, 2026 · Oct 17, 2026
diff --git a/Governance/community/CONTRIBUTOR_AGREEMENT.md b/Governance/community/CONTRIBUTOR_AGREEMENT.md
@@ -0,0 +1,79 @@
+# Contributor Agreement
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/community/CONTRIBUTOR_AGREEMENT.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 12 months |
+| Applies to | Everyone who contributes code, documentation, or other material to `rinafcode/teachLink_backend` |
+| Related | [`policies/DCO.md`](../policies/DCO.md) · [`policies/CONTRIBUTOR_SIGNOFF.md`](../policies/CONTRIBUTOR_SIGNOFF.md) · [`policies/LICENSING.md`](../policies/LICENSING.md) |
+
+This document is the human-readable overview of what a contributor agrees to
+when they contribute to the project. It is not a contract and it adds no
+obligation beyond the licence and the sign-off described below; the authoritative
+texts are [`policies/DCO.md`](../policies/DCO.md),
+[`policies/CONTRIBUTOR_SIGNOFF.md`](../policies/CONTRIBUTOR_SIGNOFF.md), and the
+project's [`LICENSE`](../../LICENSE).
+
+## 1. What contributors agree to
+
+By contributing, you agree that:
+
+1. **You have the right to contribute the work.** The contribution is your own
+   original work, or you have permission to submit it, and it does not knowingly
+   infringe anyone's copyright, patent, or trademark.
+2. **Your contribution is licensed under the project's licence.** The licence for
+   this repository is described in [`policies/LICENSING.md`](../policies/LICENSING.md)
+   and the root [`LICENSE`](../../LICENSE). Inbound contributions are licensed
+   under the same terms as outbound, so the project can distribute them.
+3. **You follow the Code of Conduct.** Participation is governed by
+   [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md) and enforced under
+   [`COC_ENFORCEMENT.md`](../COC_ENFORCEMENT.md).
+4. **You follow the contribution process.** Branching, commits, the PR checklist,
+   and review expectations are defined in [`CONTRIBUTING.md`](../../CONTRIBUTING.md).
+5. **You will not contribute secrets or third-party material you cannot license.**
+   Do not submit credentials, `.env` values, customer data, or code copied from a
+   source you do not have the right to relicense.
+
+## 2. Sign-off mechanism
+
+The project uses the **Developer Certificate of Origin (DCO)**, not a CLA. You
+sign off by adding a `Signed-off-by:` trailer to each commit:
+
+```
+Signed-off-by: Full Name <email@example.com>
+```
+
+`git commit -s` adds it for you. The trailer certifies the statements in §1 and
+is described fully in [`policies/DCO.md`](../policies/DCO.md). Commits without a
+valid sign-off may be asked to amend before merge.
+
+## 3. Where records are kept
+
+- **The commits themselves are the record.** The `Signed-off-by` trailer in the
+  repository history is the primary, durable record of each contribution and its
+  sign-off.
+- **Pull requests** keep the review trail: who proposed the change, who reviewed
+  it, and the discussion that led to the merge.
+- **No separate private registry** of contributors is maintained for the DCO;
+  the git history is sufficient and auditable. Maintainer-role records, if any,
+  live with the governance documents in this folder.
+- Personal data in a sign-off is limited to the name and email you choose to
+  publish in the commit, in line with the project's data-minimisation principle.
+
+## 4. If you change your mind
+
+You may stop contributing at any time. Because the DCO grants an irrevocable
+licence for contributions already made, merged contributions remain part of the
+project under the project's licence. If you have a concern about a specific
+contribution, raise it with the maintainers rather than rewriting published
+history.
+
+## 5. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |
diff --git a/Governance/compliance/ACCESSIBILITY_STATEMENT.md b/Governance/compliance/ACCESSIBILITY_STATEMENT.md
@@ -0,0 +1,73 @@
+# Accessibility Statement Governance
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/compliance/ACCESSIBILITY_STATEMENT.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 12 months, and after any major UI change |
+| Applies to | The public accessibility statement for the platform's user-facing surfaces |
+| Related | [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md) · [`community/INCLUSIVE_LANGUAGE.md`](../community/INCLUSIVE_LANGUAGE.md) |
+
+This document defines the **stated conformance level**, the **feedback channel**,
+and the **review cadence** for the project's accessibility statement. It governs
+the statement's process; the published statement itself may live outside this
+repository, but it must follow the rules below so that what we claim matches what
+we do.
+
+## 1. Stated conformance level
+
+- Our target is **WCAG 2.2 Level AA** for user-facing web surfaces of the
+  platform. This is the level the published statement must claim.
+- **Claims must be evidence-based.** The statement may only claim a conformance
+  level that a documented evaluation supports. Where we are not yet conformant,
+  the statement must say so plainly, list the known gaps, and give the
+  remediation plan rather than overstating conformance.
+- **Partial conformance is stated as partial.** If some surfaces meet AA and
+  others do not, name the exceptions. A blanket "fully conformant" claim is not
+  permitted while known gaps exist.
+- **Third-party content** that the project does not control is called out
+  separately, with the effort made to influence it.
+
+## 2. What the statement must include
+
+At minimum: the conformance target and current status; the date of the most recent
+evaluation and who performed it; known limitations and the plan to fix them; the
+feedback channel in §3; and the review cadence in §4. It should be reachable from
+the product's footer or help pages, not buried in a repository.
+
+## 3. Feedback channel
+
+- Users can report an accessibility barrier through a **named, monitored
+  channel** — a dedicated email address and the issue tracker — published in the
+  statement itself.
+- A report is **acknowledged within 3 business days** and triaged under
+  [`processes/TRIAGE.md`](../processes/TRIAGE.md). Reports that describe a
+  blocker for assistive-technology users are prioritised.
+- Where a barrier has no quick fix, the report is tracked as an issue labelled
+  for accessibility, with a target and an owner, and the reporter is told where
+  to follow it.
+- The feedback channel is not used for security reports; those follow
+  [`SECURITY_POLICY.md`](../SECURITY_POLICY.md).
+- The channel is open to everyone and the response is given respectfully, as
+  required by [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md).
+
+## 4. Review cadence
+
+- The statement is **reviewed at least every 12 months**, and after any major
+  change to a user-facing surface, so it does not drift from reality.
+- Each review checks the conformance claim against a fresh evaluation, confirms
+  the feedback channel still works, and updates the "last reviewed" date.
+- The review is recorded in this document's change log with the reviewer and the
+  outcome. If a gap is found, an issue is opened rather than only editing the
+  statement.
+- If a review is not performed within the cadence, the statement is amended to
+  say the last evaluation is older than one year.
+
+## 5. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |
diff --git a/Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md b/Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md
@@ -0,0 +1,88 @@
+# Privacy Policy Governance
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/compliance/PRIVACY_POLICY_GOVERNANCE.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team, in consultation with the project's data-protection contact |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 6 months, and on any material change to data processing |
+| Applies to | The public privacy policy that describes how the platform handles personal data |
+| Related | [`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md) · [`domains/DATA_RETENTION.md`](../domains/DATA_RETENTION.md) · [`compliance/DPA_TEMPLATE.md`](DPA_TEMPLATE.md) |
+
+This document defines **who owns** the project's privacy policy, **how** it is
+updated and reviewed, and **how** it is versioned. It governs the process, not
+the legal content; the published policy itself may live outside this repository,
+but every change to it follows the process below.
+
+## 1. Who owns the privacy policy
+
+- The **maintainer team** owns the privacy policy and is accountable for keeping
+  it accurate and published. See [`roles/MAINTAINER.md`](../roles/MAINTAINER.md).
+- A **data-protection contact** (a named maintainer or an external advisor acting
+  for the project) is responsible for the substantive review: whether the policy
+  matches what the system actually does.
+- The **treasurer** reviews any part of the policy that touches payment or
+  financial data, with the treasurer's duties in [`roles/TREASURER.md`](../roles/TREASURER.md).
+- Where processing is performed by a processor, the relationship is recorded
+  using [`compliance/DPA_TEMPLATE.md`](DPA_TEMPLATE.md).
+
+## 2. What the policy must cover
+
+The policy, at minimum, must state:
+
+- what personal data is collected and for what purpose;
+- the legal basis relied on for each processing activity;
+- how long data is retained and how it is deleted (see
+  [`domains/DATA_RETENTION.md`](../domains/DATA_RETENTION.md) and
+  [`policies/DATA_DELETION.md`](../policies/DATA_DELETION.md));
+- who data is shared with, including sub-processors and any cross-border transfer
+  (see [`policies/DATA_RESIDENCY.md`](../policies/DATA_RESIDENCY.md));
+- the data-subject rights available and how to exercise them, including consent
+  withdrawal (see [`policies/CONSENT_MANAGEMENT.md`](../policies/CONSENT_MANAGEMENT.md));
+- how children's data is handled (see [`compliance/CHILDRENS_DATA.md`](CHILDRENS_DATA.md));
+- the contact channel for privacy questions and complaints.
+
+The classification vocabulary used to describe the data is defined in
+[`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md).
+
+## 3. Update and review process
+
+1. **Trigger.** A change is opened when the system's data handling changes, when
+   a new processor or transfer is introduced, when a legal requirement changes,
+   or on the scheduled review date, whichever is first.
+2. **Proposal.** An issue is opened describing the change and the processing
+   activity it reflects. The change is made as a pull request that stays within
+   `Governance/` for the process record.
+3. **Substantive review.** The data-protection contact confirms the policy still
+   matches the system. A change that alters a legal basis, a retention period,
+   or a transfer also requires maintainer approval.
+4. **Cross-check.** The reviewer confirms the policy is consistent with
+   [`domains/DATA_CLASSIFICATION.md`](../domains/DATA_CLASSIFICATION.md) and
+   [`domains/DATA_RETENTION.md`](../domains/DATA_RETENTION.md) and that the
+   promises made are implementable.
+5. **Approval.** At least one maintainer who is not the author approves, then the
+   change is merged and, when it affects users, published as §4 requires.
+6. **Scheduled review.** Even with no trigger, the policy is reviewed at least
+   **every 6 months** and the review date recorded here.
+
+## 4. Versioning and notification
+
+- Every published policy carries a **version** (semantic `MAJOR.MINOR.PATCH`) and
+  an **effective date**. Material changes increment `MAJOR`; clarifications
+  increment `MINOR`; typo fixes increment `PATCH`.
+- The current version and its history are kept **in this document's change log**
+  and in the published policy itself, so a user can see what changed and when.
+- A material change is notified to users through the product's normal notice
+  channel (in-product notice or email to registered contacts) **before** it takes
+  effect, with a reasonable advance window, unless a legal requirement dictates
+  otherwise.
+- Prior versions are kept for an audit trail; do not delete a superseded version
+  from the history.
+
+## 5. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |
diff --git a/Governance/compliance/TERMS_OF_SERVICE_GOVERNANCE.md b/Governance/compliance/TERMS_OF_SERVICE_GOVERNANCE.md
@@ -0,0 +1,89 @@
+# Terms of Service Governance
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/compliance/TERMS_OF_SERVICE_GOVERNANCE.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team, with legal review where required |
+| Last reviewed | 2026-10-17 |
+| Review cadence | Every 12 months, and on any material change to the service |
+| Applies to | The public terms of service that govern use of the platform |
+| Related | [`compliance/PRIVACY_POLICY_GOVERNANCE.md`](PRIVACY_POLICY_GOVERNANCE.md) · [`policies/DEPRECATION.md`](../policies/DEPRECATION.md) |
+
+This document defines **who owns** the terms of service, the **update and
+approval process**, and the **user-notification rule** for changes. It governs
+the process; the published terms themselves may live outside this repository, but
+every change follows the process below.
+
+## 1. Who owns the terms
+
+- The **maintainer team** owns the terms and is accountable for keeping them
+  current and published.
+- **Legal review** is required for any change that alters liability, dispute
+  resolution, acceptable use, or termination. Where the project has no in-house
+  counsel, the maintainers obtain external review before publishing.
+- **Product owners** of a feature that changes what users may do must flag the
+  change so the terms can be updated before the feature ships.
+- The **privacy policy** is owned separately under
+  [`compliance/PRIVACY_POLICY_GOVERNANCE.md`](PRIVACY_POLICY_GOVERNANCE.md); the
+  two documents must not contradict each other.
+
+## 2. What the terms must cover
+
+At minimum: acceptable use, account responsibilities, intellectual-property and
+licence terms, fees and payment terms where applicable, availability and support
+expectations, suspension and termination, disclaimers and limitation of
+liability, governing law, and how disputes are resolved. Feature-specific rules
+(for example rate limits or API fair use) must be reachable from the terms rather
+than existing only in code.
+
+## 3. Update and approval process
+
+1. **Trigger.** A change is opened when a feature changes user obligations, when
+   a legal or regulatory requirement changes, or on the scheduled review date.
+2. **Proposal.** An issue describes the change and the user-facing behaviour it
+   reflects. The change to the process record is made as a pull request inside
+   `Governance/`.
+3. **Review.**
+   - A maintainer who is not the author confirms the terms match the service.
+   - Legal review is required for the categories listed in §1.
+   - The privacy-policy owner is consulted if the change touches data use.
+4. **Approval.** A material change requires approval by at least **two
+   maintainers**, one of whom must not be the author. Legal sign-off, where
+   required, is recorded on the issue.
+5. **Effective date.** Approval sets an **effective date** that allows the notice
+   period in §4 to run before the new terms bind users.
+6. **Scheduled review.** Even without a trigger, the terms are reviewed at least
+   **every 12 months**.
+
+## 4. User-notification rule
+
+- **Material changes are notified before they take effect.** A reasonable advance
+  notice is given through the product's standard channel (in-product notice or
+  email to registered contacts) before the effective date, unless a legal or
+  security requirement dictates a shorter or immediate change.
+- **The notice must say what changed and when it takes effect**, and link the new
+  version. It is not enough to change the document silently.
+- **Non-material changes** (typo fixes, formatting, clarifying wording that does
+  not change meaning) may be published without a notice but still increment the
+  version.
+- **Where continued use constitutes acceptance**, the notice must say so and give
+  users a way to stop using the service. Changes that increase a user's
+  obligations without a lawful basis to impose them cannot rely on continued use
+  alone.
+
+## 5. Versioning
+
+- Every published version carries a version and an effective date. Material
+  changes increment the major version; clarifications the minor; typo fixes the
+  patch.
+- The version history and the notice sent for each material change are recorded
+  in this document's change log and in the published terms.
+- Superseded versions are retained for the audit trail.
+
+## 6. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-10-17 | 1.0.0 | Initial release. |