Best Webby Platform Governance Policy

Version 1.0 · Effective 1 August 2026 · Joorus Inc., Toronto, Canada

1. Why this document exists

Best Webby is software that other businesses run their livelihoods on. Those businesses have customers of their own, and those customers have rights. A failure here does not stop with us — it reaches people who have never heard of us and never agreed to anything with us.

This document states how we govern the platform: what we will do, what we require of merchants, and how each is enforced. It is published so that it is a commitment rather than an intention, and so that a merchant, a regulator or a payment partner can hold us to a written standard.

Scope. It applies to the Best Webby platform, everyone who operates it (employees, contractors and automated systems acting on our behalf), and every business that uses it.

Where this policy and a specific agreement conflict, the specific agreement governs the commercial terms; this policy governs conduct.

2. Principles

These are the tests we apply when a decision is not obvious.

1. The merchant's business is theirs. We provide software. We do not own their customers, their data or their relationships, and we do not compete with them using what we learn from operating their store.

2. We do not hold what we do not need to hold. Customer payments settle directly to the merchant's own gateway. We are not in the money path, we do not take title to goods, and we are not the merchant of record for any sale.

3. Least authority, always. Every person and every system gets the narrowest access that lets them do the job, for the shortest time. This applies to automation exactly as it applies to people — more so, because automation is faster than anyone's ability to notice it going wrong.

4. Say what is true, including when it is unflattering. Status pages report what was actually measured. Incident notices describe what actually happened. A control we have not built is not described as though we had.

5. Enforcement with due process. When we act against an account we say why, and there is a route to answer. Suspension is not silence.

6. Legality is not optional and not delegable. We follow the law where we operate. Merchants follow the law where they operate and where their customers are. Neither of us can contract out of it.

3. Data governance

Ownership. Merchant content and merchant customer data belong to the merchant. Where we process personal data on their behalf we act as processor, on their documented instructions, under the data processing terms.

Isolation. Every merchant's data is isolated at the database level, enforced by the database itself rather than by application code remembering to filter. Object storage is per-merchant, not shared.

Minimisation. We collect what the platform needs to function and what the law requires us to keep. We do not sell merchant or shopper data, and we do not share it with third parties for their own marketing.

Cross-merchant intelligence — aggregate benchmarks and insights — is opt-in, never on by default, and is only ever aggregated. It is never used to expose one merchant's specifics to another.

Access to merchant data by us. Our staff do not browse merchant data. Access happens for a stated operational reason — a support request, an investigation, a legal obligation — and privileged actions are logged.

Retention and deletion. A merchant can export their data at any time. On account closure, data is deleted on a published schedule, including object storage. Shoppers can request export and erasure through the merchant, and the platform provides the mechanisms to honour it.

Location and transfers. We disclose where data is stored and which subprocessors we use, and we maintain a published subprocessor register.

4. Automation and AI governance

The platform uses automated systems, including AI models, to operate services, screen content, and assist merchants. This section governs them.

4.1 Automation is bound by the same authority limits as people. An automated system acting on our behalf gets scoped, least-privilege credentials for the task it performs. Broad standing access for convenience is not acceptable, however useful it is.

4.2 Destructive and irreversible actions require a human decision. Deleting merchant data, moving money, suspending an account, and changing production infrastructure are authorised by an accountable person. Automation may prepare such an action and may execute it once authorised; it does not decide to take it.

4.3 Privileged automated activity is logged and reviewable. What ran, under whose authority, against what, and when.

4.4 Untrusted input is never an instruction. Merchant content, shopper content, uploaded files and third-party API responses are data. An automated system that reads them does not take direction from them. This is a specific, known attack against AI-driven systems and it is treated as a security boundary, not a curiosity.

4.5 AI output is not authority. Model output that reaches a shopper, alters a listing, or affects an account is checked before it takes effect. A model's confidence is not evidence.

4.6 Merchants are told when they are dealing with automation, and any automated decision that materially affects an account can be appealed to a person (see §7).

4.7 We do not train models on merchant data for our own or a vendor's benefit without explicit, revocable, per-merchant consent.

5. Access to production

Separation of duties. The identity that deploys is not the identity that administers. Neither is a shared login.

Authentication. Multi-factor authentication is required for administrative access. Sensitive operations — refunds, credential issuance, account deletion — require a fresh second factor at the moment of the action, not merely a session that was authenticated earlier.

Change control. Changes to production are recorded, attributable, and reversible. Emergency changes are permitted and are reviewed afterwards, not excused.

Credentials. Secrets are held in a managed store, rotated on a schedule and immediately on suspicion, and are never committed to source control. Automated scanning enforces this.

Monitoring. Availability, background processing, backup freshness and certificate expiry are monitored continuously and alert a person. We publish live component status.

6. What we require of merchants

Merchants accept the Merchant Terms of Service and the Acceptable Use Policy before they can use the platform, and confirm compliance for each product they publish. Acceptance is recorded against the exact version of the document shown at the time.

In summary, a merchant must:

• **Comply with the law of every country they do business in and every country

their customers are in** — consumer protection, distance selling, product safety and labelling, age restrictions, import and export controls, sanctions, tax, privacy and marketing law.

• Hold any licence, registration or authorisation a market requires for the

products they sell there, before listing them.

• Not sell prohibited goods — unlawful items, counterfeits, stolen goods,

controlled substances, unlicensed weapons, unauthorised regulated financial products, protected wildlife, recalled products, and material involving minors or produced without consent. The full list is in the Acceptable Use Policy.

• List accurately — description, images, origin, materials, condition and

price, using imagery they have the right to use.

• Honour their customers' rights — returns, refunds, cancellation, contact

details that reach a person, and consent-based marketing with working unsubscribes.

• Not misuse the platform — no impersonation, phishing, payment-credential

testing, money laundering, or attacks on our systems or anyone else's.

Legality varies by market. A product lawfully sold at home may be prohibited where the customer is. Knowing the difference is the merchant's responsibility; helping them see it is ours.

7. Product and content governance

Screening. Listings are screened automatically against restricted-category rules, known-violating imagery, and classification of the listing's images and text. Screening is applied with regard to the markets a merchant sells into.

Hold before harm. A listing that a screen flags is not visible to shoppers until it has been reviewed by a person. If screening cannot complete — an outage, a timeout, an error — the listing stays held. A failure of our systems does not become an open door.

Proportionality. Established merchants with a clean record are not held back by a review queue for every routine listing; their listings are screened and monitored after publication, with sampling. Trust is earned by conduct and is withdrawn by conduct. It is never sold and never granted by hand as a favour.

Reporting. Anyone — a shopper, a rights holder, a competitor, a regulator — can report a listing or a store. Reports are investigated.

Due process. When we hold, remove, or refuse a listing, we tell the merchant what was wrong and let them correct and resubmit. When we suspend an account we state the reason and provide a route to answer; the merchant keeps access to their dashboard and their data in order to make that answer, unless the law or an active investigation requires otherwise.

Proportionate escalation. Repeat or serious breaches escalate: from a single listing removed, to pre-publication review for the account, to suspension. We record who decided, when, and why.

8. Incidents

Detection and response. We monitor for failure and for abuse, and we have a defined path for responding to both.

Notification. If merchant or shopper data is compromised, we notify affected merchants without undue delay and give them what they need to meet their own notification duties — which they, not we, owe to their customers. We do not delay disclosure to protect our reputation.

Honesty in post-mortems. We describe what happened, what caused it, and what changed as a result. We do not describe an outage as maintenance.

9. Transparency

We publish: live component status; this policy; the merchant terms and acceptable use policy with their version history; our subprocessor register; and a route to report abuse that does not require an account.

This policy states the standard we hold ourselves to. Because stating a standard and having met it are different things, we publish a Control Status register alongside it: every commitment in this document, marked as in place, partially in place, or committed with a target date.

We would rather publish an honest gap than an implied capability. A reader should never have to guess which of the commitments above is already true — the register answers that, and it is updated as controls land.

10. Governance of this policy

Ownership. This policy is owned by Joorus Inc. and reviewed at least annually, and after any material incident.

Change. Revisions are versioned and dated. Material changes affecting merchant obligations are notified in advance and require acceptance before continued use.

Precedence. Nothing in this policy limits a right a merchant or a shopper has by law.

Contact. Governance, compliance and abuse: [email protected].

Joorus Inc. operates Best Webby — Next-Gen Solutions. This document states operating commitments and merchant obligations. It is not legal advice, and the specific contractual wording of the Merchant Terms of Service governs the commercial relationship.