Who owns the records — and what you can take with you.

This page makes the ownership and export rules on Makerstead explicit. It sits alongside the terms of service (subscription mechanics, signature, payment) and the privacy policy (data handling backbone). Where those documents overlap, this page owns the “who owns the records, what you can export, what happens on cancel” questions. If you’re reading the platform for the first time, start here — if you’re leaving it, this is the page that walks you out.

The data on Makerstead is owned along the same lines the bench and the owner of a piece already experience it in the workshop. Three buckets, three owners:

• The subscribing business. When a maker or trade business opens a subscription, that business owns the records it creates: the product page bound to a QR, the photograph library attached to those records, the service-log entries on each one, the customer roster it assembled for follow-up, and any ownership-transfer packets it sends. In platform terms, that’s the business’s bench — the substantive content the QR resolves to for any owner who scans it. The business may export these rows on demand and may direct that they be transferred to a different maker through the desk.
• The end-customer. Where a record (or a transfer packet, or a service-log entry) carries a name, contact information, shipping or pickup address, or other personal field that an owner submitted themselves, those fields belong to that individual. They may correct them through the desk, ask for the record to be deleted, or request a copy — the way those requests work is documented on our privacy policy.
• Makerstead (us, the platform).We hold platform bookkeeping: the login event log, billing state tied to the subscription, abuse-signal records filed against takedowns, and other back-office records that aren’t the records you came to make. This bookkeeping is never resold, never enriched against third-party data, and never used to train a model on — the no-train promise runs in both directions and is on the terms page.

The export surface is a contractual right — you can take the row data with you on any reasonable cadence for the life of your subscription, and the right survives cancellation for as long as the data we hold on the platform does. From the dashboard, the active maker’s export endpoint at /api/export/products returns one wide CSV: Product, Customer, Request, Service history, and Ownership-transfer rows, joined on the keys a downstream tool can pivot on.

If you are reading this page outside an active subscription — during a publish-grace window, after a lapse, or as someone evaluating the platform before signing up — this is what the export gets you when it’s turned back on:

• A wide CSV per record, joined to the customer roster and the service history — fields the source-of-truth pages already document.
• One additional archive row, in the same shape, captures the photograph library as a single file reference and the ownership-transfer queue as an additional joined table.
• The export is available at any time during the 90-day publish-grace window after a lapse (see below) and on request after that. Hit the dashboard and the export lives behind a button. If the dashboard is unavailable because the subscription has been closed for longer than the retention window, email us and we’ll see what survives.
• End-customers may ask for a copy of the personal fields they submitted through the desk — route that request through makerstead@polsia.app.

Subscription cancellation is not the same as data deletion, and the two have different mechanics. Two paths and what each one does to your records:

• Soft-cancel.The subscription lapses or the maker asks for the account to end, but no separate “delete the records” instruction is given. We treat the next ninety (90) days as a publish-grace window. Public care pages still resolve via QR for that window; the service log on a record goes read-only (no new entries publish, no new ownership transfers can be initiated by this maker); the export described above stays available on the dashboard; ownership-transfer requests that were already sitting in the queue are returned to their senders rather than sitting on a dead account.
• Hard-cancel. The maker, an end-customer invoking the privacy-policy deletion ask, or a lawful-authority request triggers an active deletion. We generate a final archive of the same shape as the export, deliver it to the business or the requester by email, then permanently delete the row. The archive itself sits on a separate shelf for thirty (30) days after delivery so a re-request or a dispute has the artefact to cite; the shelf is then deleted.

Retention after the 90-day grace runs differently per row type, in three buckets:

• Business-aggregated rows. Product, photograph library, service log, ownership-transfer packet — the substance of the bench — are deleted when the publish-grace window closes (or earlier on a hard-cancel).
• Customer rows.Personal fields the end-customer submitted (name, contact, addresses, service notes tied to a name) follow the customer’s deletion choice — a redacted summary is retained long enough to honour the QR resolution during the grace period; the identifying fields are deleted on request or at the end of that period.
• Platform bookkeeping.Billing state, login events, abuse signals — retained as long as the law requires for accounting, fraud, and dispute resolution; never resold.

The full per-row timing and the legal bases for retention sit on the privacy policy — this page is the contractual split, the privacy page is the legal basis behind each retention.

A care record is published by being reachable through its QR. When the maker’s subscription ends — through lapse, through a hard cancel, or through an enforcement takedown — that’s the thing an owner scanning the code is going to feel first. The mechanics:

• During the 90-day publish-grace. The QR still resolves. The public care page renders a clear notice at the top — “this maker’s subscription has ended; care history is preserved for [N] days” — so the owner scanning can see the status, not just the content. The notice is not branded as a takedown; it is neutral and points the owner at this policy page for the why-it-stopped context.
• After the grace window on a soft-cancel, or after the 30-day shelf on a hard-cancel. Public QR resolution ends for the records of that business. The QR code stops rendering a care page and lands on a “maker no longer publishing” landing instead. The landing explains the closure, points the owner at the exporting business’s contact if that contact is on file, and offers a one-click export-by-email of the owner’s own submitted fields.
• Enforcement takedowns. Where a subscription is terminated for cause under the acceptable-use policy, public resolution ends immediately rather than running out the publish-grace window — the surrounding row deletion and the export window still run as documented above.
• Ownership transfer before churn. Where the originating maker transfers a record to a new maker before churning — complete with the receiving maker’s acceptance through the desk — the new maker inherits ownership and the QR keeps resolving through the new tenancy. The previous maker’s churn doesn’t reach into rows that have already moved.

Email makerstead@polsia.app for ownership questions, export asks beyond the dashboard, deletion requests from a business or from an end-customer, and any data-dispute you’d like revisited. Include the record URLs in question, how you came across them, and what you’d like done. We acknowledge within two business days.

Material changes to this policy get a sign-up-screen notice and at least fourteen (14) days’ notice before they take effect. Non-material changes — typo fixes, wording clarifications, contact-email updates, link updates, retention-window nudges that go uprather than down — are applied silently and reflected in the “Last updated” date at the bottom of the page.

Continued use of Makerstead after a material change takes effect is your acceptance of the updated policy. If a change is one you can’t accept, cancel from the billing surface and export your records before the effective date.