Security

Version 2026-09-21. Stationyx is a product of Wiens Corporation.

This page answers the five questions an IT reviewer asks, in the order they ask them. Every statement describes what the software does today. Where we cannot prove something, this page says so instead of claiming it.

Where your data lives

Stationyx runs on Supabase, which holds the application database, the sign-in accounts and the uploaded files. Production runs in Supabase's us-east-2 region, which is Ohio, in the United States. Supabase runs that region on its own cloud provider and publishes its infrastructure sub-processors itself; ours are listed below.

The API, the background worker, the application itself and this website run on a Wiens Corporation virtual server. Nightly database and file backups are written to that same server.

Your organization's records carry your organization and line ids, and the browser reads them under database row-level security tied to the account that signed in. A person who is not on a line does not receive that line's rows, and the check runs in the database rather than only in the application.

Who can see it

Wiens operates the service, so Wiens staff can technically read tenant data. This is the sentence we will stand behind, and it is deliberately narrower than the one you may be used to reading:

Wiens staff access your data only to operate the service, fix a fault, or when you ask us to. Access through our administrative tools is recorded with the person, the time, the organization and the reason, and we keep that record. Our engineers can also reach the database directly to operate and repair it, which our hosting provider logs but our application does not.

The recorded half is enforced, not promised. Every administrative route sits behind one gate, and that gate writes the record before the handler runs. If the record cannot be written the request fails, so there is no served administrative read without one. The record holds who, when, which capability, which organization or line, and the reason the operator gave.

We do not claim that every access is logged, because it would not be true. The nightly backup alone is a complete copy of every customer, and whoever can read that file reads the data without touching the application. The same goes for our hosting provider's database console, for the credential our own operator scripts use, and for our sub-processors' consoles. The record proves that a Wiens person used an administrative feature. It does not prove that no Wiens person read the database.

Closing that gap means database-level audit logging, a separate login for each engineer, and encrypted backups. We have costed that work and have not done it. If you need it before you buy, tell us and we will tell you what it would take.

Getting your data out

An owner exports the whole organization whenever they like. It is owner-only, it runs on demand from the owner's own signed-in account, and nobody at Wiens approves, schedules or assembles it. There is no ticket and no wait.

The archive holds:

• every record belonging to your organization, one JSON file per table, with the column names the database uses;
• everything you uploaded: document library files, their revisions and work-instruction step photos, at the same paths the records name;
• the PFMEA, control plan and process flow workbooks, rendered at the moment you take the export;
• every document version you released, byte for byte the file that was approved rather than a fresh render of it.

It never holds PIN material, station machine credentials, your model provider key, the cache of prompts and model output, the usage and cost log, the record of how a suggestion was derived, or the internal undo buffer. A person's record says a PIN is set and never what it is.

The set of tables in the export is discovered from the live database on every run rather than kept as a list, so a table added later cannot quietly fall out of it. A test searches a seeded export for the actual PIN hashes, salts and machine credentials, and for every value belonging to a second organization, and fails if any of them appears.

Single sign-on

No, not today. Everyone signs in with an email address and a password held by Supabase Auth. Stationyx supports no SAML, no OIDC, and no Google or Microsoft sign-in. If single sign-on is a requirement for you, raise it before you buy rather than after.

Operators are the exception, and by design: an operator has no account at all. They identify at the station with a PIN or a badge, and the PIN is a salted slow hash in a table only the service connection can read.

What happens when a subscription lapses

Ending a tenancy is something an owner asks for. It runs in two phases.

• Access ends at once, and nothing is destroyed. The organization is marked, and from that moment it stops resolving for everybody: the API drops it out of the one place a membership enters a request, and the database's own row-level security checks carry the same predicate, so the browser cannot reach it either. Asking twice keeps the first timestamp, so re-asking cannot move the date in either direction.
• Thirty days later it is destroyed permanently. A nightly job takes the organizations whose window has closed, re-checks each one on its own, logs the per-table counts before it starts, and deletes. Every record in our database and every file in our storage goes, the activity trail with it.

Inside those thirty days a Wiens operator can put the organization back, and clearing the mark is the whole restore because nothing was removed. Restoring is deliberately not the same action as asking: the account that can end a company must not be the one that quietly reinstates it.

Export before you ask. Marking the organization ends access, which means the export stops answering too.

The honest limit on destruction:

• It reaches our Postgres database and our Supabase file storage. Those are ours to erase, and they are erased.
• It does not reach rotated off-site backups. A nightly dump taken while your organization was live still holds it until that dump ages out of rotation.
• It does not reach our sub-processors. The error reporter, the analytics service, the email service and the model provider each keep what they keep under their own retention terms, and we cannot delete on their behalf.
• Sign-in accounts are identities rather than organization data, so the purge removes your organization's memberships and not the account itself. An account that existed only for a deleted organization can be removed on request.

AI suggestions

Nothing reaches a model unless somebody in your workspace runs an AI action. When one does, what goes is station and step names and descriptions, PFMEA text, control plan text, and the line context you entered. What never goes is images and uploaded files, credentials, keys and tokens, and user accounts and email addresses.

Production calls Google's Vertex AI directly. Google does not use prompts, responses or other customer data to train or fine-tune its models without permission. Prompts are logged for abuse detection, and that logging can be excepted on request so nothing is retained.

Our calls go to Vertex AI's global endpoint, which carries no data residency guarantee: a request may be served from any region Google operates in. Pinning a region is possible on Vertex, but the model we run is served only on the global endpoint, and we chose the model with that trade-off in front of us. If residency is a requirement for you, it is a model choice we can discuss.

Inside the product, the suggestions someone applies are stored in your workspace along with token counts for cost. A cache of recent prompts and model output also sits inside your organization's own data, and it is destroyed when your organization is.

An admin switches AI off for the whole organization in Settings. Every AI endpoint then refuses the request before it reaches a model, and the AI controls disappear from the app. Applying and undoing an earlier suggestion stay available, because neither calls a model and undoing has to keep working after the switch is off.

Sub-processors

Every third party that your data, your metadata or your browser reaches. This table is not typed by hand. It is generated from what the software actually calls, and our build fails both ways: a vendor added without a disclosure breaks it, and a disclosure kept after the code stopped calling that vendor breaks it too.

Anthropic and OpenAI appear on that list because the software can be configured to use them, not because production does. Production routes to Google.

What we have not built

Naming these is cheaper than being asked about them later.

• Single sign-on, as above.
• A view that shows you which Wiens person opened your organization. The record exists; there is no customer-facing page for it yet, and building one is a decision about disclosure rather than a side effect of logging.
• Database-level audit logging of direct engineering access, per-engineer database logins, and encryption of the nightly dumps at rest.
• A published uptime commitment. We do not have one, so we do not offer one.