Privacy Policy

• 1Who we are
• 2What this policy covers
• 3What we collect
• 4Why we collect it
• 5What we do not do
• 6Where it is stored
• 7How long we keep it
• 8Who else sees it
• 9Overseas disclosure
• 10How we protect it
• 11Access and correction
• 12Data breaches — we will tell you
• 13Complaints
• 14Cookies and browser storage
• 15Changes to this policy

1Who we are

Invixo is operated by Kye Alexandre Brant (ABN 55 445 847 562) from Western Australia. In this policy, “we” and “us” mean Invixo.

Privacy enquiries go to support@invixo.com.au.

2What this policy covers

This policy covers personal information we handle when you use Invixo — as an account holder, as a client invited to view a project, or as a person whose details appear inside a customer's project data.

We handle personal information in line with the Australian Privacy Principles in the Privacy Act 1988 (Cth) and with the Notifiable Data Breaches scheme in Part IIIC of that Act. This policy is a commitment we intend to keep.

A distinction that matters here. Most of what customers upload is survey and design data, not personal information — a point cloud is not a person. But some of it is: names and signatures on permits, faces and locations in site photographs, the email address of a client you invite. Where a customer uploads personal information, that customer decides what is collected and why; we hold and process it on their behalf. Where we collect it directly — your account details, your activity log — we are the ones responsible.

3What we collect

This is the actual inventory, taken from the system itself rather than written from a template.

3.1 Your account

Your name, profile photo and job title are shown to other people who can open the projects you work on — for example beside your name on markups and in activity lists.

3.2 The activity log

Every state-changing request — anything that creates, updates or deletes something — writes one row to an append-only audit log, along with sign-ins and sign-outs. Each row records:

• who — the actor's email address and role (or a marker such as (share guest) where there is no account);
• what — the action (login, logout, create, update, delete), the HTTP method, the request path, and the resulting status code;
• where — the project it belongs to, and the IP address the request came from;
• when — the timestamp.

Health checks, event streams and the “who am I” call are deliberately left out, because logging them would bury the trail in noise. The log is visible to administrators of your organisation on the Activity page. It exists so a change to a project can be traced to an account — which is as much your protection as ours.

3.3 Project data you upload

Survey and design files, models, point clouds, drawings, documents, alignments and everything the platform derives from them. We also extract and store the text of document pages so that documents can be searched.

Most of this is not personal information. Some of it may be — a drawing title block with a person's name, a document containing contact details. We do not inspect it, index it for any purpose beyond your own search, or use it for anything except running the platform for you.

3.4 Site photographs

When a photograph is uploaded to a project we store the image, its filename, any caption, and a generated thumbnail. We also read two things out of the file's EXIF metadata, because the product uses them to place the photo on the map and on the timeline:

• GPS latitude and longitude, converted to decimal degrees — this is what puts a pin on the map;
• the original capture date and time.

Both are best-effort: a photo without GPS still uploads, just without a pin. A location can also be set by hand, and we record which of the two it came from. Be aware that a phone photograph usually carries the exact location where it was taken. If that matters for a particular site, strip the metadata before uploading, or set the location manually.

3.5 Client invitations

When you invite a client to view a project read-only, we store the email address you invited, a label you choose for them, who created the invitation, any expiry, a hash of the single-use set-up link, the scrypt hash of the password the client sets for themselves, the time of their last sign-in, and an identifier for their one live session. The raw invitation token is never stored — only its SHA-256 hash — so a database read cannot hand out a working link.

You choose who to invite. We do not add those addresses to any list, and we do not contact them for any purpose other than delivering the invitation you asked us to send.

3.6 Permits

The permit system records the people involved in hazardous work: typed names, drawn signature images, roles, dates and comments, together with a snapshot of the exact declaration wording each person signed. Some signers have no account at all, in which case the typed name and the drawn signature are the whole attribution. This is a safety and compliance record, which is why section 7 treats it differently from everything else.

3.7 Support correspondence

If you write to us for support, we keep the message and our reply, including anything you choose to attach.

4Why we collect it

• To run the platform — to sign you in, show you your projects, process imports and compute the outputs you asked for.
• To keep it secure and accountable — the activity log lets a change be traced to an account, and lets an intrusion be investigated.
• To support you — to diagnose a problem you have reported.
• To meet legal obligations — where a law requires us to keep or produce something.

We do not use your personal information for any other purpose without asking you first.

5What we do not do

6Where it is stored

Invixo runs on servers operated by Binary Lane in Australia. Within them:

• account details, the activity log, permits and project metadata are held in a PostgreSQL database;
• uploaded files, derived products, photographs and thumbnails are held in an S3-compatible object store;
• a queue holds jobs in flight while imports and computations run.

Backups. Every night the database and the uploaded files are copied off the server to storage operated by Cloudflare (R2). The server keeps the 14 most recent nightly copies of the database; the backup job does not itself delete the database copies it has already sent off-site. The uploaded files are mirrored, so a file deleted from the platform leaves the off-site mirror at the next nightly run. A bundle of the server's configuration is encrypted before it leaves the server. Backups exist so that we can restore the service after a failure.

Because of this, information you delete from the platform may persist in a backup of the database after it is gone from the live system.

7How long we keep it

Where we no longer need personal information and no law requires us to keep it, we delete it or de-identify it.

8Who else sees it

Inside your organisation, who can see what is decided by the roles and project permissions your administrators set. A client invited to view a project sees that one project, read-only, and nothing else.

Outside, we use a small number of sub-processors. These are the only third parties that receive anything:

We also disclose personal information where we are required or authorised by law to do so, and where it is necessary to protect someone's safety or to enforce our rights. If we are ever compelled to hand over your data, we will tell you where the law lets us.

If we are ever bought or merged, your information may transfer with the business — and it would remain subject to a policy at least as protective as this one.

9Overseas disclosure

Some of the sub-processors above operate outside Australia. The platform itself is hosted in Australia (Binary Lane). Outside Australia:

• United States — Cloudflare (DNS, and the off-site backups of the database and uploaded files), Mapbox (map tiles, terrain and fonts), and, only if you switch those overlays on, NASA GIBS;
• European Union — Brevo (outgoing email);
• Switzerland — epsg.io (MapTiler), for the coordinate-system definition when you start the RL at click tool on an EPSG-coded project;
• Wherever is nearest to you — the code distribution networks (jsDelivr, unpkg), and RainViewer's radar imagery if you switch it on.

Using the platform means basemap and library requests will leave Australia in the ordinary course.

10How we protect it

• Passwords are never stored in readable form — only as salted scrypt hashes, for both staff accounts and client viewer accounts.
• Invitation tokens are stored hashed, never in clear. A leaked database copy cannot be used to redeem an invitation.
• Sessions use a signed, HttpOnly cookie that scripts on the page cannot read, valid for up to 14 days. Client viewer accounts are limited to a single live session — a newer sign-in invalidates the older one.
• Access is enforced on the server, not merely hidden in the interface, and is scoped per project. A client viewer is confined to the one project they were invited to.
• The activity log is append-only, and the network address it records is taken from a header our own proxy controls rather than one a client can forge.
• Backups are taken nightly and copied off the server.

No system is perfectly secure, and we do not claim otherwise. If something does go wrong, section 12 says what happens.

11Access and correction

You can ask us what personal information we hold about you, ask for a copy of it, and ask us to correct it if it is wrong. Write to support@invixo.com.au.

We will respond within 30 days. We do not charge for making a request. If we refuse — which we would only do where the law allows, for example where releasing it would reveal someone else's personal information — we will tell you why in writing, and how to complain about it.

Much of it you can see and change yourself: your name, profile photo, job title and preferences in your account settings, and your organisation's activity log on the Activity page.

If the information you are asking about sits inside a customer's project data rather than in your own account, we will point you to the customer who controls it, because it is theirs to correct.

12Data breaches — we will tell you

13Complaints

If you think we have mishandled your personal information, tell us first at support@invixo.com.au. We will acknowledge within 7 days and respond substantively within 30 days.

If you are not satisfied with our response, you can complain to the Office of the Australian Information Commissioner — oaic.gov.au, 1300 363 992. You do not need our permission to do that, and complaining to us first does not cost you the right to.

14Cookies and browser storage

We use no advertising or tracking cookies. What the platform sets is:

• a signed session cookie (HttpOnly) that keeps you signed in, and an equivalent for client viewer sessions;
• a small readable marker telling the interface that a client viewer session is in progress;
• browser local storage holding your theme choice, which organisation you are working in, a copy of your saved map views, and a hint that you are signed in. Apart from the saved map views, which are also kept with your account (section 3.1), these stay in your browser; they are not sent to us as a record of you.

Clearing your browser storage signs you out and resets those preferences. It costs you nothing else.

15Changes to this policy

We will update this policy when what we do changes. The version string and date at the top change with it, so an acceptance record can point at a specific version. This is version 2026-09-27, dated 27 September 2026. We will tell account holders about material changes before they take effect.