1. First principle: who is being protected?
The Customer’s data, continuity, and agency must outlive any single business relationship.
Control-C is not only licensing software. It is delegating custodianship. This agreement encodes that duty so it survives leadership changes, market shocks, and good intentions gone stale.
2. Partnership model definition (anchor the shape)
2.1 White-Label Stewardship Partnership (WLSP)
A White-Label Stewardship Partnership (WLSP) is a relationship where:
- The Partner operates a self-hosted instance of Control-C.
- The Partner controls the commercial relationship with end customers.
- Control-C retains custodial oversight obligations to protect customer survivability.
- Customers may integrate third-party platforms (for example Xero) under delegated authority.
This definition prevents later reframing as “just a reseller” or “just infrastructure.”
3. Stewardship covenant (ethical core)
3.1 Stewardship duty
The Partner explicitly acknowledges that:
- It acts as a Data Steward, not an owner, of Customer Data.
- Its role includes a duty of care, continuity, and reversibility.
- Commercial optimization must never materially compromise:
- Data integrity
- Recoverability
- Customer exit rights
3.2 Customer primacy clause
In any conflict between:
- Partner commercial interests
- Platform sustainability
- Customer data survivability
Customer survivability prevails.
4. Technical and operational controls (where ideals become real)
4.1 Hosting and architecture requirements
Partners must:
- Run Control-C on documented, reproducible infrastructure.
- Maintain daily automated backups of:
- Control-C datastores
- Configuration
- Encryption material (where applicable)
- Support export in open, documented formats (Postgres dump plus schema at minimum).
Control-C reserves the right to audit architecture diagrams, not just code.
4.2 Feature gating and product integrity
- Control-C defines a capability matrix (enabled and disabled features).
- The Partner must not:
- Remove customer exit tooling
- Obfuscate recovery workflows
- Misrepresent feature parity with Control-C core offerings
- Any customizations must be:
- Declaratively documented
- Reversible without customer data loss
5. Customer survivability guarantees (the heart of it)
5.1 Right to continuity
Every end customer must retain the ability to:
- Retrieve a complete, usable copy of their data.
- Reconnect to:
- Another Control-C partner
- Control-C direct
- A self-managed environment
No hostage economics.
5.2 Escrow and transition safeguards
Partners must agree to one or more of:
- Code escrow (for partner-specific extensions)
- Encrypted credential escrow (for customer-owned secrets)
- A Control-C held “break glass” recovery pathway
Triggered automatically upon:
- Insolvency
- License termination
- Material breach
- Prolonged service outage
No discretionary delays.
6. Business change and end-of-life provisions
6.1 Change of control
If the Partner undergoes an acquisition, merger, majority ownership change, or a strategic pivot away from data services, it must:
- Notify Control-C in advance.
- Provide customers with clear continuity options, timelines, and migration paths.
Silence is a breach.
6.2 Partner exit or failure
Upon termination (voluntary or involuntary):
- The Partner maintains service for a defined transition window (for example 90 days).
- Control-C may step in to assist migration and assume temporary custodial control solely to protect customers.
- No ransom pricing. No “professional services” lock.
7. Code of ethics (short, sharp, enforceable)
Partners agree to:
- Never knowingly place customers at risk for short-term gain.
- Communicate failures early and plainly.
- Preserve reversibility in all technical decisions.
- Avoid dark patterns, forced bundling, or exit friction.
- Treat Customer Data as loaned trust, not an asset.
Breach of this code of ethics is a breach of this agreement.
8. Oversight, audit, and right to care
Control-C retains the right to:
- Conduct periodic stewardship reviews.
- Request evidence of:
- Backup integrity
- Restore drills
- Incident response readiness
- Intervene only to protect customers, not to compete.
9. Statement of intent
This partnership exists to ensure that businesses relying on digital systems are never abandoned by them. Commercial success is welcome. Customer abandonment is not.
10. What this framework quietly does
Without saying it out loud, this framework:
- Filters out bad-faith partners early.
- Forces operational maturity.
- Makes Control-C the ethical gravity well.
- Positions Control-C as infrastructure for continuity, not convenience.
11. Platform lineage, update stewardship, and central continuity
11.1 Central continuity replication (non-negotiable)
All Partner-hosted instances must support secure, automated replication to a Control-C managed Central Continuity Datastore.
Key properties:
- Read-only for Control-C under normal operation.
- Encrypted in transit and at rest.
- Scoped to:
- Customer data
- Metadata
- Recovery indexes
- Integrity proofs (hashes, manifests)
This datastore exists solely to:
- Validate recoverability.
- Enable customer survival scenarios.
- Provide independent verification of backups.
Not analytics. Not monetization. Not surveillance.
11.2 Replication as a condition of licence
The Partner acknowledges that:
- Central replication is a condition of the white-label license.
- Disabling or materially degrading replication:
- Requires written approval.
- Must be time-boxed.
- Must include customer notification if prolonged.
Silent failure is a material breach.
12. Software currency and operational integrity
12.1 Supported version covenant
Partners must operate only on currently supported Control-C releases within the defined version skew (N-2 maximum).
Control-C defines:
- End-of-support timelines.
- Security patch SLAs.
- Mandatory upgrade windows for critical fixes.
Running obsolete software is treated as a customer continuity risk, not a technical preference.
12.2 Update responsibility model (clear lines)
| Responsibility | Control-C | Partner |
|---|---|---|
| Core software releases | ✅ | ❌ |
| Security patches | ✅ | ❌ |
| Deployment and rollout | ❌ | ✅ |
| Environment compatibility | Shared | Shared |
| Regression reporting | ❌ | ✅ |
12.3 Operability and health signalling
Partners must expose basic health telemetry, including:
- Uptime
- Job success rates
- Backup freshness
- Version reporting
- Replication status
Signals may be API-based, push or pull, and lightweight, but they must exist.
13. Right to assist (duty-of-care clause)
13.1 Assisted remediation right
If a Partner instance is failing to replicate, critically out of date, functionally non-operable, or placing customer continuity at risk, Control-C may:
- Notify the Partner.
- Offer direct assistance.
- Require a remediation plan with deadlines.
If unresolved, Control-C may invoke protective intervention limited strictly to restoring operability or enabling customer transition.
This is not a takeover clause. It is a duty-of-care clause.
14. Platform continuity on partner exit
Upon Partner termination or failure:
- The Central Continuity Datastore becomes the authoritative recovery reference.
- Control-C may:
- Validate last-known-good state.
- Assist customer re-homing.
- Reconstitute environments if contractually required.
Customers do not start from zero.
15. Why this completes the stewardship loop
These clauses protect three layers simultaneously:
- Customer survivability
- Platform integrity over time
- Ecosystem trust (partners, regulators, upstreams like Xero)
Continuity is not just about data. It is about the continuity of care.