Privacy Notice

1Who we are

Integrated Core Systems ("ICS", "we"), incorporated in British Columbia, Canada, is the controller of the personal information described here. Reach us at support@systemsicore.com.

We are subject to Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) and British Columbia's Personal Information Protection Act (PIPA). Where we serve people in the European Economic Area or the United Kingdom, we also apply the GDPR and UK GDPR, and §13 states our legal basis for each purpose.

2What this notice covers

This site (systemsicore.com), the customer portal (portal.systemsicore.com), the documentation site (docs.systemsicore.com), the licensing API, the ICore Blocks desktop application and the ICore SDKs.

3The website

No cookies. No analytics. No advertising or tracking pixels. This marketing site does not set a cookie, does not load an analytics script, and does not profile visitors.

Two things do happen, and you should know about both:

• Your light/dark preference is stored in your browser's localStorage under the key icore-theme. It stays in your browser, is never transmitted, and is not a cookie. Clearing site data removes it.
• Fonts are loaded from Google Fonts. The site renders in IBM Plex, served from fonts.googleapis.com and fonts.gstatic.com. That means Google receives your IP address and user agent when the page loads, and its own privacy policy applies to that request. No cookie is set by these requests, and we receive nothing from Google.

Our hosting provider, Cloudflare, processes standard request data - IP address, timestamp, requested URL, user agent - to serve the page and to defend against attack.

The customer portal necessarily stores a session token in your browser so you stay signed in. It is functional and cannot be turned off while you are signed in.

4The release-notification list

If you ask to hear about new releases, we store the email address you give us and, if you choose to fill them in, a name and a company. Nothing else, and only if you ask.

You are on the list as soon as you subscribe. We do not currently send a confirmation email first, so we cannot be certain that the person who ticked the box owns the address. If a message from the list reaches you and you did not ask for it, its one-click unsubscribe removes you at once and for good, and you can also write to support@systemsicore.com.

Alongside the address we keep a record of the consent itself, because Canada’s Anti-Spam Legislation requires us to be able to prove it:

• WhenThe time you submitted the form.
• What you agreed toThe exact sentence that appeared beside the checkbox, stored word for word. If we later change the wording, your record keeps the wording you actually saw.
• WhereThe page the form was on.
• From whereYour IP address as a salted one-way hash, and your browser’s user agent. The hash lets us show two actions came from the same place; it cannot be turned back into your IP address, and we never store the address itself.

What we send. A short, plain-text message when a new ICore Blocks release ships, and occasionally something else about the product. It is not a newsletter and there is no drip sequence.

What is not in it. No tracking pixel, no open tracking, no click tracking, no per-recipient tracking link - the same commitment §3 makes for the website. We cannot tell whether you opened a message, and we have deliberately built it so that we cannot.

Leaving. Every message carries an unsubscribe link, it works in one click, and it takes effect immediately. We keep a record that the address unsubscribed - that record is what stops it being added again by mistake - and we stop using it for anything else. Retention is in §16.

We are told when you join. Each signup also places one short email in our own @systemsicore.com mailbox at Google Workspace, through Google's Gmail API, with the address, the name and company if you gave them, and the time. It is how we know the list is growing; it goes to nobody else.

The list itself is held in a database on Cloudflare (§14). It is never sold, rented, shared or used by anyone else.

5Job applications

If you apply for a role through the form linked from that role's page, you send us your name, your email address, your CV, up to five other documents you choose to attach, and an optional note. That is everything the form asks for.

The website keeps no copy. The form posts to a small program running on Cloudflare that puts what you sent into one email, with your files attached, and places it directly in our careers@systemsicore.com mailbox at Google Workspace through Google's Gmail API. It is not sent across the public email network on the way, and that program stores nothing. If a send fails it logs the role, how many files there were, their total size and the error code - never your name, your address or your files. The form sets no cookie and loads no third-party script, like the rest of this site (§3).

Who sees it, and what for. Only the people hiring for the role. We use it to assess your application and, if we offer you a role, to prepare the agreement with you. It is not shared with anyone outside that process, and it is never added to the release list or to any other mailing.

How long. We keep an application for 12 months after the role closes and then delete it, unless you ask us to delete it sooner. If you join us, it becomes part of your contractor or partner record. Write to careers@systemsicore.com to see what we hold about you or to have it deleted.

The program runs on Cloudflare, and the application is held in Google Workspace (§14).

6Account data

When you create an account we hold what you give us: email address, and optionally full name, display name, company, job title, country, locale and an avatar. We also hold two preference flags - whether you have opted in to marketing email (off by default) and whether telemetry is on (on by default) - and the timestamps of account creation, last update and last activity.

Signing in with Google. If you choose Continue with Google on the Portal, Google confirms who you are and sends us your email address, whether Google has verified it, your name, a link to your Google profile picture and an identifier for your Google account. We store these with your account and use them only to sign you in and fill in your profile, exactly as if you had typed them in yourself. We ask Google for basic profile information and nothing else: we cannot see your Google password, and we cannot read your mail, contacts, calendar or files. If an account with the same email address already exists, Google becomes a second way into that account rather than a new one. Deleting your account (§18) removes the Google link with it. Google's own handling of your sign-in is covered by Google's privacy policy.

If you belong to an organisation's licence, your membership and role are recorded, and that organisation's administrators can see your seat and your activations.

7Licence, activation and trial data

A licence record holds its key, plan, tier, seat count, term and status, and who owns it. Each time the Software is activated on a machine, we record:

• a salted hash of a machine identifier - the raw identifier is computed on your machine and never leaves it; what we store cannot be reversed back into it, and it is used only to tell one activation from another;
• the machine label you chose, the operating system, the CPU architecture and the application version;
• when the seat was activated, last seen and deactivated.

The Trial tier works the same way, without an account. Activating a 30-day trial creates no user record and asks for no email address: the licence is bound to the salted machine hash alone, so the trial record identifies a machine rather than a person. The IP address of the activation request is logged as a security event under §10, as it is for every request we serve.

We issue short-lived signed tokens so the Software can verify its licence offline. A record of each token - its identifier, when it was issued and when it expires - is kept so it can be revoked.

8Usage telemetry

With telemetry on, the Software reports two kinds of thing.

Sessions - a session identifier generated by the application, the application version, the operating system and architecture, the salted machine hash, when the session started and ended, how long it was actively in use, and how it ended (clean exit, crash, or lost heartbeat). Active time is measured from foreground use, not wall clock, so an application left open overnight does not read as eight hours of work. The session is recorded against the account, the licence and the activation it ran under, together with whether it was running in offline grace.

Events - the name of an action, a timestamp, and at most one label drawn from a closed vocabulary. The actions are: a model opened, a model saved, a simulation run, a code-generation run, a block added, an export, a plugin loaded, an SDK call, a licence check, a licensed feature blocked - and the updater's four: a check, a download, an update applied, an update failed.

Where an event carries a label, that label is one of these and nothing else:

• the code-generation target, as a language name - c, cpp, rust, python, matlab, java, vhdl, verilog, systemverilog, st;
• the block type as it is spelled in the catalogue - Control_Systems/Base_Blocks/Gain - never the name you gave your instance of it;
• what kind of thing was exported - simulink, recipe, hdl - never where it was written;
• the licence state a check resolved to, and which feature was blocked when you hit a tier limit;
• for the updater, what a check concluded (up to date, an update is available, held by a version ceiling, held by a staged rollout, and so on) and why an update failed, as a category - denied, download failed, digest mismatch, signature invalid, and the rest. Never a path, a host, a server's message, or the build you are on.

The shape enforces that, rather than our remembering it. A label longer than 64 characters, or containing anything outside letters, digits, _, - and /, is replaced with unspecified before it is sent - a rule that every file name, every extension and every path a person would actually have fails.

Neither the session record nor the event record stores an IP address or any other network identifier. Cloudflare still sees the request itself, as it does every request we serve (§3).

We use this to see which export targets are actually used, which features people hit a tier limit on, and whether a release is crashing - or failing to update - more than the one before it.

9What we never collect

This is a design constraint, not a policy we could quietly relax: the event pipeline accepts type names, counts and a fixed set of properties, and there is no path through it for model content. Your engineering IP is yours, and it stays on your machines.

We also do not sell personal information, do not share it with advertisers or data brokers, and do not use it to build profiles for anyone else.

10Security and download logs

Authentication events - sign-in, sign-out, password reset, and failed attempts - are logged with the account (or, for a failed sign-in with no matching account, the email address that was tried), the source, the application version where relevant, the IP address, the user agent and the country. This is how we detect credential stuffing and tell you about a sign-in you did not make.

Download events - every request for an installer or an SDK archive is logged with the release, the account and licence, whether it was granted or denied and why, the IP address, the user agent and the country. Denials are logged as carefully as grants; that record is what tells us a legitimate customer is being blocked by a bug rather than by policy.

Turning telemetry off does not stop these two. They are security records rather than product analytics: they are what answers was my account attacked and why can this person not get in, and someone who declined usage analytics has not asked to be left unprotected. What limits them is retention instead - the IP address and the user agent are erased after 90 days, and the event and its outcome are what remain.

11Payments

We never see your card. Paddle.com Market Limited is the merchant of record for every purchase. You transact with Paddle; Paddle collects and processes your payment details, billing address and tax information under its own privacy policy, and it is the controller of that data.

What Paddle passes back to us, and what we store, is: the customer and subscription identifiers, the plan bought, the amount, the currency, the billing period and status, and the country used for tax. Enough to know what you are entitled to and when it renews - not enough to charge you ourselves.

12Support and verification

When you email support we hold the correspondence and anything you send with it. If you attach a model to a bug report, we hold that model - but only because you chose to send it, and we use it only to answer your ticket.

The contact form. If you write to us through the form on the contact page, you send us your name, your email address, optionally your company, the topic you picked and your message. A small program on Cloudflare puts that into one email and places it directly in our @systemsicore.com mailbox at Google Workspace through Google's Gmail API; the program stores nothing, and if a send fails it logs only the topic, the message length and the error code. We use it to answer you, and it is treated like any other correspondence from then on. Writing to us never adds you to the release list or to any other mailing.

The Non-Commercial and Educational tiers require verification. We hold what you provide to establish eligibility - for example an academic email address, proof of enrolment or employment, or a description of your project - and the outcome and date of the review. We keep the outcome; we delete supporting documents once the review is decided.

13Why we use it, and on what legal basis

Under PIPEDA and BC PIPA we rely on your consent, express or implied, for these same purposes, and limit collection to what is reasonably necessary for them.

14Who else processes it

• CloudflareHosting, CDN, edge compute and object storage for the site, the portal, the licensing API and the installer archives. Processes request metadata and stores the files we serve. Job applications (§5) and contact-form messages (§12) pass through it on their way to Google Workspace and are not stored there. The release list (§4) is stored in a Cloudflare database.
• SupabaseManaged PostgreSQL and authentication. Holds the account, licence, activation and event records described above.
• PaddleMerchant of record. Independently controls payment, billing and tax data (§11).
• Google WorkspaceEmail for our own @systemsicore.com addresses. Holds support correspondence and contact-form messages (§12), the job applications placed in the careers@systemsicore.com mailbox (§5), and the note we receive about each release-list signup (§4); the last three arrive through the Gmail API.
• Google FontsFont delivery only. Receives the IP address and user agent of visitors to this site (§3). No cookie, and no data flows back to us.

Each is bound to process data only on our instructions, except Paddle, which is an independent controller for the payment relationship, and Google when you choose to sign in with it, which is an independent controller of your Google account. We do not sell or rent personal information to anyone, and we disclose it otherwise only where the law requires it, or to a successor if the business is transferred - in which case this notice continues to apply until you are told otherwise.

15International transfers

We are in Canada; our processors operate globally, so your information may be processed outside your country, including in the United States and the European Union. Canada holds an EU adequacy decision for commercial organisations. Where a transfer is not covered by adequacy, it is made under Standard Contractual Clauses or the equivalent UK addendum. Write to us if you would like the details for a particular processor.

16How long we keep it

• Account and profile - while your account exists, and until you delete it.
• Licence and activation records - for the life of the licence and a period afterwards, so that entitlement can be reconstructed. A perpetual licence never expires, so its record is kept for as long as it may need to be honoured.
• Telemetry - sessions and events are deleted 13 months after they are recorded. Each night they are also rolled up into a per-account daily summary - session count, active and elapsed time, simulation and code-generation runs, and which targets were used. That summary is still tied to your account, so it lives while the account does and is deleted with it. Turning telemetry off stops collection; ask and we will delete what we already hold.
• Auth and download logs - the events are kept as a security record; the IP address and user agent on them are erased after 90 days (§10).
• Offline licence tokens - the record of an issued token, which exists so the token can be revoked, is deleted 30 days after that token expires.
• Billing records - kept for the period Canadian tax and accounting law requires, regardless of account deletion.
• Verification documents - deleted once the review is decided; only the outcome is kept.
• Release-list subscription - while you are subscribed. When you unsubscribe we delete the name and company immediately and keep the address with its consent history, so that the unsubscribe can be honoured and proven; ask and we will erase that too, accepting that we then have no record telling us not to add you again.
• Job applications - 12 months after the role closes, then deleted, unless you ask us to delete yours sooner. If you join us, your application becomes part of your contractor or partner record. The website itself keeps no copy (§5).
• Support correspondence and contact-form messages - kept while they are useful for answering you, then deleted.

Where we cannot delete something because the law requires us to keep it, we restrict it to that purpose alone.

17Your rights

Wherever you live, you can ask us to:

• Access - give you a copy of what we hold about you.
• Correct - fix anything inaccurate. Most of it you can edit yourself in the Portal.
• Delete - erase your account and the data tied to it (§18).
• Port - send you your data in a machine-readable form, or to someone else.
• Object or restrict - stop or limit a processing we base on legitimate interests. For telemetry, the switch in the application does this immediately and needs no request.
• Withdraw consent - unsubscribe from marketing at any time, from a link in the email or from the Portal.

Email support@systemsicore.com. We reply within 30 days, and we do not charge for a reasonable request. We may need to confirm your identity first - normally by asking you to write from the address on the account.

We take no automated decision that produces a legal or similarly significant effect on you.

18Deleting your account

You can delete your account from the Portal, or ask us to at support@systemsicore.com from the address on the account. Deleting it removes your profile, your organisation memberships, your activations, your sessions, your usage events and the daily summaries built from them.

Two things survive deletion, and each is kept for one reason only. Billing and tax records, held by us and by Paddle, because the law requires us to keep them. And one archive row per personal licence destroyed: its key, plan, tier, status, seat count, term, Paddle subscription identifier, and the email address the account used. It is the only remaining record that the licence was ever issued to you - which is what lets us answer you if you come back about it - and it is reachable by nobody but us. Ask, and we will tell you what that row says about you or delete it, unless a live subscription still depends on it.

Deleting your account ends any subscription's access at the end of the paid period and does not itself trigger a refund; see the Refund Policy. If you hold a perpetual licence, tell us before deleting, so the entitlement can be preserved or transferred rather than lost.

19How it is protected

• Everything is served over TLS. The desktop application never connects to our database directly - every read and write goes through an authenticated API.
• Database access is governed by row-level security, so an account can reach its own rows and no one else's. The privileged key that bypasses it exists only inside the server environment.
• Installer and SDK archives are never public. Each download is a signed URL valid for a few minutes, and every request - granted or denied - is logged.
• Licence tokens are signed with Ed25519. The private key lives only in the server's secret store and never appears in the database or in anything the application ships with.
• Machine identifiers are salted and hashed before storage; the raw value never leaves your machine.
• Passwords are stored hashed by our authentication provider. We never see them.

No system is perfect. If a breach is likely to result in a risk to your rights, we will notify you and the relevant regulator - the Office of the Privacy Commissioner of Canada, and any EU or UK authority with jurisdiction - as the law requires.

20Children

The Software is engineering tooling for professional and academic use. It is not directed at children, and we do not knowingly collect information from anyone under 16. If you believe a child has given us information, write to us and we will delete it.

21Changes to this notice

We will update this notice as the product changes. The version and effective date at the top of this page always say which one you are reading. If a change materially affects how we use your information, we will tell you by email or in the Portal before it takes effect.

22Contact and complaints

Integrated Core Systems
1801-1700 Blanshard St
Victoria, BC  V8W 0G8
Canada
Privacy questions and requests: support@systemsicore.com

If we have not resolved your concern, you can complain to the Office of the Privacy Commissioner of Canada, to the Office of the Information and Privacy Commissioner for British Columbia, or - if you are in the EEA or the UK - to your local supervisory authority or the UK Information Commissioner's Office. We would rather hear from you first.