diff --git a/Governance/COC_ENFORCEMENT.md b/Governance/COC_ENFORCEMENT.md
new file mode 100644
index 00000000..edf37098
--- /dev/null
+++ b/Governance/COC_ENFORCEMENT.md
@@ -0,0 +1,189 @@
+# Code of Conduct Enforcement Ladder
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/COC_ENFORCEMENT.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-09-29 |
+| Review cadence | Every 6 months, or after any enforcement decision |
+| Applies to | Everyone covered by [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md) §3 |
+
+This document defines **what happens once a Code of Conduct report is upheld**:
+the graduated steps available, the criteria that select between them, and who
+may apply each.
+
+It exists so that enforcement is predictable. A project that can impose any
+sanction for any violation is one where the outcome depends on who is handling
+the report and what sort of day they are having. A stated ladder makes a
+decision reviewable — and [`COC_APPEALS.md`](COC_APPEALS.md) §5.1 lets a sanction
+be appealed as *disproportionate*, which is only meaningful against a published
+scale.
+
+It is governance only. It changes no application behaviour, adds no runtime
+dependency, and is scoped entirely to the `Governance/` folder.
+
+## 1. Scope
+
+This document applies where a report made under
+[`COC_REPORTING.md`](COC_REPORTING.md) has been reviewed and a violation of
+[`CODE_OF_CONDUCT.md` §4](CODE_OF_CONDUCT.md) established.
+
+It does **not** apply to:
+
+- provisional protective measures taken while a review is still open, which are
+  governed by [`COC_REPORTING.md` §5](COC_REPORTING.md) and are not findings;
+- revocation of a governance privilege on non-conduct grounds, which is governed
+  by [`policies/REVOCATION.md`](policies/REVOCATION.md);
+- ordinary review outcomes, which are not enforcement at all
+  ([`CODE_OF_CONDUCT.md` §5](CODE_OF_CONDUCT.md)).
+
+## 2. Principles
+
+| Principle | What it means in practice |
+| --- | --- |
+| **Graduated by default** | Start at the lowest step that credibly addresses the conduct. Escalate for repetition or severity, not for annoyance. |
+| **Proportionate** | The response matches the conduct, not the status of either party. |
+| **Reasoned in writing** | Every sanction states the conduct, the provision applied, the step chosen, and its duration. |
+| **Correction over punishment** | The aim is that the behaviour stops and the affected person can keep participating. A sanction that achieves that is sufficient. |
+| **Consistent** | Comparable conduct receives comparable responses. Departures are explained in the decision. |
+| **Always appealable** | Every step on this ladder carries the appeal right in [`COC_APPEALS.md`](COC_APPEALS.md). |
+| **Never retaliatory** | A sanction imposed because someone reported, appealed, or participated in a process is itself a violation ([`CODE_OF_CONDUCT.md` §4.5](CODE_OF_CONDUCT.md)). |
+
+Starting low is the default, not a requirement. Conduct that is severe on a
+first occurrence is met at the step it warrants — §4.
+
+## 3. The ladder
+
+### Step 1 — Private correction
+
+| | |
+| --- | --- |
+| **What** | A private, written note naming the conduct and the provision it engages, with a clear statement of what must change. Not recorded as a sanction. |
+| **When** | A first, isolated lapse: a sharp review comment, a dismissive reply, a joke that landed badly. Conduct that most likely reflects carelessness rather than intent. |
+| **Applied by** | Any maintainer. |
+| **Duration** | None. It is a correction, not a restriction. |
+| **Recorded** | Not logged in [`DECISION_LOG.md`](DECISION_LOG.md). Retained privately by the handler so repetition can be recognised. |
+
+### Step 2 — Formal warning
+
+| | |
+| --- | --- |
+| **What** | A written warning stating the conduct, the provision breached, and that a further violation will escalate. May require a specific action: editing or withdrawing a comment, or ceasing contact with a named person. |
+| **When** | Repeated conduct after a step 1 correction, or a first violation too substantial for a private note — a personal attack, a discriminatory remark, sustained dismissiveness toward a contributor. |
+| **Applied by** | Any maintainer, after consulting one other unconflicted maintainer. |
+| **Duration** | The warning stands on the record for **12 months**. Conditions attached to it (such as no contact) continue until lifted in writing. |
+| **Recorded** | Logged in [`DECISION_LOG.md`](DECISION_LOG.md) by outcome category and date, with the person not identified. |
+
+### Step 3 — Temporary restriction
+
+| | |
+| --- | --- |
+| **What** | Time-boxed removal of a specific ability: interaction with one thread or repository area, posting in a community channel, or reviewing. Other participation continues. |
+| **When** | A violation continuing after a formal warning, or a single violation serious enough that leaving the interaction unchanged would expose someone to further harm. |
+| **Applied by** | Two maintainers acting together, at least one unconflicted. |
+| **Duration** | Stated at the outset, **7 to 90 days**. An open-ended restriction is not a step 3 measure. |
+| **Recorded** | Logged in [`DECISION_LOG.md`](DECISION_LOG.md). |
+
+### Step 4 — Suspension
+
+| | |
+| --- | --- |
+| **What** | Time-boxed removal from **all** project spaces: repository, community channels, and calls. Any governance privilege is suspended for the same period. |
+| **When** | A pattern established across previous steps; or serious conduct on a first occurrence — targeted harassment, doxxing, a threat, or retaliation against a reporter. |
+| **Applied by** | The maintainer team, by the quorum in [`policies/QUORUM.md`](policies/QUORUM.md). The project lead may impose it alone where delay would leave someone at risk, and it is confirmed by quorum within **5 business days** or lapses. |
+| **Duration** | Stated at the outset, **30 days to 12 months**. |
+| **Recorded** | Logged in [`DECISION_LOG.md`](DECISION_LOG.md). Where a governance privilege is affected, [`policies/REVOCATION.md`](policies/REVOCATION.md) applies in parallel. |
+
+### Step 5 — Permanent ban
+
+| | |
+| --- | --- |
+| **What** | Permanent removal from every project space, with no route back except through appeal. |
+| **When** | Reserved. Appropriate only where the conduct is grave — a credible threat of violence, sexual harassment, sustained targeted harassment, deliberate introduction of a vulnerability or backdoor — or where the pattern through steps 2 to 4 shows the behaviour will not change. |
+| **Applied by** | The maintainer team by quorum, with the decision and its reasons recorded in full. Never by one person. |
+| **Duration** | Indefinite. |
+| **Recorded** | Logged in [`DECISION_LOG.md`](DECISION_LOG.md), and in the transparency reporting under [`policies/TRANSPARENCY_REPORTS.md`](policies/TRANSPARENCY_REPORTS.md) in aggregate form. |
+
+## 4. Choosing a step
+
+The starting point is step 1 and escalation is one step at a time — **unless**
+one of the following applies, each of which permits entry higher on the ladder:
+
+| Factor | Effect |
+| --- | --- |
+| **Severity** | Conduct under [`CODE_OF_CONDUCT.md` §4.1](CODE_OF_CONDUCT.md) involving threats, sexual harassment, or targeted harassment enters at step 4 or 5, first occurrence or not. |
+| **Repetition** | A further violation while a step 2 warning stands (12 months) escalates by at least one step. |
+| **Ongoing risk** | Where leaving the person in place would expose someone to further harm, enter at the lowest step that removes the risk. |
+| **Abuse of position** | A violation using a maintainer or reviewer role ([`CODE_OF_CONDUCT.md` §4.3](CODE_OF_CONDUCT.md)) escalates by one step, because the power imbalance makes the conduct harder to resist and harder to report. |
+| **Retaliation** | Retaliation against a reporter or appellant enters at **step 4 minimum**. It attacks the reporting process itself, which everything else here depends on. |
+| **Impact on a newer contributor** | Aggravating. Conduct that drives away someone who has not yet established themselves does disproportionate damage. |
+
+Mitigating factors, which may hold a response at a lower step:
+
+- **Prompt, unprompted acknowledgement** and a genuine effort to repair.
+- **A single lapse** against a long record of constructive participation.
+- **Ambiguity** — where a reasonable person could have read the exchange
+  differently, or where context was genuinely missing.
+
+Mitigation does not apply to the conduct listed under **Severity** above.
+
+## 5. Who applies what
+
+| Step | Decided by | Second person required |
+| --- | --- | --- |
+| 1 — Private correction | Any maintainer | No |
+| 2 — Formal warning | Any maintainer | Yes — one other unconflicted maintainer consulted |
+| 3 — Temporary restriction | Two maintainers | Yes — at least one unconflicted |
+| 4 — Suspension | Maintainer team by quorum | Yes — quorum per [`policies/QUORUM.md`](policies/QUORUM.md) |
+| 5 — Permanent ban | Maintainer team by quorum | Yes — never a single decision-maker |
+
+Applying at every step:
+
+- **Nobody decides a matter they are party to.** A maintainer who is the subject
+  of the report, who reported it, or who is directly involved takes no part in
+  deciding it.
+- **Nobody decides their own appeal.** Whoever takes the decision is excluded
+  from the appeal panel ([`COC_APPEALS.md` §4](COC_APPEALS.md)).
+- **Every decision is communicated in writing** to the person sanctioned,
+  stating the conduct, the provision, the step, the duration, and the appeal
+  route and its 14-day deadline.
+
+## 6. Expiry and return
+
+A time-boxed sanction ends on its stated date without anyone needing to act. It
+is not extended silently; extending it requires a fresh decision at the
+appropriate step, with its own appeal right.
+
+**Return after a suspension.** A person returning at step 4 resumes ordinary
+participation. Governance privileges suspended alongside are restored unless
+they were separately revoked under
+[`policies/REVOCATION.md`](policies/REVOCATION.md), in which case that document
+governs their return.
+
+**Record expiry.** A step 2 warning ceases to count toward escalation after 12
+months. Steps 3 and 4 count for **24 months**. After those windows, the conduct
+is not treated as a prior violation when selecting a step — though the log entry
+itself is retained.
+
+**A permanent ban** is lifted only by a successful appeal, or by a decision of
+the maintainer team by quorum on fresh evidence.
+
+## 7. Relationship to other documents
+
+| Document | Relationship |
+| --- | --- |
+| [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md) | The standard being enforced; §4 defines the violations this ladder responds to. |
+| [`COC_REPORTING.md`](COC_REPORTING.md) | How a matter reaches this ladder, and the provisional measures that precede a finding. |
+| [`COC_APPEALS.md`](COC_APPEALS.md) | The appeal right attaching to every step, and the independent panel that hears it. |
+| [`policies/REVOCATION.md`](policies/REVOCATION.md) | Governance privileges: applies in parallel at steps 4 and 5, and governs return. |
+| [`policies/QUORUM.md`](policies/QUORUM.md) | The quorum required at steps 4 and 5. |
+| [`policies/TRANSPARENCY_REPORTS.md`](policies/TRANSPARENCY_REPORTS.md) | Aggregate reporting of enforcement activity. |
+| [`DECISION_LOG.md`](DECISION_LOG.md) | Where outcomes from step 2 upward are recorded, in minimised form. |
+
+## 8. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-09-29 | 1.0.0 | **Initial release.** Defines the enforcement principles (§2), the five-step ladder from private correction to permanent ban with criteria, authority and duration for each (§3), the aggravating and mitigating factors that select a step (§4), who may apply each step and the conflict rules (§5), and expiry, return and record windows (§6). |
diff --git a/Governance/COC_REPORTING.md b/Governance/COC_REPORTING.md
new file mode 100644
index 00000000..675b3a1b
--- /dev/null
+++ b/Governance/COC_REPORTING.md
@@ -0,0 +1,221 @@
+# Code of Conduct Reporting Process
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/COC_REPORTING.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-09-29 |
+| Review cadence | Every 6 months, or after any conduct report |
+| Applies to | Everyone covered by [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md) §3 |
+
+This document defines **how to report** a Code of Conduct concern: where the
+report goes, how quickly you get a response, and what confidentiality you are
+guaranteed.
+
+A Code of Conduct with no usable reporting route is decoration. The purpose of
+this document is to make reporting predictable enough that someone will actually
+do it: you should be able to know, before you write anything, who will read it,
+how long it will take, and what will happen to what you send.
+
+It is governance only. It changes no application behaviour, adds no runtime
+dependency, and is scoped entirely to the `Governance/` folder.
+
+## 1. Scope
+
+Use this process to report conduct covered by
+[`CODE_OF_CONDUCT.md` §4](CODE_OF_CONDUCT.md) — harassment, privacy violations,
+abuse of position, bad-faith participation, and retaliation — occurring in any
+space listed in [`CODE_OF_CONDUCT.md` §3](CODE_OF_CONDUCT.md).
+
+**Use a different route for:**
+
+| Situation | Route |
+| --- | --- |
+| A security vulnerability | [`SECURITY_POLICY.md`](SECURITY_POLICY.md) and [`processes/VULN_DISCLOSURE.md`](processes/VULN_DISCLOSURE.md) |
+| A technical disagreement | [`processes/CONFLICT_RESOLUTION.md`](processes/CONFLICT_RESOLUTION.md) |
+| An objection to a proposed governance decision | [`processes/OBJECTION_HANDLING.md`](processes/OBJECTION_HANDLING.md) |
+| Contesting an enforcement decision already taken | [`COC_APPEALS.md`](COC_APPEALS.md) |
+
+If you are not sure which applies, report it here anyway. Routing it correctly
+is the project's job, not yours.
+
+## 2. Who may report
+
+**Anyone.** You do not need to be a contributor, to have commit access, or to
+have been the target of the conduct.
+
+- **The person affected** may report.
+- **A witness** may report conduct directed at someone else. Where the affected
+  person is identifiable, the project will normally ask them before taking
+  action naming them — except where waiting would leave someone at risk.
+- **A third party** who was told about the conduct may report it, and should say
+  that their account is second-hand.
+
+You may report **anonymously** (§3.3), with the limits that necessarily carries.
+
+A report made in good faith that turns out to be mistaken is **not** a
+violation. Only a knowingly false report is
+([`CODE_OF_CONDUCT.md` §4.4](CODE_OF_CONDUCT.md)).
+
+## 3. How to report
+
+### 3.1 Channels
+
+Report through **one** of the following. All are private; none creates a public
+record.
+
+| Channel | Address | Use when |
+| --- | --- | --- |
+| **Email** | `conduct@teachlink.example` (replace with the project's published conduct contact if different) | The default. Best for anything detailed, and the only channel that leaves you a copy. |
+| **Direct message** | `@rinafcode` on GitHub or [Telegram](https://t.me/teachlinkOD) | Quicker, or when email is inconvenient. |
+| **Any maintainer** | See [`roles/MAINTAINER.md`](roles/MAINTAINER.md) | When your report concerns the project lead, or anyone you would otherwise have to report *to*. |
+
+**Never open a public issue or pull request to report a conduct concern.** Doing
+so exposes the people involved before anyone has looked at the facts, and makes
+a proportionate response harder.
+
+### 3.2 Reporting a maintainer, or the project lead
+
+Report to any other maintainer directly. A report is never handled by its
+subject: whoever receives it hands it to someone unconflicted, and the person
+reported takes no part in assessing it, in deciding it, or in any appeal of it
+([`COC_APPEALS.md` §4](COC_APPEALS.md)).
+
+If every maintainer is conflicted, say so in your report. The matter is then
+referred to the steering group, or to an external reviewer drawn from the wider
+Stellar/TeachLink community, and that referral is recorded in the decision.
+
+### 3.3 Anonymous reports
+
+You may report without identifying yourself, by email from an account that does
+not carry your name.
+
+An anonymous report is taken seriously and is assessed on what it contains. Two
+consequences follow unavoidably:
+
+- **We cannot ask you follow-up questions,** so include as much detail as you
+  can up front.
+- **We cannot tell you the outcome,** because there is nobody to tell.
+
+Where an anonymous report describes conduct that is independently verifiable —
+something in a public thread, a commit, or a review — it can usually be acted on
+regardless. Where it rests entirely on an account only you can give, it may not
+be possible to reach a conclusion.
+
+### 3.4 What to include
+
+Nothing here is mandatory. A short report is better than no report.
+
+- **What happened**, in your own words.
+- **Where** it happened — a link to the issue, pull request, review comment, or
+  chat message, if there is one.
+- **When** it happened, approximately.
+- **Who** was involved, and whether anyone else saw it.
+- **Whether it is ongoing**, and whether you feel unsafe.
+- **What you would like to happen**, if you have a view. You are not obliged to
+  have one, and the project is not bound by it — but it is taken into account.
+
+Screenshots and copied text help, particularly where content may be edited or
+deleted later.
+
+## 4. Response timeline
+
+| Step | What happens | Owner | Deadline |
+| --- | --- | --- | --- |
+| 1 | **Acknowledgement.** You are told your report has been received and who is handling it. No assessment of the merits at this stage. | Recipient | **2 business days** |
+| 2 | **Conflict check and assignment.** The report is assigned to a handler with no involvement in the matter (§3.2). If that changes who is handling it, you are told. | Maintainer team | **5 business days** |
+| 3 | **Initial assessment.** The handler decides whether the report falls under [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md), and whether any immediate protective step is needed (§5). | Handler | **5 business days** |
+| 4 | **Review.** The handler reviews the evidence and gives the person reported a fair chance to respond, including the substance of the allegation. | Handler | **21 calendar days** of acknowledgement |
+| 5 | **Decision and notification.** A decision is taken under [`COC_ENFORCEMENT.md`](COC_ENFORCEMENT.md). The reporter is told the outcome category and that the matter is closed. | Handler | **21 calendar days** of acknowledgement |
+
+Deadlines may be extended **once**, by up to 14 days, with written notice to the
+reporter and a stated reason. A deadline missed by the project never counts
+against the reporter, and never shortens the appeal window in
+[`COC_APPEALS.md` §5](COC_APPEALS.md).
+
+**What the reporter is told at step 5:** the outcome category — that action was
+taken, or that no action was taken — and that the matter is closed. Reporters
+are **not** told the specific sanction applied to another person, which is that
+person's private information. If you believe a no-action decision was wrong, you
+may request one review under
+[`COC_APPEALS.md` §7](COC_APPEALS.md).
+
+## 5. Immediate protective measures
+
+Where conduct is ongoing and someone is at risk of further harm, the handler may
+act before the review in §4 concludes. Available immediate steps are limited to:
+
+- muting or temporarily removing someone from a channel;
+- hiding or removing specific content;
+- temporarily restricting repository interaction.
+
+An immediate measure is **provisional, not a finding**. It is time-boxed, it is
+communicated to the person affected with the reason, and it is confirmed,
+varied, or lifted when the review concludes. It carries the same appeal right as
+any other decision.
+
+Permanent sanctions are never applied as an immediate measure.
+
+## 6. Confidentiality
+
+This is the guarantee the rest of the document depends on.
+
+**What the project commits to:**
+
+1. **Your report is shared only with the people who need it to act** — the
+   handler, any unconflicted maintainer they must consult, and, on appeal, the
+   panel under [`COC_APPEALS.md` §4](COC_APPEALS.md). It is not discussed with
+   the wider maintainer team, in public channels, or with anyone else.
+2. **Your identity is not disclosed to the person reported** without your
+   consent, unless the substance of the allegation cannot be put to them without
+   it. Where that is the case, **you are told before it happens**, and you may
+   withdraw the report instead.
+3. **The person reported is told the substance of the allegation**, because a
+   decision taken against someone who was never told what they were accused of
+   is not a decision anyone can defend.
+4. **Records are minimised.** Enforcement outcomes are logged in
+   [`DECISION_LOG.md`](DECISION_LOG.md) by outcome category and date, with the
+   reporter not identified.
+5. **Evidence is retained only as long as needed** to decide the matter and any
+   appeal, then deleted — except where a legal or safeguarding obligation
+   requires retention, which is recorded.
+6. **Retaliation for reporting is itself a violation**, and a serious one
+   ([`CODE_OF_CONDUCT.md` §4.5](CODE_OF_CONDUCT.md)). This holds whether or not
+   your report was upheld.
+
+**The limits, stated plainly:**
+
+- Confidentiality cannot be absolute where there is a credible risk to someone's
+  physical safety, or where a legal obligation requires disclosure. If that
+  point is reached, you are told what must be disclosed and to whom, before it
+  happens where that is possible.
+- Anonymity limits what can be done with a report (§3.3).
+
+## 7. Withdrawing a report
+
+You may withdraw a report at any time before a decision is taken, and the
+project will normally close the matter.
+
+It will not close it where the conduct described is serious enough that the
+project must act to protect others — ongoing harassment, a credible threat, or a
+safeguarding concern. If that applies, you are told, and the matter proceeds
+without requiring anything further from you.
+
+## 8. Relationship to other documents
+
+| Document | Relationship |
+| --- | --- |
+| [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md) | The standard this process enforces; §3 sets where it applies and §4 what counts as a violation. |
+| [`COC_ENFORCEMENT.md`](COC_ENFORCEMENT.md) | What happens after a report is upheld — the graduated ladder and who applies it. |
+| [`COC_APPEALS.md`](COC_APPEALS.md) | Contesting a decision (§5), and review of a no-action decision (§7). |
+| [`SECURITY_POLICY.md`](SECURITY_POLICY.md) | The equivalent route for security vulnerabilities, which do not come here. |
+| [`policies/COMMUNICATION_NORMS.md`](policies/COMMUNICATION_NORMS.md) | Official channels and response-time norms for ordinary communication. |
+| [`DECISION_LOG.md`](DECISION_LOG.md) | Where outcomes are recorded, in minimised form. |
+
+## 9. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-09-29 | 1.0.0 | **Initial release.** Defines scope and routing (§1), who may report (§2), channels including the route for reporting a maintainer and anonymous reports (§3), the response timeline with deadlines (§4), provisional protective measures (§5), the confidentiality guarantee and its limits (§6), and withdrawal (§7). |
diff --git a/Governance/CODE_OF_CONDUCT.md b/Governance/CODE_OF_CONDUCT.md
new file mode 100644
index 00000000..01126852
--- /dev/null
+++ b/Governance/CODE_OF_CONDUCT.md
@@ -0,0 +1,194 @@
+# Code of Conduct
+
+| Field | Value |
+| --- | --- |
+| Document | `Governance/CODE_OF_CONDUCT.md` |
+| Status | Active |
+| Version | 1.0.0 |
+| Owner | Maintainer Team |
+| Last reviewed | 2026-09-29 |
+| Review cadence | Every 12 months, or after any change to the enforcement or appeals process |
+| Applies to | Everyone participating in a TeachLink Backend space (§3) |
+
+This document states the standard of behaviour expected in this project, the
+behaviour that is not acceptable, and where that standard applies.
+
+It is the authoritative statement of the conduct standard.
+[`CONTRIBUTING.md` §1](../CONTRIBUTING.md) gives the one-paragraph summary a new
+contributor reads first; this document is what that summary points to, and where
+the two differ, this document governs.
+
+It is governance only. It changes no application behaviour, adds no runtime
+dependency, and is scoped entirely to the `Governance/` folder.
+
+## 1. Our commitment
+
+We want TeachLink Backend to be a project where the quality of an idea matters
+and the identity of the person raising it does not.
+
+We commit to making participation free of harassment for everyone, regardless of
+age, body size, visible or invisible disability, ethnicity, sex characteristics,
+gender identity and expression, level of experience, education, socio-economic
+status, nationality, personal appearance, race, caste, colour, religion, or
+sexual identity and orientation.
+
+This is a commitment about behaviour, not belief. Nobody is asked to hold a
+particular view. Everyone is asked to treat other participants decently while
+working here.
+
+## 2. Expected behaviour
+
+| Expectation | What it looks like in practice |
+| --- | --- |
+| **Criticise the work, not the person** | "This query will N+1 on large courses" rather than "you clearly didn't think about this". |
+| **Assume competence and good faith** | Ask what someone was solving for before concluding they were careless. Most odd-looking code had a reason. |
+| **Be specific and actionable** | A review comment says what is wrong, why it matters, and ideally what would be better. "This is bad" is not review feedback. |
+| **Accept feedback on your own work** | Disagree with reasons, or accept the change. Neither sulking nor relitigating a settled decision is acceptable. |
+| **Respect people's time** | Search before asking, read the error before pasting it, and say what you already tried. |
+| **Respect stated boundaries** | If someone asks you to stop contacting them, stop. If someone states their pronouns or name, use them. |
+| **Own your mistakes** | Say what went wrong, fix it, and move on. Nobody is penalised here for an honest mistake reported early. |
+| **Leave space for others** | Newer contributors should be able to ask an obvious question without being made to feel foolish. |
+
+Reviewer and author duties in [`CONTRIBUTING.md` §9](../CONTRIBUTING.md) and the
+tone conventions in
+[`policies/COMMUNICATION_NORMS.md`](policies/COMMUNICATION_NORMS.md) sit
+underneath these expectations and are not restated here.
+
+## 3. Scope
+
+This Code of Conduct applies in every space the project operates in, and in any
+space where a person is representing the project.
+
+**Project spaces** — this Code applies fully:
+
+- the `rinafcode/teachLink_backend` repository: issues, pull requests, reviews,
+  commit messages, code comments, and discussions;
+- the [Telegram community](https://t.me/teachlinkOD);
+- any mailing list, call, or chat run by the project;
+- project documentation, including this folder;
+- any event, online or in person, that the project organises or sponsors.
+
+**Representing the project** — this Code applies to conduct that occurs
+elsewhere but is carried out in the project's name: posting from an official
+account, speaking as a TeachLink maintainer at an event, or acting as the
+project's representative in another community.
+
+**Outside the project** — conduct in unrelated spaces is not governed here, with
+one exception. Where off-project conduct is directed at a project participant
+*because of* their participation — targeted harassment, doxxing, or threats
+following a disagreement in this repository — it is in scope, because its effect
+lands squarely inside the project.
+
+The project does not police participants' unrelated personal, political, or
+professional lives.
+
+## 4. Unacceptable behaviour
+
+The following are violations of this Code. The list is illustrative, not
+exhaustive: conduct that is plainly contrary to §1 and §2 is a violation whether
+or not it appears here.
+
+### 4.1 Harassment and abuse
+
+- Sexualised language or imagery, and unwelcome sexual attention or advances.
+- Trolling, deliberately inflammatory comments, and sustained disruption of
+  discussion.
+- Insults, personal attacks, and derogatory comments — including about someone's
+  competence, when the point is to diminish rather than to inform.
+- Public or private harassment, including repeated unwanted contact after being
+  asked to stop.
+- Discriminatory language or jokes touching any characteristic listed in §1.
+- Threats of violence, or encouraging anyone toward self-harm.
+
+### 4.2 Privacy violations
+
+- Publishing another person's private information — physical or email address,
+  employer, legal name, or account handles they keep separate — without their
+  explicit permission.
+- Sharing the content of a private conversation, or of a conduct report, outside
+  the people entitled to see it under
+  [`COC_REPORTING.md` §6](COC_REPORTING.md).
+- Republishing material a person has asked to have removed.
+
+### 4.3 Abuse of position
+
+- Using a maintainer or reviewer role to pressure, retaliate against, or
+  advantage someone for reasons unrelated to the work.
+- Blocking or delaying a contribution on grounds other than its merit.
+- Bypassing the governance processes in this folder to achieve an outcome that
+  would not survive them.
+
+### 4.4 Bad-faith participation
+
+- Deliberately introducing a vulnerability, a backdoor, or a licensing problem.
+  (Reporting a vulnerability you discovered is the opposite of this — see
+  [`processes/VULN_DISCLOSURE.md`](processes/VULN_DISCLOSURE.md).)
+- Sustained plagiarism, or misrepresenting authorship, contrary to
+  [`policies/ATTRIBUTION.md`](policies/ATTRIBUTION.md).
+- Knowingly making a false conduct report. A report made in good faith that
+  turns out to be mistaken is **not** a violation; only a knowingly false one is.
+
+### 4.5 Retaliation
+
+Retaliating against someone for reporting a concern, appealing a decision, or
+taking part in either process — through review obstruction, exclusion, public
+criticism, or removal of a privilege — is itself a violation, and is treated as
+a serious one. This holds regardless of whether the original report was upheld.
+
+## 5. What is *not* a violation
+
+Recording this explicitly, because a Code of Conduct that is read as forbidding
+ordinary technical disagreement stops being used:
+
+| Not a violation | Why |
+| --- | --- |
+| Rejecting a pull request, or requesting substantial changes | Review is the job. Firm, specific, reasoned feedback is expected. |
+| Disagreeing with a maintainer, publicly | Disagreement is how decisions get tested. See [`processes/OBJECTION_HANDLING.md`](processes/OBJECTION_HANDLING.md). |
+| Closing an issue as out of scope | Scope decisions belong to maintainers; contest them through [`processes/CONFLICT_RESOLUTION.md`](processes/CONFLICT_RESOLUTION.md). |
+| Saying "this approach is wrong, and here is why" | Direct is not the same as disrespectful. |
+| Being slow to respond | Response times are norms, not obligations — see [`policies/COMMUNICATION_NORMS.md`](policies/COMMUNICATION_NORMS.md) §4. |
+| Making a mistake, including one that broke something | Mistakes are a cost of contribution, not misconduct. |
+
+The distinction throughout is **conduct toward people**, not positions on
+technical questions.
+
+## 6. Reporting and enforcement
+
+This document states the standard. Two companion documents carry it out:
+
+| Document | Answers |
+| --- | --- |
+| [`COC_REPORTING.md`](COC_REPORTING.md) | How to report, to whom, how fast you get a response, and what confidentiality you are guaranteed. |
+| [`COC_ENFORCEMENT.md`](COC_ENFORCEMENT.md) | What happens after a report is upheld: the graduated ladder of responses, the criteria for each step, and who may apply them. |
+| [`COC_APPEALS.md`](COC_APPEALS.md) | How to contest an enforcement decision, and the independent review it receives. |
+
+If you are reading this because something has happened, go straight to
+[`COC_REPORTING.md`](COC_REPORTING.md).
+
+## 7. Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][covenant],
+version 2.1, with project-specific additions: the scope boundaries in §3, the
+abuse-of-position and retaliation provisions in §4.3 and §4.5, and the
+not-a-violation list in §5.
+
+[covenant]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+
+## 8. Relationship to other documents
+
+| Document | Relationship |
+| --- | --- |
+| [`CONTRIBUTING.md` §1](../CONTRIBUTING.md) | The summary a contributor meets first; this document is its authoritative expansion. |
+| [`COC_REPORTING.md`](COC_REPORTING.md) | How a violation of this document is reported. |
+| [`COC_ENFORCEMENT.md`](COC_ENFORCEMENT.md) | What the project does when a violation is established. |
+| [`COC_APPEALS.md`](COC_APPEALS.md) | How an enforcement decision is contested and independently reviewed. |
+| [`policies/COMMUNICATION_NORMS.md`](policies/COMMUNICATION_NORMS.md) | Day-to-day tone, channels, and etiquette that sit underneath §2. |
+| [`policies/REVOCATION.md`](policies/REVOCATION.md) | Removal of a governance privilege, including on conduct grounds. |
+| [`processes/CONFLICT_RESOLUTION.md`](processes/CONFLICT_RESOLUTION.md) | Working disagreements, which are not conduct matters (§5). |
+| [`DECISION_LOG.md`](DECISION_LOG.md) | Where enforcement and appeal outcomes are recorded. |
+
+## 9. Change log
+
+| Date | Version | Change |
+| --- | --- | --- |
+| 2026-09-29 | 1.0.0 | **Initial release.** States the commitment (§1), expected behaviour (§2), scope including the off-project boundary (§3), unacceptable behaviour across harassment, privacy, abuse of position, bad faith and retaliation (§4), what is explicitly not a violation (§5), and the reporting, enforcement and appeals routes (§6). |
diff --git a/Governance/policies/STALE_ISSUES.md b/Governance/policies/STALE_ISSUES.md
new file mode 100644
index 00000000..7b0310aa
--- /dev/null
+++ b/Governance/policies/STALE_ISSUES.md
@@ -0,0 +1,148 @@
+# Stale Issue Policy
+
+**Document:** `Governance/policies/STALE_ISSUES.md`
+**Status:** Active
+**Last Updated:** 2026-09-29
+**Owner:** Maintainer Team
+
+---
+
+## Purpose
+
+This policy defines what makes an issue stale, the steps taken before it is closed, and how a closed issue is brought back. The goal is an issue tracker that reflects work someone actually intends to do, so that a contributor browsing it finds real work rather than a backlog of abandoned reports.
+
+It is the detailed counterpart to the summary in [`../processes/TRIAGE.md`](../processes/TRIAGE.md) § *Stale Issues*, and uses the same thresholds.
+
+---
+
+## Scope
+
+This policy applies to all issues opened against `rinafcode/teachLink_backend`.
+
+It does **not** apply to pull requests, which are covered by [`STALE_PRS.md`](STALE_PRS.md) on a shorter timer.
+
+---
+
+## Staleness Threshold
+
+An issue is considered **stale** when it has received **no activity for 60 calendar days**. Activity includes:
+
+- A comment from anyone.
+- A label, milestone, or assignee change by a maintainer.
+- A linked pull request being opened, updated, or closed.
+- A reaction from a maintainer signalling continued interest.
+
+The 60-day window restarts every time any of the above occurs.
+
+### Why 60 days, when a PR goes stale at 30
+
+The two artefacts decay differently, so they are timed differently.
+
+A **pull request** is in-flight work that rots on its own: the branch drifts from `main`, conflicts accumulate, and the review context fades from everyone's memory. Thirty days of silence usually means the work has stopped.
+
+An **issue** is a statement that something is wrong or missing. A bug nobody has reached is still a bug after two months, and an unclaimed feature request is not invalid merely because the queue is long. Closing issues on a PR's timer discards valid reports and teaches contributors that filing one is pointless.
+
+Sixty days matches `status: stale` in [`../LABEL_TAXONOMY.md`](../LABEL_TAXONOMY.md) and the triage process. All three should be changed together if the threshold is ever revised.
+
+---
+
+## Warning and Closing Steps
+
+When an issue becomes stale, the following sequence is followed:
+
+### Step 1 — Stale Label and Comment (Day 60)
+
+The `status: stale` label is applied and a comment is posted:
+
+> *"This issue has had no activity for 60 days and has been marked stale. If it is still relevant, please leave a comment saying so — a single comment is enough to keep it open. Without a response it will be closed on [date = Day 74]. Closing is not a judgement on the report; it can be reopened at any time."*
+
+The comment names the closing date explicitly. "Will be closed soon" gives nobody a reason to act today.
+
+### Step 2 — Maintainer Check (Day 67)
+
+If there is still no activity 7 days after the label is applied, a maintainer checks whether the issue should be exempt rather than closed:
+
+- Is it still reproducible, or still a genuine gap?
+- Is it blocked by something outside any contributor's control?
+- Is it a valid report that simply has not been prioritised? If so, it is a backlog problem, not a stale one — apply `status: blocked` or a milestone and remove the stale label.
+- Is it a good candidate for a new contributor? If so, label it per [`GOOD_FIRST_ISSUE.md`](GOOD_FIRST_ISSUE.md) and remove the stale label rather than closing it.
+
+The maintainer records their assessment in a comment.
+
+### Step 3 — Closure (Day 74)
+
+If there is no activity for **14 calendar days** after the stale label is applied (74 days total since last activity), the issue is **closed as not planned** with:
+
+> *"Closing this issue due to inactivity. This is not a judgement on whether the problem is real — it keeps the tracker reflecting active work. If this still affects you, comment here and it will be reopened; no new issue is needed."*
+
+Issues are closed **as not planned**, never as completed. Closing an unfixed bug as completed corrupts the project's own history and any metrics drawn from it.
+
+The `status: stale` label remains on the closed issue for historical filtering.
+
+---
+
+## Exemptions
+
+The following prevent the stale timer from applying:
+
+| Situation | Action |
+|---|---|
+| Issue is labelled `status: blocked` | Timer is paused; the maintainer must document the blocker |
+| Issue is assigned to a milestone | Timer is paused until the milestone closes or the issue is removed from it |
+| Issue is labelled `priority: critical` or `priority: high` | Never auto-closed. Sustained inactivity here is a triage failure, and is escalated per [`../processes/TRIAGE.md`](../processes/TRIAGE.md) rather than resolved by closing the issue |
+| Issue is a confirmed security report | Never auto-closed; governed by [`../SECURITY_POLICY.md`](../SECURITY_POLICY.md) and [`../processes/COORDINATED_DISCLOSURE.md`](../processes/COORDINATED_DISCLOSURE.md) |
+| Issue tracks a governance decision | Timer is paused until the decision is recorded in [`../DECISION_LOG.md`](../DECISION_LOG.md) |
+| Issue has an open linked pull request | Timer is paused; [`STALE_PRS.md`](STALE_PRS.md) governs the PR |
+| Issue is labelled `status: on hold` | Timer is paused until the hold is lifted |
+
+A `good first issue` is **not** exempt, but under step 2 it is refreshed rather than closed where it remains a genuine entry point.
+
+---
+
+## Reopen Path
+
+**Any person may reopen a stale-closed issue by commenting on it.** No new issue, no justification, and no maintainer permission is needed — a comment saying the problem still occurs is sufficient.
+
+On reopening:
+
+1. The `status: stale` label is removed.
+2. The issue re-enters triage per [`../processes/TRIAGE.md`](../processes/TRIAGE.md), and the 60-day timer restarts from the reopening comment.
+3. If the original report was thin, the person reopening is asked — not required — to add current reproduction details.
+
+If you cannot reopen the issue yourself, comment anyway; a maintainer reopens it at triage.
+
+There is no limit on how many times an issue may be reopened, and no penalty for having one closed as stale.
+
+---
+
+## Maintainer Responsibilities
+
+- Review the stale issue list as part of the weekly backlog review, alongside stale PRs.
+- Never close an issue without the step 1 warning and its stated date.
+- Check the exemption table before closing, not after.
+- Remove `status: stale` promptly when activity resumes, so the label stays meaningful as a filter.
+- Treat a high volume of stale closures as a signal about triage capacity, not as housekeeping done well.
+
+---
+
+## Metrics
+
+Maintainers should track monthly:
+
+- Number of issues marked stale.
+- Number of stale issues closed vs. rescued (activity resumed before closure).
+- Number of stale-closed issues later reopened — a high figure means the threshold or the exemptions are wrong, not that contributors are being difficult.
+- Median age of open issues at the point of being marked stale.
+
+These feed the reporting in [`TRANSPARENCY_REPORTS.md`](TRANSPARENCY_REPORTS.md) and [`PUBLIC_METRICS.md`](PUBLIC_METRICS.md).
+
+---
+
+## Related Documents
+
+- `Governance/policies/STALE_PRS.md` — the equivalent policy for pull requests, on a 30-day timer
+- `Governance/policies/INACTIVITY.md` — inactivity of people, as distinct from artefacts
+- `Governance/processes/TRIAGE.md` — issue triage, including the stale summary this policy expands
+- `Governance/LABEL_TAXONOMY.md` — label definitions, including `status: stale`
+- `Governance/policies/GOOD_FIRST_ISSUE.md` — criteria for issues kept open as entry points
+- `CONTRIBUTING.md` — general contribution guidelines