Legal

Tenant Terms of Service

Version 1.3 · effective 2026-12-01. Notice given 2026-09-19 under §14, so it does not bind until the effective date above. Published during the notice period because §14 promises presentation BEFORE the change binds.

These are the terms a farm accepts inside the Koklo Nya application, recorded against this version number. They are not the website terms, which govern use of www.koklonya.com.

Version: 1.3 Effective date: 2026-12-01 (notice given 2026-09-19 — see §14)

⛔ v1.3 CHANGES WHO ACCEPTS THESE TERMS — AND NOTHING ELSE. These terms are the contract between the operator and your farm or organization (the tenant), not between the operator and each person who signs in. From v1.3 they are accepted once per version, on the tenant's behalf, by someone holding the tenant.terms.accept permission — or by the person who creates the tenant, as they create it. Every other user is asked only to acknowledge the terms and the Privacy Policy for themselves, and no longer confirms "authority to bind" anyone. A tenant that has not accepted the version in force becomes read-only from its effective date until it does. See §14 and §14.4.

⚠ Notice is given by publication, because the platform has no third-party tenants (§14.1). This version was published on 19 September 2026 at www.koklonya.com/tenant-terms-v1.3.html, and the notice runs from that day — 73 days before it takes effect, against the 30 that §14 owes. The effective date is 2026-12-01 and it is settled.

Retained from v1.2, for the record. It describes v1.2's own effective date, not v1.3's.

⛔ THE v1.2 EFFECTIVE DATE MOVED FROM 2026-10-15 TO 2026-11-15 ON 14 SEPTEMBER 2026, AND THE REASON IS THE NOTICE, NOT THE TERMS. §14 requires written notice to each tenant owner's contact email. The version was PUBLISHED on 2026-09-13 and no email was sent — on the footing that §14.1 states there are no third-party tenants, so publication reached everyone it had to. If that footing is wrong, the notice was defective and no date in this document would have cured it. Moving the date is the remedy that costs nothing and presumes nothing: a notice served any time up to 2026-10-16 still carries the full 30 days. ⚠ Nothing in the terms themselves changed with this move. Supersedes: v1.2, effective 2026-11-15, which remains the version in force until 2026-12-01 (v1.1, effective 2026-07-31, is in force until 2026-11-15) Acceptance: once per version on the tenant's behalf, by a holder of tenant.terms.accept or by the tenant's creator at creation; and a personal acknowledgement by every user on first sign-in. Both recorded in public.tenant_ts_acceptance (id, tenant_id, user_id, document, version, capacity, basis, accepted_at, ip_address, user_agent)

Retained from v1.1, for the record.

Note on v1.1. v1.1 adds §1.1 (statutory positions, not advice) and a related responsibility in §6. That is a material change, so §14 would normally require 30 days' notice and explicit re-acceptance. There was no incumbent acceptance to supersede when v1.1 was written: public.tenant_ts_acceptance did not exist in any migration and no tenant had ever accepted v1.0, so no notice window was running and none was owed. That is no longer true — migration 20260722000142_tenant_terms_acceptance created the table, and the acceptance step is live. The §14 process governs every change from here.

Retained from v1.2, for the record.

⛔ Correction of 7 September 2026 — READ THIS BEFORE RELYING ON THE VERSION NUMBER. The "Cross-border transfer rationale" in §2 previously stated that the Ghana Data Protection Commission had recognised the UK and EU as "adequate", and that transfer was therefore lawful "without requiring additional Standard Contractual Clauses or your individual consent". That was wrong. The Data Protection Act 2012 (Act 843) contains no cross-border transfer provision, no mechanism for declaring a country adequate, and no such function among the Commission's functions under s.3 — so there was no recognition to rely on and none could have been made. A statement of that kind, in a document about a tenant's own compliance, must not stand for a day longer than it takes to correct, so the passage has been rewritten in place to set out what Act 843 in fact requires and where the assessment actually lies.

✅ That correction shipped as v1.2, effective 2026-11-15. The correction is material, so §14 governs. ⚠ The effective date is LATER than §14's minimum, and deliberately so — it is not the end of a 30-day count from the publication date of 2026-09-13, which would have been 2026-10-13. §14 requires at least 30 days' written notice, and the extra room exists so that a notice served as late as 2026-10-16 still carries its full 30 days. Until 2026-11-15 v1.1 remains the version in force — you are not asked to re-accept before the notice period you are owed has elapsed.

The version is declared in two places and they move together: this header, and LEGAL_VERSION_SCHEDULE in packages/shared/src/schemas/legal-consent.ts. That schedule carries v1.2 with an effectiveFrom of 2026-11-15, so the consent gate keeps accepting v1.1 until the date arrives and then asks for v1.2 on the next sign-in — without a second deployment, and without locking anyone out during the notice period. Determined and recorded at docs/audit-reviews/CA_DETERMINATION_data_residency_act915_s27_2026-09-07.md, Addendum 1 §A1.6 and Addendum 2.

This Terms of Service governs your tenant's use of Koklonya. These terms bind your farm or organization (the "tenant") once they have been accepted on its behalf by someone with authority to do so — see "Acceptance" at the end. By signing into Koklonya you confirm that you have read and understood them. If you do not agree, do not sign in.

Plain-English version first. A more formal contract section follows for legal review. Where the two conflict, the formal section governs.

1. What Koklonya is

Koklonya is a multi-tenant ERP for poultry farms, operated from Ghana by Edem Segbefia trading as Koklonya (the "operator"). It records your farm's daily production, mortality, sales, procurement, payroll, and accounting data, and produces IFRS-acceptable financial reports for your auditor.

You retain ownership of all data you put into Koklonya. The operator processes that data on your behalf to deliver the service you signed up for, and for no other purpose.

1.1 Statutory positions, not advice

Koklonya applies published rules — tax rates, thresholds, accounting standards — to the figures you enter, and shows you the position those rules produce. That is a computation of general application, not advice about your particular circumstances.

In plain terms:

• What the software does. It surfaces the statutory position that the rules produce on your own data, and shows the provision it relied on so you can check it.
• What it does not do. It does not advise you on your tax affairs, does not tell you what you ought to do about your position, and does not act for you before the Ghana Revenue Authority or any other authority.
• What remains yours. Every return, declaration and filing is made and signed by your own authorised officer. You are the taxpayer of record.
• Please confirm. Statutory positions the software surfaces should be confirmed with your own tax adviser, or with the GRA, before you rely on them — particularly where the amounts are material or your circumstances are unusual.

Where the software shows a figure or an obligation, it is telling you what the rules produce on the facts entered. It is not telling you what to do.

The operator is not your tax adviser, accountant or auditor, and nothing in the service creates that relationship. Where the operator has obtained professional opinions to configure the software correctly, those opinions were obtained for the operator's own purposes — they are quality assurance on the configuration, not advice given to you, and you may not rely on them as such.

2. Where your data lives

Cross-border transfer rationale. Your data is collected in Ghana and stored in the United Kingdom. The Data Protection Act 2012 (Act 843) does not gate that transfer, and no Ghanaian regulator has approved it. ⚠ That statement is about Act 843, which is the statute governing personal data. It is not a claim that no other Ghanaian law bears on where your records sit — Act 915 s.27 requires tax records to be maintained within the country, and sector regulators may impose their own requirements on your farm. §10 sets out the retention duties the operator implements; anything specific to your circumstances is yours to check. The Data Protection Act 2012 (Act 843) contains no provision permitting or restricting the transfer of personal data out of Ghana, no mechanism for declaring a foreign country "adequate", and no such function among the Data Protection Commission's functions under s.3 (implement and monitor compliance; make administrative arrangements; investigate complaints; keep the Data Protection Register). There is therefore no adequacy decision for anyone to rely on, no Ghanaian equivalent of Standard Contractual Clauses to sign, and no transfer-specific consent for you to collect. Where the Act does mention foreign law, it points the other way: s.18(2) governs personal data sent into Ghana from a foreign jurisdiction, not Ghanaian data sent out.

What Act 843 does instead is follow the data. Under s.45(1)(c) the Act applies to processing "in respect of information which originates partly or wholly from this country" — so your data does not leave Ghanaian law by leaving Ghana. Under s.30(2) and (3) the processing must be governed by a written contract obliging the processor to maintain the confidentiality and security measures necessary to ensure the integrity of the data. Under s.30(4), "where a data processor is not domiciled in this country, the data controller shall ensure that the data processor complies with the relevant laws of this country". Under s.28 the controller must take appropriate, reasonable, technical and organisational measures against loss, damage, unauthorised destruction and unlawful access. Those duties apply to your data on eu-west-2 exactly as they would to a filing cabinet in Accra.

What that means for you. Your tenant is the data controller and the operator is your processor (§12), so the s.30(4) duty is yours. The operator's job is to make it dischargeable: these terms and the Privacy Policy are the written contract s.30(2) requires between you and the operator; each sub-processor listed in §13 is engaged on terms requiring confidentiality and security; and §3 sets out the measures actually in place, which you may cite in your own records. Whether hosting your farm's personal data in the United Kingdom is appropriate for your circumstances is an assessment Act 843 leaves to you as controller — it is not one any Ghanaian authority has made for you, and if the answer is not obvious for your farm you should take your own advice. The destination is relevant to that assessment: the United Kingdom maintains its own data protection regime (UK GDPR and the Data Protection Act 2018). That is a fact about where your data sits, not a ruling by any Ghanaian regulator, and these terms do not present it as one.

A Ghana-resident read-only mirror of your data is maintained on operator hardware once your tenant reaches Phase 1 of the operator's infrastructure plan (typically when you sign as a paying customer). The mirror improves analytics performance and offers a disaster-recovery target; it does not change the writeable system of record, which remains in eu-west-2.

If your farm has a regulatory or contractual requirement that data must be hosted inside Ghana, contact the operator before signing in. Koklonya cannot satisfy that requirement today.

3. Security & access

• Encryption in transit: TLS 1.3 enforced on every connection to and from the system.
• Encryption at rest: Supabase Pro encrypts the database with KMS-managed keys. Storage buckets (mortality photos, branding assets, user avatars) are private by default and accessed via signed URLs with finite TTLs.
• Authentication: email + password via Supabase Auth, with optional TOTP-based two-factor. Two-factor is required for any user assigned a role that holds tenant.billing.manage or financials.period.close permissions, after that user's first 30 days.
• Authorization: role-based access control with system, default, and tenant-custom roles. Every mutation is gated by an explicit permission key.
• Audit log: every change to your data attempts an append-only audit row recording who did what, when, from which IP, and with what before/after state. The write is synchronous and best-effort (non-blocking on audit failure): if it fails, the change still completes and the failure is logged to our error tracker, so gaps are possible. What a gap costs: the underlying change is still visible in your data, but the audit details of the missed row — who acted, from which IP and user agent, and the before/after values — are not recoverable. Audit rows are retained for at least as long as the record the row describes, plus any extension or legal hold that applies to that record — see §10; that is 6 years for tax and accounting records, 12 years for payroll records, statutory identifiers and employment contracts, and up to 12 years for some farm records. Audit rows are not included in the self-service export, which covers the public and accounting data only; ask us and we will extract the audit slice for your tenant manually.
• Idempotency: safe retries are supported via a 24-hour idempotency-key replay window so a flaky network connection cannot cause double charges, double mortality entries, or duplicate batch placements.

The operator does not access your tenant's data except for support work you have requested. When operator staff act on a tenant's behalf, the action runs through an explicit time-limited "impersonation" mechanism that records both a tenant-side audit row and an operator-side audit row, both linked to a support ticket reference.

4. Backups & disaster recovery

• Supabase Pro takes daily logical backups with 7-day point-in-time recovery (PITR) on the application database.
• The operator runs a nightly off-site backup pipeline that exports an encrypted logical dump to Backblaze B2 cold-tier storage. ⚠ These copies persist for up to about 7 years and 3 months. The bucket's lifecycle hides a backup from ordinary listing after 90 days, and permanently deletes it 7 years after that hiding — so a copy can persist about 2,645 days from the night it was taken. The 90-day figure is visibility, not deletion, and an earlier version of these terms wrongly stated it as the retention period.
• A restore-drill exercise is performed quarterly on a staging environment to verify the recovery procedure. Results are documented in docs/RUNBOOK_restore_drill.md and available on request.

Recovery objectives:

• RPO (recovery point objective): ≤ 24 hours
• RTO (recovery time objective): ≤ 12 hours for the application; ≤ 24 hours for the database

These objectives are best effort, not contractually guaranteed in this version of the terms. A future enterprise tier may carry contractual SLAs.

5. Service level (Phase 0)

For the first phase of the service (pre-30 tenants), the operator targets:

Service credits, refunds, and contractual SLAs are not available in this version. The operator publishes a public status page at https://status.koklonya.com for incident communication.

6. Your responsibilities

You agree to:

• keep your sign-in credentials secret;
• enable two-factor authentication for any user with elevated permissions;
• review and approve the role assignments for every user you invite;
• pay for the service plan you have selected;
• comply with applicable Ghanaian tax law, the Companies Act 2019, and the Ghana Veterinary Council's notifiable-disease reporting requirements when using the corresponding modules;
• satisfy yourself that any statutory position the software surfaces is correct for your circumstances before relying on it, and confirm it with your own tax adviser or the GRA where the amounts are material (see §1.1) — you remain the taxpayer of record and your own authorised officer signs every return;
• use the service for lawful purposes only.

You agree NOT to:

• attempt to reverse-engineer, decompile, or scrape the application except for legitimate data-export purposes via the published export tools;
• circumvent rate limits or RLS policies;
• use the service to store data unrelated to the operation of a poultry farm;
• introduce malicious code or attempt to compromise the operator's infrastructure.

7. Pricing & billing

The pricing model in effect at sign-up is documented separately and forms part of these terms by reference. You may upgrade or downgrade your plan via Settings → Billing. The operator may change pricing for future billing cycles with at least 30 days' notice; your existing billing cycle is unaffected.

Phase 0 (pre-public launch). During the operator's Phase 0 trial period, Koklonya is provided to invited tenants at no charge. Phase 0 may be ended with 60 days' notice, after which a paid plan must be selected to continue using the service. Your data is preserved across this transition.

8. Suspension & termination

The operator may suspend or terminate your tenant for:

• non-payment of fees overdue more than 30 days;
• material breach of these terms after 14 days' written notice and an opportunity to cure;
• legal compulsion (court order, regulatory action) in which case the operator will notify you to the extent legally permitted.

You may terminate your tenant at any time via Settings → Data & privacy → Request termination. On termination:

1. The operator immediately stops accepting new writes to your tenant.
2. A data export (a single JSON file, as described in §9) is generated and made available to you for 30 days. ⚠ It covers your public and accounting tables only — it does not include attached files or audit-log rows, which you should retrieve separately before deletion (see §9); two files are produced: the tenant export described in §9, and a separate export of your own personal/account record.
3. After 30 days, all tenant data is deleted from the application database. ⚠ Backups are on a different clock: encrypted, access-restricted backup copies are not selectively edited and remain until B2's lifecycle permanently deletes them at 7 years (§4) — the 90-day figure there is when a copy stops being listed, not when it is destroyed. The application-database deletion excludes every retained record class listed in §10 — the records kept for tax purposes, the payroll, statutory-identifier and employment-contract records, the other accounting records kept as operator policy, the audit-log entries that describe those retained records (entries describing anything else follow the ordinary deletion above), the farm-record classes on their longer traceability periods, and notifiable-disease reports. Those are retained for the periods §10 states, on the basis §10 gives for each (legal obligation in some cases, operator policy in others). When a period expires the record becomes eligible for deletion and is deleted as §10 describes; we do not promise deletion at the moment a period ends, so it may persist under the same protections for some time after. ⚠ Backups are not edited in place. Off-site backup copies are not selectively rewritten to remove a deleted tenant; a copy persists until B2's lifecycle permanently deletes it — hidden after 90 days, deleted at 7 years (§4) — encrypted and access-restricted throughout, and is not restored into the live system except in a disaster-recovery event.
4. Aggregated, fully de-identified usage metrics may be retained indefinitely for product analytics.

9. Data export & portability

If your role holds the tenant.data.export permission, you may export your tenant's data at any time without termination via Settings → Data & privacy → Export. Exports are produced as a single JSON file containing:

• a single JSON file (koklonya-tenant-export-<tenant>.json), containing one entry per table you have permission to read across the public and accounting data;
• your own personal record is separately available as koklonya-account-export-<user>.json.

The export is gated on the tenant.data.export permission, and each export attempts an audit-trail entry on the best-effort basis described in §3.

⚠ What the JSON export does NOT include, stated plainly because an earlier version of these terms said otherwise: it is not a ZIP, there are no per-report CSV files, no attached files (mortality photos, branding assets, avatars), and no audit-log rows. Attachments remain available in the application, an audit slice can be extracted for you on request (§3), and the archive export below carries the attached files themselves.

There is also an archive export, and it DOES carry your document bytes. Alongside the JSON file, Settings → Data & privacy offers a gzipped tar (koklonya-tenant-export-<tenant>-<timestamp>.tar.gz) containing the same row bundle plus the stored documents themselves. It is gated on the same tenant.data.export permission and on the same sensitivity rules that apply in the application — a document you may not read there is not included here either, and the archive's manifest names every document it withholds and why. The paragraph above describes the JSON file only.

On rate limiting. A global cap of 300 requests per 5 minutes per IP address applies across the API and therefore to exports. Since 13 September 2026 a concurrency limit applies as well: one tenant export runs at a time per server process, and a request that arrives while another is still running is refused with 429 and a Retry-After header rather than being queued. It bounds memory on the server rather than your entitlement — it does not reduce what you may export, or how often, only how many may run at once. ⚠ This section previously said that no per-user, per-tenant, concurrency or queue limit existed, and reserved the right to introduce one "and will say so here if we do". This paragraph is that notice, given in place as the reservation provided.

10. Legal retention obligations

The operator may retain certain records beyond your termination date. Some of these retentions are required by Ghanaian law; others are periods we set ourselves or have not yet verified against a statute, and the source column below says which is which — the farm-record periods, for instance, are set on our Chartered Accountant's advice against Veterinary Services Directorate and EPA Ghana traceability requirements. As of the effective date of these terms, retained records are:

Some farm records are kept longer than six years. These periods are operator policy, set on the advice of our Chartered Accountant and based on Veterinary Services Directorate (MoFA) and EPA Ghana traceability requirements. We have not identified a Ghanaian statute that fixes a number for them; that reflects the sources we reviewed rather than an exhaustive survey of every statute, regulation and sector rule, so we describe them as policy rather than as a legal minimum. The classes are listed separately but may overlap — a treatment entry can also be a movement record — and where a record falls into more than one, the longest applicable period governs:

Notifiable-disease reports are the 5-year row in the table above and are not included in the 10-year veterinary class. Audit-log entries describing any of these records are kept for at least as long as the record itself.

The six-year period does not always start on the transaction date. Under Act 915 it runs from the "relevant date" for the record, and where a matter touching those records is open, retention continues until the longer applicable period ends — noting that an investigation runs to written notice of completion, an objection or appeal to a decision that has been carried out, an application to its determination, and a refund claim to payment. In practice this means we may hold these records longer than six years where a tax matter concerning them is still live.

Retained records are encrypted, access-restricted, and used only for the purpose that triggered retention — a legal obligation where one applies, and otherwise the purpose stated above for each class. They are not used to identify you, except where the legal obligation or operator-policy purpose that triggered retention itself requires identification — for example producing a named payroll or tax record to an authority that demands it — and are not used for any other purpose.

On deletion, so the commitment matches what the system does. When a record's retention period ends it becomes eligible for deletion; we do not promise that deletion happens at that moment, and a record may remain in encrypted, access-restricted storage for some time after its period ends. It stays subject to every protection above throughout and is never used for another purpose. You may ask us to confirm the status of a retained record, or request deletion of one whose period has expired, through the data-subject request route described in the Privacy Policy (§12).

11. Limitation of liability

To the fullest extent permitted by Ghanaian law:

• the operator's total aggregate liability to your tenant under these terms in any 12-month period is limited to the fees you paid the operator during that period;
• the operator is not liable for indirect, consequential, special, exemplary, or punitive damages;
• the operator is not liable for losses arising from third-party services (Supabase, Cloudflare, telecommunications providers, payment gateways) where the loss is caused by the third-party's fault and not the operator's;
• nothing in these terms limits liability for fraud or for any liability that cannot be excluded under Ghanaian law.

The service is provided "as is." Specific warranties of merchantability or fitness for a particular purpose are disclaimed except as expressly stated in these terms.

12. Privacy

A standalone Privacy Policy is published at https://koklonya.com/privacy and forms part of these terms by reference. The Privacy Policy describes what personal data Koklonya processes, why, with whom it is shared (no third party for advertising; Supabase / Cloudflare / Backblaze as named sub-processors), how it is secured, and the rights of data subjects under the Ghana Data Protection Act 2012.

You are responsible for the lawful basis on which your tenant collects personal data about its own employees, customers, and suppliers, and for providing them with the privacy notices required under Ghanaian law. Koklonya is the processor of that data on your behalf; your tenant is the controller.

13. Sub-processors

The operator engages the following sub-processors as of the effective date:

The operator gives at least 30 days' notice via email and via the in-app notifications channel before adding or replacing a sub-processor that processes personal data.

14. Changes to these terms

The operator may update these terms from time to time. Material changes (anything affecting your data, your liability, your costs, or your termination rights) require:

• at least 30 days' written notice to the tenant owner's contact email — except that, while every tenant of the platform is operated by the operator itself for testing, notice is given by publishing the new terms at their address on www.koklonya.com at least 30 days before they take effect, and no email is sent;
• presentation of the new terms in the application on next sign-in;
• explicit re-acceptance on the tenant's behalf by a user holding the tenant.terms.accept permission, recorded in tenant_ts_acceptance. That permission is held by the tenant owner and may be given to another officer — a director or company secretary, for instance — through a role. Accepting requires multi-factor authentication. Every user is also asked to acknowledge the new terms personally; that acknowledgement binds no one.

If the new terms have not been accepted on the tenant's behalf by their effective date, your tenant becomes read-only from that date: you can still sign in, read your records and export your data, but no changes to your tenant's records are accepted until the terms are accepted. Each user can still manage their own account — their profile, notification preferences and notifications, the security of their own sign-in (multi-factor enrolment and recovery codes, re-authentication, locking their own account), and closing their own account — and can still request that the tenant be erased, or cancel that request. These are not withheld while a tenant is read-only: a disagreement about the terms is between the operator and the farm, and it does not reach a person's ability to secure or leave their own account. If they have still not been accepted 30 days after the effective date, the operator will prepare and offer your full data export, and your tenant will be terminated under §8.

(Until v1.3 this bullet named the tenant.settings.manage permission. That permission edits a tenant's name, branding and locale; authority to bind the tenant to a contract must not ride on it. See §14.4.)

14.1 Notices given under this section

⚠ How the v1.2 notice was given, stated exactly rather than left to be assumed. §14 requires written notice to the tenant owner's contact email. At the date of this notice the platform has no third-party tenants: the estate is pre-revenue and every tenant in it — including the operator's own pilot farm — holds disposable test data. There was therefore no tenant owner outside the operator to write to, and no email was sent. The notice is given by publication: this section, and version 1.2 of these terms published at www.koklonya.com/tenant-terms-v1.2.html, both dated 2026-09-13. The 30-day window runs from that date regardless, and the version in force does not change until it elapses. ⚠ The window is 63 days, not 30, and the reason CHANGED on 14 September 2026. It was originally 32 — a couple of days past the minimum, so that a publication slipping by a day could not shorten what you are owed. It is now 63, because the effective date moved from 2026-10-15 to 2026-11-15: no email was sent, and if the footing above is wrong the notice was defective, so the date was pushed out to leave room for a notice that is actually served. §14 owes you at least 30 days; a remedial notice sent as late as 2026-10-16 still carries its full 30. For any future material change this is not the procedure — once a tenant of record exists, the email §14 requires is owed, and it is an operational step no code performs.

⚠ The v1.3 notice date is 19 September 2026, not the 17th, and the difference is the whole point of "notice by publication." The 17th is when the text was WRITTEN; nothing was served that day, because the page reaches the public web only when main moves — deploy-marketing.yml publishes apps/marketing/public/** on push to main. That happened when PR #969 merged as 340ff43 at 17:30:51 UTC on 19 September 2026, and the marketing deploy completed at 17:30:55 UTC. All three versions were then served: v1.1, v1.2 and v1.3 each return 200. Where publication is the notice, the notice date is the deploy, not the draft — and a table that names the drafting date overstates the notice by however long the merge took. Here that is two days against a 73-day window, which changes nothing owed; it is corrected because a notice table that cannot be reconciled with the deploy record is worth less than one that can.

✅ The footing was confirmed on 17 September 2026. The operator confirmed that every tenant on every environment — including the operator's own pilot farm — is fictitious test data. There is no third-party tenant, so publication reached everyone §14 required notice to reach, for v1.2 and for v1.3 alike.

14.2 Notice of change — v1.2, given 2026-09-13

What was wrong. v1.1 told you that the Ghana Data Protection Commission had recognised the United Kingdom and the European Union as providing "adequate" protection, and that transfer of your data to London was therefore lawful without Standard Contractual Clauses or your consent. That was incorrect. The Data Protection Act, 2012 (Act 843) contains no cross-border transfer provision, no mechanism for declaring a country adequate, and no such function among the Commission's functions under s.3 — so there was no recognition to rely on, and none could have been made. Section 18(2), the provision that statement was reaching for, governs data sent into Ghana, not out of it.

What is true instead. Act 843 does not gate the transfer on the destination. It applies to your data wherever it goes (s.45(1)(c)), and it places the duty on you as data controller: under s.30(4), where a data processor is not domiciled in Ghana, the controller "shall ensure that the data processor complies with the relevant laws of this country", under a written contract meeting ss.30(2)–(3) and with the security measures required by s.28.

What this changes for you. Nothing about where your data is held, who can reach it, or what the operator does with it — §2's hosting table and §3's measures are unchanged. What changes is the basis: the lawfulness of the transfer rests on your own assessment as controller and on the operator's contractual undertakings, not on a regulatory finding that does not exist. If your farm relies on that assessment for its own compliance, this is the paragraph to re-read.

Your options under §14. You may accept the corrected terms when they are presented on sign-in from 2026-11-15. If you do not wish to continue on this basis, tell the operator before that date and your full data export will be prepared and offered, with termination under §8. You are not asked to re-accept, and nothing is withheld from you, before 2026-11-15.

14.3 Amendment to v1.2 before it took effect — §9, 2026-09-13

What was wrong. §9 described the export as it stood on 12 September 2026 and was overtaken by the software within a day, in two directions at once:

• it said there was no per-user, per-tenant, concurrency or queue limit on export generation. A concurrency limit shipped on 13 September: one tenant export at a time per server process, refused with 429 and Retry-After rather than queued;
• it said the export is not a ZIP and carries no attached files. That remains true of the JSON file, but an archive export (.tar.gz) that does carry the stored document bytes is available in the application and was not mentioned at all.

Why this is a correction and not a fresh material change. Three reasons, stated so the reasoning can be checked rather than taken on trust:

1. §9 reserved this exact right. It said a limit may be introduced "and will say so here if we do". Saying so here is the promise being kept, not a term being altered.
2. v1.2 had not taken effect. The version in force remains v1.1 until 2026-11-15; this amendment lands inside the notice window and changes no term anyone is currently bound by. The effective date is unchanged and the 30-day window is not restarted or shortened.
3. The archive half only widens what you receive. Being told about an export that carries more of your data takes nothing away.

⚠ The one part that is adverse is the concurrency limit, and it is named rather than buried. It restricts how many exports may run at once — not what you may export, or how often. A refused request returns 429 with Retry-After and succeeds on retry.

The published page is regenerated from this document, and a control refuses to let the two drift. The v1.2 notice was given by publication at www.koklonya.com/tenant-terms-v1.2.html. That page is built from this file by npm run legal:build, and npm run check:legal-pages fails while it is stale — it reported STALE … tenant-terms-v1.2.html the moment this amendment was written, which is how the drift was caught rather than remembered. The regenerated page ships in the same commit as this text.

⚠ Publishing that page is NOT a separate operational step, and saying it was mis-stated when the notice clock starts. deploy-marketing.yml publishes apps/marketing/public/** on every push to main, so the merge IS the publication: no one deploys the page deliberately, and no one can forget to. That is the better arrangement — it removes a manual step between writing a notice and serving it — but it means the notice date is decided by when a pull request merges, which is why §14.1's v1.3 row is dated from 340ff43 and not from the day the text was drafted. The email §14 will owe once a tenant of record exists remains a genuine operational step that no code performs.

14.4 Notice of change — v1.3, WHO accepts these terms

What was wrong. Up to v1.2 these terms said three different things about who accepts them. The header said acceptance was "required on first sign-in by every user". This section said re-acceptance was by "a user with tenant.settings.manage permission". And the closing Acceptance section had every person who signed in confirm that they "have authority to bind your farm or organization" — which is not true of most people who use a farm's system, and so was weak evidence that the farm itself had agreed to anything.

What is true instead. These terms are the tenant's contract. So:

1. The tenant accepts each version once, through a person holding the tenant.terms.accept permission — the tenant owner by default, or an officer the owner gives that permission to. Accepting requires multi-factor authentication. The person who creates a tenant accepts on its behalf as they create it. The record says who accepted, under which of those two authorities, which version, and when.
2. Every user acknowledges the terms and the Privacy Policy personally on first sign-in. That acknowledgement confirms they have read them; it does not bind the tenant and does not claim authority to.
3. Until a version in force has been accepted on the tenant's behalf, the tenant is read-only — records stay readable and the data export stays available. After 30 days in that state, §8 termination follows, with the export offered.

Why this is a material change. It changes whose act binds the tenant and what follows when that act does not happen — both within §14's own definition. It is treated as material, with its own notice, rather than as a correction.

What this changes for you. If you are the tenant owner, you will be asked to accept v1.3 on your farm's behalf — the request appears once this version is published, and what it binds takes effect on 2026-12-01; your staff will not be asked to promise anything on its behalf. Acceptances recorded under v1.2 or earlier were personal clicks and are not carried forward as the tenant's acceptance.

Your options under §14. Accept v1.3 on your tenant's behalf — you may do so as soon as this version is published, during the notice period, and it takes effect on 2026-12-01 either way — or tell the operator before that date and your full data export will be prepared and offered, with termination under §8. Nothing is withheld from you, and nothing becomes read-only, before 2026-12-01.

Accepting early changes nothing before the effective date. It is offered so that a farm can settle the question in its own time rather than meet a read-only banner on the morning of 2026-12-01.

14.5 Correction to the v1.3 notice, inside its own notice period — 2026-09-19

⚠ What was corrected. This notice recorded its own date as 2026-09-17 in two places — the header and the §14.1 table. That is the day the text was settled. It was not published until 2026-09-19, so the earlier date asserted a notice that had not yet been given. The date now reads 2026-09-19 in both places. The published page also carried a contingency — that the effective date "must move" if publication were later than 2026-10-31 — which is now spent, because publication was six weeks earlier than that; it has been removed rather than left telling a reader the date on the face of a notice might be provisional.

⛔ This does not restart the notice period and does not make a new version, on the same footing as §14.3's amendment to v1.2 before it took effect. The correction shortens nothing and takes nothing away: it moves the recorded notice date two days LATER, which if anything lengthens what is owed, and the effective date of 2026-12-01 is unchanged. A correction that reduced the notice, moved the effective date, or altered an obligation would not qualify and would be given its own notice.

★ How the publication date was established, so it can be checked rather than believed. The page reaches the public web only when main moves: deploy-marketing.yml publishes apps/marketing/public/** on push to main. The v1.3 page is absent from 340ff43^1 — the state of main immediately before the merge — so the merge of pull request #969 as 340ff43 at 17:30:51 UTC on 19 September 2026 is the publication event, and not some earlier deploy. The marketing deploy (deploy-marketing.yml, run 35458324225) completed at 17:30:55 UTC and succeeded. All three versions then served 200.

⚠ The notice of record changed under its own URL, which is why both states are recorded rather than only the corrected one. As first published on 2026-09-19, the v1.3 page as served had SHA-256 74501c557245c827a47b1975442abd712952d6f2d46eb4e8d604c0761cf4052f (v1.1 753ee6f5…4d3c6cb5, v1.2 d70348d1…c91014ce). ⚠ These are the hashes of the bytes as served, which are not identical to the files in the repository — the host does not serve them verbatim — so they attest what a reader received, not that the page matches its source. The page-matches-source control is check:legal-pages, which is a separate and independent check.

⚠ Corroboration for the v1.2 notice, noted while establishing this one. §14.1 records the v1.2 notice as given 2026-09-13; there are marketing deploys on that date, so that entry is evidenced by the same mechanism rather than by assertion.

15. Governing law & dispute resolution

These terms are governed by the laws of Ghana. Any dispute arising under these terms will first be addressed by good-faith negotiation between you and the operator. If unresolved within 60 days, the dispute will be referred to mediation in Accra under the Ghana ADR Act 2010. Litigation is a last resort and lies with the courts of the Greater Accra Region.

16. Contact

Acceptance

On the tenant's behalf. The person who accepts these terms for the tenant — its creator, or a holder of the tenant.terms.accept permission — confirms that:

• they are at least 18 years old;
• they have authority to bind the farm or organization to these terms;
• they have read this document end-to-end (or have had it explained to them in a language they understand);
• they accept these terms on the tenant's behalf, as written.

By every user. Everyone who signs in confirms, for themselves only, that:

• they are at least 18 years old;
• they have read this document and the Privacy Policy (or have had them explained in a language they understand).

A user's acknowledgement does not bind the tenant and does not claim authority to.

Each acceptance and acknowledgement is recorded with the user id, the version, whether it was made on the tenant's behalf or personally (and, if on the tenant's behalf, under which authority), the timestamp, the IP address, and the user agent. The recorded acceptance is exportable on request.

End of Tenant Terms of Service v1.3.