JDDARS LLC, doing business as GairCor Technologies
Version 2.4 · Effective date: October 4, 2026
Applies to gaircor.com, the App Hub and product pages hosted on it, the forms and scheduling page on it, the downloads it offers, and email sent to or from the addresses published on it.
Part I — The short version
This part is a summary. It is written to be genuinely useful, not to be relied on in a dispute. Where this part and Part II differ, Part II controls.
What this business is. A small Louisiana software company. We build desktop and web applications, publish them through an App Hub, and take consulting engagements. There is no advertising network behind this website, no marketing department, and no program of any kind that monetizes what we learn about you.
This site recorded browsing sessions until September 12, 2026, and version 2.0 of this policy did not say so. Session replay has now been switched off: no recording is made when you browse this site. Recordings captured while it ran still exist at our analytics provider and are deleted automatically 30 days after each was made, so none will remain after mid-October 2026. §2.3 sets out in full what those recordings contain, because we would rather describe what was collected than quietly drop the subject. Heatmaps are still switched on — aggregate maps of where visitors click and how far they scroll, which is not a recording of any individual session.
Whether any of that runs at all depends on where you are, and the two halves are different. If you are in the EU, the EEA or the United Kingdom — or if we cannot tell where you are — nothing is captured until you press Accept on the banner. Everywhere else, including the United States, analytics and heatmaps run by default and you turn them off with the Cookie settings link in the footer. We say this plainly because "privacy-friendly analytics" is not the same sentence as "we ask first", and the banner only appears for some of you. §2.1 and §3.
Your IP address is read for location, then truncated before it is stored. Our analytics provider reads the full address to derive the country, region or state, city, postal code, time zone and an approximate latitude and longitude with a stated accuracy radius — that is more than "approximate country", and the old policy understated it. It then replaces the final part of the address with zero and stores that instead, so the address kept on the event is not yours. The location values are unaffected, because they are derived first. Events recorded before this policy's effective date keep the full address. §2.2 and §5.
The consent banner does not look you up anywhere. Your country is read from a file our own hosting provider serves at the edge. No third-party geolocation service is contacted to decide whether to show you the banner. §5.5.
We do not sell your information. Not to data brokers, not to lead aggregators, not to advertisers, not to anyone. We receive no money and nothing else of value for it. There is no advertising pixel, no tag manager and no cross-site identifier on this site. §18.
What we collect from you directly is what you type into the contact form — your name, your email address, optionally your company and phone number, your message, and which product or category you were looking at. That is the whole of it. §2.4.
This website never emails you. There is no mailing list, no newsletter, no marketing mail and no automated acknowledgement — not even a "thanks, we got it". When you write to us, a person reads it and replies from an ordinary mailbox. §6.
One consequence of that you should know. Our contact form carries a hidden anti-spam field. If something fills it in — a password manager doing its job is the realistic case — the submission is discarded and the page still tells you it was sent. If you send us something that matters and hear nothing back, email legal@gaircor.com rather than assuming it arrived. §11.6.
Almost nothing here deletes itself, and we will not pretend otherwise. Three things expire on a timer and we name them: the session recordings made before replay was switched off, 30 days after each was made; our own copy of analytics events, after 90 days; and the staging rows of the transfer that produces that copy, nightly. Everything else — your message, your booking, your account, our copy of a payment record — stays until a person deletes it by hand. There is no purge job for any of it. §10.
A download from this website is a plain link and leaves no record; a download through the App Hub application is a different thing. Nothing on gaircor.com asks you to sign in before downloading, nothing expires, and nothing about the request is written down — and today no installer link is configured here at all, so the page shows "coming soon". The App Hub application, which you install separately, uses a protected flow that requires a signed-in account with a confirmed email address, issues a link that dies after five minutes, and writes an audit row. Neither path checks whether you paid for anything. §2.6.
A hash is not anonymity, and we do not describe it as one. In that App Hub audit row we store a salted one-way value derived from the IP address instead of the address itself. That is a real control and we are glad to have it. It is still information about a person, we treat it as such, and we will never call it anonymous. §9.
Our copy of payment records is more complete than we would like, and you should know that too. Our billing mirror deliberately stores no email address for a customer it can map to a product. But a Stripe record it cannot map is written down whole, exactly as Stripe sent it — and for a customer record that includes the name and email address. Records like that exist in our database today. §2.7 and §9.2.
We have not registered a copyright agent. There is no designated DMCA agent for gaircor.com with the U.S. Copyright Office, so the statutory safe harbor is not available to us. We still act on takedown notices; the Terms of Use describe how. We would rather say this than imply a protection we never secured.
Disagreements are resolved by individual arbitration under the Terms of Use. This policy does not create a second route and does not restate the mechanism. §19.
You can ask for a copy of what we hold, ask us to correct it, or ask us to delete it. Email privacy@gaircor.com. We offer this to everybody who asks, not only to residents of states whose law requires it, and §12 is honest about what we can and cannot reach.
Part II — The Policy
The following is the operative text. Each section opens with a one-line summary in italics; the summary is a reading aid and the numbered text that follows it controls. Capitalized terms are defined in §23.
1. Scope, and who this policy is for
In short: this covers everyone who reaches GairCor through this website, a form, the App Hub, the scheduling page, or email.
1.1 Who we are. The business responsible for the information described here is JDDARS LLC, a Louisiana limited liability company, doing business as GairCor Technologies ("GairCor", "we", "us", "our"). Our address is 609 Metairie Rd #8259, Metairie, LA 70005. We are the controller of the Personal Information described in this policy.
1.2 What this policy covers. Personal Information collected through the website at gaircor.com (the Site), including the App Hub, the product, services, docs and blog pages, the contact form, the scheduling page, downloads offered through the Site, and email exchanged with the addresses published on it.
1.3 What this policy does not cover.
- Individual products with their own accounts. GairCor Flow and the GairCor AI Prompt Engine are separate applications on their own domains, with their own sign-in and their own product notices. Where a product publishes its own privacy notice, that notice governs that product and this one governs the Site. Nothing in this policy describes what happens inside those applications.
- The Ops Portal. GairCor runs an internal operations portal. It is not a public service, it is not offered to you, and it is reachable only by GairCor staff behind a network gate and a password. It appears in this policy only where it is the reason something happens to your information — see §20 and §22.
- Third-party sites and services you reach from here, including the scheduling service embedded on the scheduling page, and anything you reach by following a link.
- Information you give directly to a third party, even where we pointed you at them.
1.4 Who this policy is about. Five audiences, addressed throughout:
| Audience | Who that is | Where their information is described |
|---|---|---|
| Site visitors | Anyone browsing the Site without submitting anything | §2.1, §2.2, §2.3, §3, §5 |
| Enquirers | Anyone who submits the contact form | §2.4, §6, §10 |
| People who book a call | Anyone who schedules through the embedded scheduling page | §2.5, §7 |
| Account holders | Anyone holding a GairCor account used by the App Hub application to authorize a download. No account is created or used on this website | §2.6, §8 |
| Customers | Anyone who has paid for a GairCor product | §2.7, §4.5 |
1.5 Sensitive information, said plainly. No form on this Site asks for a Social Security number, a government identification number, a bank credential or a payment card number, and no page on this Site takes a payment. Card details for a paid product are handled by our payment processor on its own pages and infrastructure; we never see or store a card number (§2.7). If a page purporting to be ours asks you to type a card number or a password into a form, it is not ours — write to privacy@gaircor.com before you send anything.
2. What we collect, from whom, and why
In short: a detailed record of how you use this site; what you type into the contact form; what the scheduling service passes us; and a small amount our systems generate.
We collect information in two ways: you give it to us, or our systems and our providers record something about your visit. There is no third category — we buy no lists, we receive no data from data brokers or advertising networks, and we do not enrich or append anything to what you provide.
2.1 Site visitors — product analytics
Our analytics provider is PostHog, operating in the United States. Our analytics library starts in an opted-out state, so nothing is sent until a decision is made about your region:
- If you are in the EU, the EEA or the United Kingdom, nothing is captured until you accept. The banner appears, the library stays opted out, and declining leaves it opted out. The countries treated this way are exactly: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden and the United Kingdom.
- If we cannot determine your country, you are treated as though you were in that group. The failure is deliberate and it fails toward asking.
- Everywhere else, including the United States, analytics are switched on automatically when the page loads, and your choice is recorded as granted without a banner being shown. You can withdraw it at any time through the Cookie settings link in the footer, which reopens the same banner. This is an opt-out, not an opt-in, and we will not describe it as one.
What is actually captured. A defined set of events, not a general recording of everything the page can see:
| Event | When it fires |
|---|---|
| Page view | You open or reload a page on the Site |
| Web vitals | Your browser finishes measuring a page-performance metric — loading, responsiveness and layout stability |
| App Hub product viewed / product opened | You open or expand a product in the App Hub |
| App Hub product searched / category filtered | You use the App Hub search box or a category filter. The search event records the length of what you typed, not what you typed |
| Contact form submitted / failed | You submit the contact form. The event records the enquiry type and two true/false values — whether you filled in a company and whether you filled in a phone number. Your name, email address, phone number and message are not in the analytics event |
| Consultation requested / schedule call clicked | You follow a booking link from a product or the scheduling page |
What travels with each event. The page address including anything after the ?, the path, the host, the page title, the address of the page that referred you and its domain, the search engine you arrived from where there was one, your browser and its version, your operating system and its version, your device type, your browser language, the size of your screen and of your browser window, the raw user-agent string your browser sends, the analytics library and its version, a classification of whether the request looks like a bot or an automated agent, and three routing values we add ourselves — app_id, env_key and platform — so the event can be attributed to the right GairCor application. The values derived from your IP address are described separately at §2.2 because they deserve to be.
You are not identified. Nothing on gaircor.com associates an analytics record with your name or email address. The analytics library assigns a randomly generated device identifier, stores it in your browser (§3.2), and that identifier is what our reports count. No call that would attach your identity to it is made anywhere on this Site.
What is not switched on. There are no surveys on this project. Exception and error autocapture is not enabled — our client configuration contains a flag that would request it, but the feature is off at the project, no exception events exist, and we do not describe error capture as something this Site does. Dead-click capture is off. There is no advertising or attribution integration of any kind.
2.2 The location our analytics provider derives from your IP address
Your address is read to derive location, and then truncated before the event is stored. Two steps run in order when an event reaches our analytics provider. First, a geolocation step reads the full address and attaches the values listed below. Second, an anonymization step replaces the final part of the address with zero — 203.0.113.144 becomes 203.0.113.0 — and it is that truncated form which is stored on the event. Because the location step runs first, the values below are still derived from the full address and are no less precise than they were; what changes is what is kept afterwards. The values derived and attached to the event are:
- the country and continent,
- the region or state and its code,
- the city,
- the postal code,
- the time zone, and
- an approximate latitude and longitude, together with an accuracy radius in kilometres stating how precise the match is.
Events recorded before this policy's effective date carry the full address, because the truncation step was added on that date. Those events are not rewritten; they keep the full address until they age out of our own copy under §10.2 and out of our provider's store under its own schedule.
This happens on our provider's own infrastructure as part of processing the event; we do not operate the lookup and we do not send your address to a separate geolocation service to obtain it. We describe it here at this length because version 2.0 of this policy said "approximate location (country/region)", and that was an understatement of what is collected. This is separate from, and unrelated to, the country check that decides whether you see the consent banner — that check is described at §5.5 and contacts nobody outside this site.
2.3 Session recording and heatmaps — read this section
Session replay has been switched off. It is not running on gaircor.com and no recording is made of your visit. We are leaving this section in place at its full length for two reasons: recordings made before it was switched off still exist, and a reader deserves to be told what was collected while it ran rather than find the section quietly deleted.
2.3.1 What was recorded, and until when. Session replay ran on this site until September 12, 2026. While it ran, a recording of each visit was made and sent to our analytics provider, subject to the same consent position as the rest of analytics (§2.1): it did not run for a visitor in the EU, the EEA or the UK who had not accepted, and it ran by default everywhere else. A recording contained:
| Captured | Detail |
|---|---|
| The pages you visited | Each page address you opened during the session, in order, and the site that referred you |
| Timing | When the session started, how long it lasted, and how much of that was active rather than idle |
| Your clicks | Where you clicked, and on what |
| Pointer and scroll activity | Mouse movement and activity counts, and how far down each page you reached |
| The rendered page | A reconstruction of what was on your screen, so the session could be played back as video |
| Network timing | Performance timing for the resources the page loaded. The contents of network requests and responses were never captured — no request bodies, no response bodies, no headers |
| Your browser and device | The same technical values listed at §2.1, and the location values at §2.2 |
Console output was not captured, because console-log capture is switched off on this project.
2.3.2 What was masked, stated exactly. Text typed into a form field was masked by the recording library, and the characters typed were not reproduced in the recording. That was the protection, and it is the only one of its kind we claim for the period it ran. Two things follow that we would rather you heard from us:
- Masking applied to input, not to the page. Text simply displayed on a page — anything printed on screen rather than typed by you — formed part of what a recording reconstructed.
- We configured no additional masking rules of our own. What applied was the recording library's default behaviour, unmodified. We did not tell you your typing was "safe"; we told you it was masked by default, which is a narrower statement and a true one.
2.3.3 How much was recorded. No sampling rate was set, so every session was eligible for recording rather than a fraction of them. No minimum session length was set, so short visits were recorded too. No page was excluded from recording; there was no blocklist of addresses on this project.
2.3.4 What happens to the recordings that already exist. Each is deleted 30 days after it was made. The retention period is set on the project and enforced automatically by our provider, which counts each recording down and deletes it. Because replay was switched off on September 12, 2026, no recording of this site will remain after mid-October 2026, and no new one is being created. When a recording is deleted, the analytics events from that same session remain — the page views, the product views, the form-submission event — because those are separate records. We say so rather than let "the recording is deleted" be heard as "the visit is forgotten".
2.3.5 Heatmaps, which are still running. Heatmap collection remains enabled, and it is not session replay. A heatmap aggregates where visitors clicked and how far they scrolled on a given page, so we can see which parts of a page are used. It is not a reconstruction of one person's visit and it cannot be played back as one. It is subject to the same consent position as the rest of analytics.
2.3.6 How to stop what is still running. Declining on the banner, or opening Cookie settings in the footer and declining, opts you out of all of it — events and heatmaps together. There is no separate switch for heatmaps alone, and we would rather say so than describe a control that does not exist.
2.4 The contact form
The form collects:
| Field | Required | Purpose |
|---|---|---|
| Name | Yes | To answer you |
| Email address | Yes | To answer you |
| Company | No | Context for the enquiry |
| Phone number | No | So we can call you back if you would rather we did |
| Message | No | Whatever you want to tell us |
| Enquiry type | Defaults to "general" | To route the enquiry |
| Product / category | Set by the page | Which product or category you were looking at when you wrote |
Stored alongside it: the date and time of submission, and the contents of the hidden anti-spam field described at §11.6, which is normally empty.
Your IP address is not written to your enquiry record. It is read from the request and used in memory to enforce a rate limit, and it is not stored with the enquiry or anywhere else in that operation. §5.3.
2.5 Scheduling
Scheduling on this website is the embedded scheduling service and nothing else. The scheduling page loads a third-party scheduling service (§4.4) in a frame. When you book, you are booking with that service, on its infrastructure, under its own privacy policy — the name, email address, telephone number and anything else its form asks for are collected by Calendly as the processor of that booking, not by any form of ours. We see the resulting appointment through that service.
This website writes no booking record of its own. No page on gaircor.com creates a row about your appointment in a GairCor database. There is no booking form here, and the scheduling page's only function is to display the embed.
Where you reach the scheduling page from a product or a topic link, we pass the product, category and enquiry type into the embed as pre-set fields so the booking arrives labelled. Nothing about you personally is added to that.
A feature that exists but is not connected. GairCor operates a server function that would write a booking — name, email address, optional phone number, product, category and the scheduling service's reference for the event — into our own database. Nothing calls it: not this website, not any other GairCor application. Two records created while testing it exist in that table. We describe the function because it exists and could be connected, and we will update this section before it is.
2.6 Accounts, and the two different ways a download happens
There is no sign-up or sign-in on gaircor.com. No page on this Site offers to create an account or to log in. The account system described here belongs to the App Hub application — a separate GairCor application you install — and is reached through it, not through this website.
Where an account exists, it holds your email address, whether that address has been confirmed, an internal account identifier, and a profile record holding a display name — which, unless you set one, is your email address — an optional avatar address, a role, and the dates the record was created and last changed. Authentication is operated by our platform provider (§4.1); we never hold your password.
Downloading from this website: a plain link, and no record. Where a product page on gaircor.com offers an installer, it offers it as an ordinary download link to a hosted file. No account is required, no email address is confirmed, the link does not expire, and nothing is written down — no audit record, no account identifier, no hashed address, nothing. Your request reaches the file host and our own hosting provider in the ordinary way (§4.2, §5.1) and that is the whole of it. As at September 12, 2026 no installer address is configured, so the product page shows a "coming soon" state instead of a link, and no download has been served from this website at all.
Downloading through the App Hub application: an account, a short-lived link, and an audit record. The protected download flow is used by the App Hub application, which is its only caller. When it runs it requires a signed-in account, a confirmed email address, and an app marked published, and it applies a rate limit of ten download requests per minute per account. It then issues a link that stops working after 300 seconds — five minutes — and writes an audit record containing your account identifier, the app, the version, the file, the date and time, and a salted one-way hash of your IP address rather than the address itself (§9.2.1). That application is distributed separately from this website and may carry its own notice; where it does, that notice governs it and this section describes only the server-side flow common to both.
One thing about that flow we would rather state than let you assume: it does not verify a purchase. A stale comment in its own source describes it as validating entitlement. It does not — it checks sign-in, email confirmation, the rate limit and publication status, and it consults no purchase, subscription or billing record at all. We describe the software as it is built rather than as it is labelled, and we will update this section if that changes. No audit record of a download exists in our database today.
2.7 Payments
Payments for paid products are taken by Stripe (§4.5), on Stripe's own pages and infrastructure. No page on gaircor.com accepts a card number, and GairCor never receives or stores one.
What reaches our own database is a billing mirror, and it is uneven in a way worth describing precisely:
- Every event Stripe sends us is verified against Stripe's signature before it is acted on, and recorded once — a repeated delivery does not create a second record.
- The whole event, as Stripe sent it, is stored. For a purchase that payload can include the buyer's name and email address, the billing address where one was collected, and the card's brand, country and last four digits. Not the card number.
- The mapped customer record deliberately holds no contact details. Where we can attribute a Stripe customer to one of our products, we store the Stripe customer identifier, the Stripe account, and the product — and nothing else. No email address, hashed or otherwise, is written to it.
- A record we cannot attribute is written down whole into a diagnostic table, exactly as Stripe sent it. For an unattributed customer record that includes the name and email address, and records of that kind are in our database today. They are not deleted on any schedule (§10.2).
- Product, price, subscription and invoice records hold identifiers, amounts, currency, interval, status and dates.
2.8 Email correspondents
If you email an address published on this Site, or reply to a message from a person here, that message sits in an ordinary mailbox with everything in it — the address you sent from, the subject, the body, and any attachment. A person reads it. Nothing parses it automatically, nothing files it against a record, and nothing removes it on a schedule.
2.9 Information we generate
Some of what we hold about you is written by us or by our systems rather than by you, and it is still your Personal Information for the purposes of an access request under §12:
- The analytics record of your visit, including the derived location values (§2.2) and any session recording within its 30 days (§2.3).
- The copy of that analytics record inside our own database (§4.3), and the aggregate daily counts built from it.
- The audit record of a download taken through the App Hub application (§2.6), including the hashed address value.
- The internal AI outputs described at §22, where a question an operator asked happens to concern your enquiry.
2.10 What we do not collect
We buy no lists. We receive no information about you from data brokers, advertising networks, lead aggregators or enrichment services. We run no browser-fingerprinting library. We do not ask for, and have no field for, a government identification number, a financial account credential or any special category of data. There is no identity-verification, know-your-customer or sanctions-screening process behind this Site, and no product offered through it requires one today.
3. Cookies and browser storage
In short: your consent choice, and the analytics identifier. No advertising cookie, no tag manager, no cross-site identifier.
3.1 Your consent choice. Your decision about analytics is written to your browser's local storage under a single key, holding one of two words — granted or denied. It is local storage, not a cookie, it is never transmitted to us as a cookie would be, and clearing your site data removes it. Removing it does not undo any collection that already happened; it means the next visit decides again from your region.
3.2 The analytics identifier. Our analytics library stores a randomly generated device identifier, together with a small amount of its own session state, in a cookie and in your browser's local storage. It exists so that two page views in the same visit can be counted as one visit. Cookieless mode is not enabled on this project, so this is set in the ordinary way rather than derived server-side. It is set only once analytics are running — which, in the EU, the EEA and the UK, means only after you have accepted.
3.3 The scheduling embed. The scheduling page loads a third-party scheduling service in a frame. That service may set its own cookies in your browser under its own terms when the embed loads. We do not control them, we do not read them, and nothing they hold is reported to us.
3.4 What we do not set. No advertising cookie. No tag manager. No conversion pixel. No cross-site or cross-device identifier. No preference or profiling cookie of our own.
3.5 One thing that does not happen. The typeface used on this Site is served from gaircor.com itself, compiled into the site when it is built. Your browser makes no request to a font host when a page loads here.
4. Service providers, by name and function
In short: the businesses that operate parts of this service, and the one outside service your browser contacts directly.
We disclose Personal Information to service providers only so they can perform the function named below, and we do not authorize any of them to use it for their own purposes. This is a complete list of the providers that receive or process Personal Information for this Site as at September 12, 2026.
4.1 Supabase — database, authentication, file storage and server functions. The contact enquiries, account records, the App Hub application's download audit records, the billing mirror and the copy of analytics telemetry all live on infrastructure Supabase operates.
4.2 Cloudflare — hosting, content delivery, DNS, and the network gate on our internal portal. Every request to this Site passes through Cloudflare before it reaches our software, so Cloudflare necessarily processes the raw IP address of every visitor in order to deliver the page, and keeps its own logs on its own schedule. Statements elsewhere in this policy about what we do not store describe our own records; they do not and cannot describe what a hosting provider processes in transit.
4.3 PostHog — product analytics and heatmaps, operating in the United States. Session replay ran on this project until September 12, 2026 and is now switched off (§2.3). PostHog receives everything described in §2.1, §2.2 and §2.3. It receives your IP address, derives the location values from it, and then truncates it before the event is stored (§5.2). Separately, a batch export is configured to copy event telemetry from PostHog into GairCor's own database, where it is retained under §10.2 rather than under PostHog's schedule. As at September 12, 2026 that export has delivered no rows; the copy in our database holds only a small set of records transferred by hand in July 2026.
4.4 Calendly — scheduling. Embedded in a frame on the scheduling page. When you book, you are giving your details to Calendly, which is the processor of that booking, holds it under its own privacy policy, and notifies us of the appointment. No booking record is written into a GairCor database by anything on this website (§2.5).
4.5 Stripe — payments. Stripe collects and holds the card details; we receive the event records described at §2.7. Stripe is the merchant-facing processor and operates under its own privacy policy.
4.6 OpenAI — the AI features described at §22, which are internal to GairCor's own operations tooling. What is sent is described there.
4.7 Legal and safety disclosures. We may disclose information where required by law, to respond to lawful process, to establish, exercise or defend a legal claim, or to protect the rights, property or safety of any person.
4.8 Professional advisers. Accountants, auditors and lawyers engaged by GairCor, under their own professional duties of confidence.
4.9 Business transfer. If GairCor or a product of ours is sold, merged or reorganized, records may transfer as part of that transaction. Any recipient would take them subject to this policy.
4.10 What we do not share. No advertising network. No data broker. No lead aggregator. No marketing platform. No affiliate or attribution service. See §18.
5. IP addresses
In short: four different things happen to your IP address depending on which system sees it, and only one of them is a hash.
5.1 In transit, at our host. Cloudflare sees the raw address of every request, because it cannot deliver the page otherwise, and retains its own logs on its own schedule. Nothing in this policy changes that or can.
5.2 At our analytics provider — read for location, then truncated. Our provider receives the address with each event and reads it to derive the location values described at §2.2. It then replaces the final part of the address with zero before the event is stored, so what is kept is a truncated address and not yours. This applies to everything covered by §2.1, §2.2 and §2.3, and only where analytics are running for you at all. Two limits we would rather state than let you assume: the truncation applies to what is stored, not to what is received — the provider still reads the full address in the moment it processes the event — and events recorded before this policy's effective date keep the full address until they age out (§2.2).
5.3 On the contact form — used, not stored. When you submit the form, your address is read from the request and used to enforce a limit of five submissions per minute. The counter is held in the memory of the server instance that handled the request and is not written to any database. Your address is not stored on your enquiry record. Because the counter is per-instance and in memory, it is a spam control and not a security guarantee, and we describe it as the first rather than the second.
5.4 On a download through the App Hub application — hashed. That flow's audit record stores a salted SHA-256 hash of the address rather than the address. §9 describes exactly what that does and does not mean. A download taken from this website takes none of this path: it is a plain link, and no record of any kind is written (§2.6).
5.5 The consent banner does not geolocate you. To decide whether you are in a region that requires prior consent, the page reads a diagnostic file served by our own hosting provider at the edge of this site, which reports the country the request came from. No third-party geolocation service is contacted, no lookup is performed against your address by us, and the country read this way is not stored anywhere. If the file cannot be read, the answer is treated as unknown and you are shown the banner.
5.6 Stated exactly. For a visitor who declines analytics and submits nothing, no record containing your address or anything derived from it is created by us — Cloudflare's transit logs (§5.1) excepted. A download taken from this website does not change that, because it writes nothing. For a visitor running with analytics, the position is §5.2. For someone who submits the contact form, it is §5.3. For someone downloading through the App Hub application, it is §5.4 as well.
6. Communications, and your consent
In short: this website sends you no email of any kind, and there is no marketing list to join or leave.
6.1 We send no automated email. Submitting the contact form triggers no acknowledgement, no confirmation and no auto-reply. It writes a record and notifies us internally; nothing is addressed to you. Your enquiry is answered by a person writing to you from an ordinary mailbox.
6.2 There is no marketing email. No newsletter, no mailing list, no announcement list, no drip sequence, no bulk-send facility. There is nothing to unsubscribe from because there is nothing you can be subscribed to. If we introduce marketing email, every message will identify itself as promotional, carry a working unsubscribe mechanism and a valid postal address, and we will describe it here before the first one is sent (§17.4).
6.3 Account email. Where you hold a GairCor account (§2.6), our platform provider sends the account messages that keep it working — email confirmation and password reset. These are transactional, they are sent because you have an account, and they are not marketing.
6.4 Telephone. If you give us a phone number on the contact form, you are telling us we may use it to answer your enquiry. We operate no automatic dialler and no call list. GairCor does publish a telephone number — 800-380-7520 — but it is a support line, not a privacy channel; send privacy requests to privacy@gaircor.com so they are recorded and answered in writing (§21).
6.5 Text messages. This website has no text-messaging capability. It cannot send, receive or process a text message; no automated, scheduled or bulk text is ever sent from it; no keyword such as "STOP" is processed anywhere; and no list of numbers is compiled for texting.
6.6 What we do not do. We do not sell or rent your contact details, we do not pass your number or address to a lead-generation network, and we do not use what you tell us to target advertising anywhere.
6.7 A person reads what you send. No automated system interprets the content of your message, and nothing acts on it automatically.
7. Meetings, recording, and scheduling
In short: we run no meeting service and record no meetings — but this website records your browsing session, and that is §2.3.
7.1 Where a meeting happens. Bookings made through the scheduling page are held on the third-party scheduling service (§4.4) and the meeting itself takes place on whatever platform that service or the parties choose. GairCor operates no video-meeting service of its own, installs nothing on your device, and requires no account of you.
7.2 This product records no meetings. There is no recording feature in any GairCor system covered by this policy: no recording storage, no recording index, and no code that starts, saves or retrieves a recording of a call. There is no consent flag for one, because there is nothing to consent to. If a meeting were ever to be recorded, every participant would be told before it began and asked, and we would describe the practice here first (§17.4).
7.3 The recording that used to happen was of your browsing, not of you. Read §2.3. We place this cross-reference here deliberately: a reader who comes to a section headed "recording" expecting to find out whether they are recorded should not have to hunt for the answer. Your browsing session on this website was recorded until September 12, 2026. It is not recorded now, and the recordings already made are deleted 30 days after each was made. §2.3 is the section that says so.
7.4 What the scheduling service holds. Your booking, the details you entered into its form, its own record of the appointment, and its own cookies (§3.3), under its own privacy policy. Cancelling or rescheduling with it does not delete its record, and we cannot delete it for you.
8. Accounts and the App Hub
In short: there is no document portal here; there is an account, it belongs to the App Hub application rather than to this website, and it is described at §2.6.
8.1 There is no client portal on this Site. GairCor operates no document-exchange portal, no client file area and no message thread for customers. Nothing on gaircor.com invites you to upload a document, and there is no path by which a file of yours reaches our storage through this Site. If a feature of that kind is ever built, this section will describe it before it opens.
8.2 What an account is for. Gating downloads inside the App Hub application, as described at §2.6. It is created and used there, not here. It holds an email address, a confirmation state, an internal identifier and a profile record. It carries no documents, no transaction, and no message history. Nothing on gaircor.com requires it, and no download offered from this website uses it.
8.3 The internal Ops Portal is not yours and is not offered to you. GairCor's operations portal is internal tooling for GairCor staff, reachable only through a network gate operated by our hosting provider and a password held by a staff account. It holds the aggregate reporting described in §10.2 and the AI outputs described in §22. No customer or visitor has an account on it, and none is offered.
8.4 What survives closing an account. Closing or deleting an account does not remove the App Hub download audit records written under it, the analytics records of the sessions in which it was used, or a copy of a payment record. §10.3 lists this definitively.
9. Hashes, copies, and what is not anonymous
In short: some of what we keep sounds anonymous and is not. This section names each one and says why.
This section is written twice: once in plain English, and once precisely. It exists because the most common way a privacy policy becomes untrue is by calling something anonymous that a court, a regulator or an engineer would call personal information.
9.1 In plain English
Three things in our systems look, at a glance, like information that is no longer about anybody. None of them is.
The hashed IP address on an App Hub download record. We do not store your address there; we store a scrambled value computed from it. That is genuinely better than storing the address and we are glad it is built that way. But the record it sits on also names your account, the file and the moment — so the row is about you regardless of what the address field contains, and the scrambled value itself is not anonymous either: anyone holding our database, the salt and a list of candidate addresses could test a guess. We call it pseudonymous. We will never call it anonymous and we will never call it "not personal information".
The random identifier in your browser. The analytics identifier is not your name, but it is how a series of visits become one visitor in our reports, and it travelled with a session recording for as long as replay was running (§2.3). An identifier whose entire purpose is to link records about one person is not anonymization.
Our copies of things our providers hold. A copy of an analytics event inside our own database is a second record with its own lifespan, not a view of the first one. Deleting the original does not reach it. The same is true of the Stripe payloads at §2.7: a record we could not attribute is sitting in a diagnostic table with the name and email address in it, and no schedule removes it.
9.2 Precisely
9.2.1 The App Hub download audit value. The function computes a SHA-256 digest of the client address concatenated with a salt held in the function's server-side configuration, and stores the hexadecimal digest in the ip_hash field of the audit row. The address itself is never written. The row also carries the account identifier, the application, the version, the asset and the timestamp. This applies to the App Hub application's download flow only; a download taken from gaircor.com produces no row at all (§2.6).
- It is not reversible in the ordinary course, and we do not attempt to reverse it.
- It is not anonymous. It is a deterministic value derived from a small input space. Where it can be linked to a person — and on a row that names the account, it plainly can be — it is Personal Information and is treated as Personal Information for every purpose in this policy, including an access request under §12.
- A comment in our database schema describes this field as "not PII". That comment is wrong, this policy governs, and the comment is not a representation to you.
- We do not publish the salt, its length or its source, because doing so would weaken the control.
9.2.2 The analytics device identifier. Randomly generated in your browser, stored there (§3.2), attached to every event, and to any session recording made while replay was running. Not derived from anything about you; still an identifier that links records about one person, and treated as Personal Information here.
9.2.3 Our own copy of analytics telemetry. The batch export at §4.3 writes into a staging table in our database and a scheduled transform copies rows into a permanent events table. The copy carries the event, its timestamp, the device identifier and the full set of event properties. It is a separate record with a separate lifespan (§10.2 rows 3 and 4). As at September 12, 2026 the export has delivered no rows and the permanent copy holds only the July 2026 hand-transfer described at §4.3, whose properties carry none of the technical or location values — but the mechanism is built to copy them, and this policy describes what it does, not only what it has done so far.
9.2.4 The Stripe payload copies. Described at §2.7. The whole event as Stripe sent it, and, for a record we cannot attribute, the whole object including the name and email address. These are not summaries, not tokens and not anonymized extracts. Nothing removes them automatically.
9.2.5 What we will never tell you. That a record has been deleted when a copy of it remains somewhere we named; that a hash is anonymous; that an identifier is not personal information; or that our providers' backups have been reached. Where we cannot reach something, §12.5 says so by name.
10. How long we keep information
In short: three things expire on a timer and we name them. Everything else stays until a person removes it by hand.
10.1 Three real periods, and then the honest part.
Exactly three things in this entire system delete themselves. The session recordings made before replay was switched off, 30 days after each was made, enforced by our analytics provider. Our own copy of analytics telemetry, after 90 days, by a scheduled job that runs nightly at 05:40 UTC and drops each day's partition once it is older than that. And the staging rows of the transfer that produces that copy, by a scheduled job at 04:30 UTC that removes rows already processed and more than two days old. All three are running as at September 12, 2026.
Nothing else expires. There is no retention job, no time-to-live and no clean-up task anywhere for enquiries, bookings, download audit records, account records, payment records or email. Every removal of those is something a person at GairCor does deliberately. We state it this way because the version of this policy being replaced said "operational logs are kept for a short period and then deleted or aggregated", and no job anywhere performed that. A stated retention period is a promise somebody has to keep by hand, and we will not make one we do not perform.
10.2 The schedule.
| # | Category | How long we keep it | What starts the clock | Basis | What remains afterwards |
|---|---|---|---|---|---|
| 1 | Session recordings made before replay was switched off (at our analytics provider) | 30 days from the recording, then deleted automatically. No new recordings are being made (§2.3) | The recording | Automatic, enforced by the provider | The analytics events from the same session — page views, product views, form events — which are separate records and are not deleted with it |
| 2 | Analytics events (at our analytics provider) | No expiry. A 12-month figure is configured on the project but retention is not enforced, so nothing acts on it | — | No mechanism performs a deletion | Everything |
| 3 | Our own copy of analytics events (in GairCor's database) | 90 days, then the day's partition is dropped | The day the event happened | Automatic nightly job, running | The aggregate daily counts built from it — totals and rates by day, not tied to a person |
| 4 | Staging rows of the analytics transfer | Removed nightly, once processed and more than two days old | Transfer into row 3 | Automatic nightly job, running | The copied record at row 3 |
| 5 | Aggregate reporting rollups | Indefinite | — | Day-level counts and rates; not attributable to an individual | Everything |
| 6 | Contact-form enquiries — name, email, company, phone, message, product, enquiry type, the anti-spam field, the timestamp | Until deleted on request or by manual review. No job removes them | — | Answering you, and evidence of what was asked and answered | Nothing automatic. Removal is by hand |
| 7 | Bookings held by the scheduling service — the only booking record your appointment creates | The provider's own schedule, outside our control | — | Calendly is the processor of the booking (§2.5) | Its record of the appointment. We cannot delete it for you |
| 8 | Booking rows in our own database (§2.5) | Until deleted by hand. No job removes them | — | Business record of an appointment | Nothing automatic. Nothing writes to this table — the two rows in it were created while testing |
| 9 | Download audit records from the App Hub application — account, app, version, asset, timestamp, hashed address | Until deleted by hand. No job removes them | — | Knowing which build reached which account, and abuse investigation | The hashed value survives with the row and remains Personal Information (§9.2.1). No such record exists today, and a download from this website creates none |
| 10 | Account and profile records | Until deleted by hand | — | Operating the account | Download audit rows written under it; analytics records of sessions in which it was used |
| 11 | Stripe event payload copies — the whole event as Stripe sent it | Until deleted by hand. No job removes them | — | Reconciling billing, and evidence of a transaction | Everything in the payload, including name, email address and billing address where Stripe collected them |
| 12 | Unattributed Stripe records — the whole object, including name and email address for a customer record | Until deleted by hand. No job removes them | — | Diagnosing a product mapping that failed | Everything. Records of this kind exist today |
| 13 | Internal AI outputs and tasks (§22) | Until deleted by hand | — | Operating the business | The stored summary, the metrics behind it, and the question an operator typed |
| 14 | Email in GairCor's mailboxes | Until deleted by hand | — | Correspondence record | Everything, including attachments |
| 15 | Your consent choice | In your browser until you clear your site data | Your choice | Honoring your choice | Nothing on our side — it is never sent to us |
| 16 | Copies held by our providers — hosting and edge logs, database backups, provider-side archives | Each provider's own schedule, outside our control | — | — | We have not established how long any of them survives, and we do not represent that we have |
10.3 What survives a deletion request, definitively. If you ask us to delete your records and we agree to, the following will still exist afterwards. We list them because a promise of erasure that ignored them would be false:
- Analytics records at our provider, unless separately removed there — including the derived location values, and any session recording still inside its 30 days.
- Our own copy of analytics records, until its 90 days elapse.
- Aggregate daily counts, which contain no identifier and are not reconstructible into one, and which we do not delete.
- App Hub download audit records, including the hashed address value, unless we remove them by hand.
- Stripe payload copies, including an unattributed record carrying a name and email address, unless we remove them by hand.
- Bookings held by the scheduling service, which we cannot delete on your behalf.
- Email, in both directions, in ordinary mailboxes.
- Provider-side backups and edge logs, on their own schedules, outside our control.
10.4 Legal hold. Where we know or reasonably believe a record is relevant to a claim, a dispute, an investigation or a regulatory enquiry, we retain it until the matter is resolved, regardless of anything above. In our systems a hold is a decision by a person not to perform a removal, not an automatic mechanism.
11. Security
In short: real controls, described accurately, without promising that nothing can go wrong.
11.1 We do not warrant invulnerability. No system is perfectly secure and we do not represent that ours is. What follows describes the controls actually in place as at September 12, 2026. It is not a guarantee and nothing in this section creates a warranty.
11.2 Access control lives in the database. Permission to read a record is decided by rules held in the database and applied to every query, rather than by the screens a person is shown. The public-facing tables accept an insert from the Site and nothing else; reading them requires a privileged server-side credential that never reaches your browser.
11.3 Transport and storage. Traffic to and from the Site is encrypted in transit. Files and database contents are encrypted at rest by our platform provider. Downloads taken through the App Hub application are served through links that expire after 300 seconds, and such a link is not tied to the person who requested it — anyone holding it can use it until it expires, which is why one should not be forwarded. Downloads offered from this website are ordinary, non-expiring links and carry none of that protection; §2.6 says so plainly rather than letting this section imply otherwise.
11.4 Payment integrity. Every event our payment processor sends is verified against its cryptographic signature before it is acted on, and recorded idempotently, so a replayed or forged delivery does not create a record or a state change.
11.5 The internal portal. GairCor's operations portal sits behind a network gate operated by our hosting provider and, separately, behind a sign-in on a staff account. Two independent gates, not one.
11.6 Form protection, and the failure mode you should know about. The contact form carries a hidden field that a human never sees and a machine tends to fill in. If it comes back filled, the submission is silently discarded and the page reports success. This is deliberate — telling a spam robot it failed teaches it to try again — but it has a consequence for you: a legitimate submission can be thrown away while the page tells you it was sent. A password manager filling a field it should not is the realistic case. If you send us something that matters and hear nothing, write to legal@gaircor.com. The rate limit described at §5.3 can reject a genuine submission for the same reason, and it is per-server-instance and in memory, which makes it a spam control rather than a security boundary.
11.7 What we do not claim. We do not operate a formal security certification. We do not claim an audited control framework. We do not run automated deletion outside the three jobs at §10.1. Where a control is not in place, this policy says so rather than describing the category it would belong to.
11.8 Your part. Where you hold an account, keep the password to yourself and write to privacy@gaircor.com at once if you think someone else has reached it.
12. Your choices and requests
In short: ask us for a copy, a correction or a deletion, and we will honor it where we can reach the record. We say plainly where we cannot.
12.1 What we offer, and on what footing. GairCor is a small business. We sell no personal information, and the volume we handle is far below the thresholds at which the comprehensive state privacy statutes we have reviewed begin to apply — thresholds measured by annual revenue, by the number of consumers whose data is processed, and by revenue from selling personal information. We do not hold ourselves out as a business regulated under any of them, and we reassess that as the business grows.
The choices in §12.2 are therefore offered voluntarily. They are a commitment we make as a matter of practice, to everyone who asks, regardless of where they live. Being voluntary makes them no less binding on us once published. Where the law of your own jurisdiction gives you a right described here, that law governs and nothing in this section narrows it.
12.2 What you can ask for.
- Access — a copy of the Personal Information we hold about you.
- Correction — of information that is wrong.
- Deletion — subject to §12.5.
- A portable copy — what you gave us, in a common file format.
- To withdraw analytics consent — the Cookie settings link in the footer, at any time, with no request to us required. This is the fastest control in this policy and it is entirely yours.
- To stop being contacted — tell us and we will stop.
12.3 How to ask. Email privacy@gaircor.com with the words "privacy request" and tell us what you want. There is no form and no account is required. Written notices may also be sent to 609 Metairie Rd #8259, Metairie, LA 70005.
12.4 How we verify you. We match what you tell us against what we hold, and we may ask for one further piece of information already in our records — the address or phone number used on an enquiry, or its approximate date. We will not demand a government identification document to answer a request about a web enquiry, and we will not require you to create an account. An authorized agent may act for you with your written permission, which we may confirm with you directly.
12.5 What we can and cannot do about deletion — read this before asking.
- We can delete a contact enquiry, a booking row in our own database, an account and its profile, an App Hub download audit record, a stored Stripe payload copy, an unattributed Stripe record, and an internal AI output — each by hand, and we will confirm what actually went rather than repeating what a screen told us.
- We can ask our analytics provider to delete the records associated with your device identifier, where you can give us enough to find them. In practice that usually means the identifier itself, which is in your own browser's storage.
- We cannot reach a session recording before its 30 days elapse other than through that provider's own controls; the period is enforced by them, not by us.
- We cannot remove an aggregate daily count. It holds no identifier, it is not reconstructible into one, and deleting it would falsify a business record.
- We cannot delete what the scheduling service holds about your booking. That is a request to make to it.
- We cannot delete what our payment processor holds. Its own records are governed by its policy and by financial recordkeeping law.
- We cannot reach our providers' backups or our host's edge logs, which follow their own schedules.
- We cannot delete an email you sent to a third party, or a copy of a message sitting in someone else's mailbox.
Where we cannot fully honor a deletion request, we will tell you specifically what we removed, what we retained and why, rather than reporting a deletion that did not happen. A write that changes nothing is not a deletion, and we will not report one as though it were.
12.6 Timing. We acknowledge a request within ten business days and respond substantively within forty-five days, telling you before that if we need longer and why. We choose these because a business this size can meet them in a bad month, not only a good one.
12.7 What it costs. Nothing, for a reasonable request. We may decline or charge for one that is repetitive or clearly excessive, and we will say which and why.
12.8 No retaliation. We will not refuse service, charge a different price, or provide a different quality of service because you exercised any of these choices, declined analytics, or asked us to delete something.
12.9 A limit worth stating. There is no screen anywhere on this Site through which you can read back, correct or delete what you sent us. Every request under this section is answered by a person, by hand, from the routes at §12.3.
13. Children
In short: this site is not for children and we do not knowingly collect their information.
13.1 The Site is directed to adults and to businesses evaluating software. It is not directed to children, and we do not knowingly collect Personal Information from a child under 13. Unless a specific product states otherwise, our services are intended for people at least 18 years old and able to enter a binding agreement.
13.2 If we learn we have collected information from a child under 13, we delete it, subject only to the limits at §12.5.
13.3 A parent or guardian who believes a child has given us information may email privacy@gaircor.com, and we will act on it without requiring the child to be identified further than necessary.
13.4 We do not knowingly sell or share the Personal Information of anyone under 16 — we do not sell or share anyone's, of any age (§18).
14. Do Not Track and Global Privacy Control
In short: we install no cross-site advertising technology, and our own analytics have a switch you can use directly.
14.1 How we respond. Some browsers send a Do Not Track header or a Global Privacy Control signal. GairCor does not currently detect or act on either signal, and we say so rather than claim to "honor" one, because a claim to honor implies a mechanism that would have to exist and be tested. What exists instead is the Cookie settings link in the footer, which opts you out of analytics and heatmaps together, immediately and without a request to us.
14.2 What a signal would be switching off, if we acted on one. Not advertising — there is none. We install no advertising technology, no cross-site tracking pixel, no tag manager and no attribution service on this Site, and we receive nothing about you from any such service. What we do install is the analytics described at §2.1 to §2.3, which is first-party product analytics and heatmaps. It is not cross-site tracking; it is nonetheless substantial, and §2.3 describes it fully rather than hiding behind the distinction.
14.3 The one outside service your browser contacts. The scheduling embed at §3.3, on the scheduling page only. We do not operate it, we do not choose it in order to track anyone, and nothing it collects is reported to us — but we will not represent that it does not set cookies of its own or recognize you elsewhere, because that is not ours to say.
14.4 If this changes. If we ever enable a service that engages in cross-site collection, or begin acting on a browser signal, we will update this section, and §17 governs how you are told.
15. Where we operate
In short: a United States business, storing and processing information in the United States, reachable from anywhere.
15.1 Our market. GairCor is a Louisiana business serving customers principally in the United States. Our services are offered in English and priced in United States dollars. Information described in this policy is stored and processed in the United States, including by our analytics provider.
15.2 Visitors from the EU, the EEA and the United Kingdom. The Site is reachable from those places and we do not block it. We treat visitors there as requiring prior consent for analytics and heatmaps, which is why the banner exists and why nothing is captured until it is accepted (§2.1). We have not appointed an Article 27 representative and we do not hold ourselves out as established in those markets. Where the GDPR or the UK GDPR does apply to a particular processing operation, we rely on your consent for analytics and heatmaps; on performance of a contract or steps taken at your request for answering an enquiry and operating an account; on our legitimate interests in operating and securing the Site for the spam controls at §5.3 and §11.6; and on a legal obligation where one applies. Where consent is the basis, you may withdraw it at any time through the footer link, and withdrawal does not affect what was lawfully collected before it.
15.3 Transfers. Where information reaches the United States from elsewhere, it does so because you chose to use a United States service. Where a transfer mechanism is required for a particular operation, we will identify it here before relying on it rather than reciting a list of mechanisms we have not put in place.
15.4 Other states. The Site is reachable throughout the United States. Where the law of your state gives you privacy rights, we honor verified requests under §12 without claiming to be a business regulated by that state's statute.
16. If there is a data breach
In short: we investigate, we tell the people affected, and we do not wait to be asked.
16.1 Our commitment. If we determine that Personal Information has been, or is reasonably believed to have been, obtained by an unauthorized person, we will investigate promptly and notify each affected person without unreasonable delay, and in any event no later than 60 days after we discover the breach — unless, after a reasonable investigation, we determine there is no reasonable likelihood that the incident has resulted or will result in harm to the people whose information was involved. Where we reach that conclusion, we record it in writing with the material supporting it, keep that record for as long as the law requires, and produce it to a state Attorney General on request. Louisiana's breach-notification law provides that exception; we will not use it to avoid telling you about something that could hurt you. Where the law of a state requires notice to its Attorney General or another authority, or requires a shorter period, we will meet it.
16.2 What the notice will say. What happened, when, what categories of information were involved, what we have done, what we recommend you do, and how to reach us.
16.3 Standing security duty. Independently of any breach, we maintain security procedures and practices appropriate to the nature of the information we hold, as Louisiana law requires. §11 describes them, including what is not in place.
16.4 A note on ordering. Where an incident involves a service provider, we may be required to notify that provider before making a public statement. That does not delay notice to you beyond the periods above.
17. Changes to this policy
In short: a real version number and a real date, both set by hand.
17.1 Version and date. This policy carries a version number and an effective date at the top. Both are set by hand when the text changes. The date shown is not computed when the page is served and it does not advance on its own — a policy whose date moved every request could not say what was in force on any given day. The Terms of Use carry their own version and date, and the two documents are revised together where they touch the same subject.
17.2 Non-material changes. Corrections of typography, formatting and cross-references may be made without notice, and the version number is incremented.
17.3 Material changes. A material change is one that expands what we collect, adds a purpose, adds a category of recipient, shortens a protection, or narrows a choice available to you. For a material change we will publish the revised policy with a new version and effective date not less than 30 days before it takes effect, and will post a notice on the Site. A material change does not apply retroactively to information already collected under an earlier version, except where you agree or the law requires it.
17.4 New practices require a new disclosure first. Where we intend to use information for a purpose this policy does not describe, we will update this policy before we do so, and where consent is required we will ask for it before, not after. This applies in particular to anything described here as not currently in use: marketing email (§6.2), meeting recording (§7.2), the booking function that nothing calls (§2.5), a download from this website ever requiring an account or writing a record (§2.6), error and exception capture (§2.1), surveys (§2.1), acting on a browser privacy signal (§14.1), and session replay, which was switched off on September 12, 2026 and will not be switched back on without an updated disclosure here first (§2.3).
17.5 Prior versions. We do not maintain a public archive of superseded versions. Ask us and we will tell you what this policy said on a given date so far as our records allow.
18. We do not sell or share personal information
In short: no sale, no sharing for advertising, no data brokers — and it is checkable against how the site is built.
18.1 The statement. We do not sell your Personal Information for money or for any other valuable consideration. We do not share it for cross-context behavioral advertising. We do not disclose it to a data broker, a lead aggregator or an advertising network. We receive no payment or other consideration from anyone for any disclosure described in §4.
18.2 We do not use it for advertising, credit decisions, or model training. We do not use Personal Information collected through this Site to serve advertisements, to retarget you, to determine anyone's creditworthiness, or to create, train or improve any artificial-intelligence or machine-learning model — ours or anyone else's. The internal AI use at §22 sends aggregate metrics to a provider under a commercial API and is not training.
18.3 Why this is straightforward for us to say. There is no advertising technology on this Site, no attribution service, no marketing platform holding a copy of anything, and no affiliate network. The disclosures we do make are the ones at §4: the businesses that operate parts of the service.
18.4 It is a statement about how we operate, and conditional on that remaining true. If it ever ceases to be true we will change it here before any such practice begins, under §17.4, and no such change would apply to information already collected without your agreement.
19. Fair housing, and related documents
In short: the fair-housing section of this format does not apply to GairCor, and the dispute-resolution mechanism lives in the Terms of Use, not here.
19.1 Fair housing does not apply to GairCor. GairCor Technologies is a software business. It is not a real estate brokerage, it holds no real estate license, and it does not advertise, sell, lease, broker, appraise or finance housing. The fair-housing obligations that attach to housing providers and housing advertisers do not attach to anything described in this policy. The section number is retained so the numbering of this document remains stable across versions and so its cross-references continue to resolve.
19.2 Equal treatment, stated anyway. GairCor does not discriminate on the basis of race, color, religion, sex, sexual orientation, gender identity, national origin, age, disability, veteran status, familial status, or any other characteristic protected by applicable law, in offering or providing its services. Nothing in this policy limits any right you have under federal or state anti-discrimination law.
19.3 Related documents. Our Terms of Use at /legal/terms govern your use of the Site. The Terms carry the operative dispute-resolution provision — binding individual arbitration, with the carve-outs stated there, under Louisiana law. It is the only dispute-resolution mechanism that applies, this policy does not create a second one, and nothing here should be read as offering an alternative route. Where this policy and the Terms address the same subject, this policy governs the handling of Personal Information and the Terms govern everything else.
20. Google user data
In short: does not apply. GairCor connects no Google account and receives no Google user data.
20.1 The position. GairCor requests no Google OAuth scopes, connects no Google account, and accesses no Google user data, either yours or its own. There is no Drive archive, no Calendar integration, no Contacts access, no Gmail access, and no Google sign-in anywhere in the systems covered by this policy. You are never asked to connect a Google account, and there is nothing to revoke.
20.2 Why this section exists at all. GairCor's internal operations portal previously used Google sign-in for staff. It no longer does — staff sign in with an email address and password held by our platform provider, behind the network gate at §11.5. No Google credential, token or profile is stored by any GairCor system as at September 12, 2026.
20.3 Nothing on this Site loads from Google. No Google Analytics, no Google Tag Manager, no reCAPTCHA, no AdSense, no Google Maps, no Google-hosted fonts (§3.5), and no Google advertising or measurement technology of any kind. Your browser makes no request to Google when it loads a page here.
20.4 If this changes. If GairCor ever connects a Google account or requests a Google scope, this section will describe exactly which scopes, what is stored, what is sent, how to revoke it, and the Limited Use commitments that attach — and it will do so before the feature is enabled, under §17.4.
21. How to reach us
In short: two addresses, a support telephone line, and a postal address, all answered by the same small team.
Privacy requests, questions and complaints: privacy@gaircor.com Legal notices: legal@gaircor.com Postal address: 609 Metairie Rd #8259, Metairie, LA 70005
Telephone: 800-380-7520, Monday to Friday, 9:00 a.m. to 6:00 p.m. Eastern, excluding U.S. federal holidays; voicemail outside those hours is returned in the next business day's queue. It is a support line. Privacy requests and legal notices should go to the addresses above, so that they are recorded and can be answered in writing — but if the telephone is the channel available to you, call it and say so, and we will route the request rather than turn you away. Nothing in this paragraph limits any method of service that law requires us to accept.
Copyright complaints are handled under the Terms of Use. GairCor has not registered a designated agent with the U.S. Copyright Office, so the statutory safe harbor for service providers is not available to us; we act on notices regardless, and the Terms describe how to send one.
If you are dissatisfied with our response, tell us — we would rather resolve it directly. You may also complain to the Attorney General of your state.
22. Artificial intelligence and automated processing
In short: an internal analysis tool that reads aggregate numbers, plus whatever a member of staff types into it. No decision about you is made by a machine.
22.1 Where AI is used. GairCor uses a commercial large-language-model API from OpenAI inside its internal operations portal, for three things: an internal question-and-answer tool used by staff, an hourly scan for anomalies in aggregate metrics, and a daily summary of those metrics. None of this is exposed on gaircor.com and none of it processes an enquiry, a booking or a visitor record as such.
22.2 What is actually sent. A snapshot of aggregate metric results — portfolio and per-application indicators over a period, and flagged anomalies — together with the question a staff member typed and a fixed instruction template. The system instruction tells the model to analyze only the supplied metrics and not to use or infer personal information. Individual enquiry, booking, account or payment records are not included in the request.
22.3 The honest caveat. A question a member of staff types is sent as written. If somebody typed your name or your email address into it, that text would be sent along with the metrics. We tell staff not to, the instruction template tells the model not to rely on it, and we would rather name the possibility than describe a control that cannot enforce itself.
22.4 What is stored. The model's output is stored in our internal database as a draft insight and, where it proposes one, an internal task — together with the metrics snapshot behind it and the question asked. These are covered by §10.2 row 13 and are not removed on any schedule.
22.5 No automated decisions about you. No decision that produces a legal or similarly significant effect on you is made by automated processing anywhere in the systems covered by this policy. There is no scoring of visitors, no automated approval or refusal, no profiling for advertising, and no algorithmic assessment of a person. The only automated rejections anywhere here are the spam controls at §5.3 and §11.6, which act on a request rather than on a person, and §11.6 tells you what to do if one catches you.
22.6 Not training data. Nothing described in this policy is used to create, train, fine-tune or improve an artificial-intelligence or machine-learning model. §18.2.
23. Defined terms
- Site — the website at gaircor.com, including the App Hub, product, services, docs, blog, contact, scheduling and legal pages hosted on it.
- App Hub — the catalog of GairCor applications published on the Site, some free and some paid. Downloads offered from the catalog pages on gaircor.com are plain links (§2.6).
- App Hub application — the separately installed GairCor application that signs a person in and requests a protected, short-lived download link. It is the only caller of the download flow described at §2.6, and it is not this website.
- Ops Portal — GairCor's internal operations portal. Internal tooling for staff only; not a service offered to anyone outside GairCor. §8.3.
- Personal Information — information that identifies, relates to, describes or could reasonably be linked, directly or indirectly, with a particular individual or household. It includes the information we generate about you (§2.9), the analytics device identifier, the hashed address value on an App Hub download record (§9.2.1), and the location values derived from your IP address (§2.2).
- Session recording / session replay — the reconstruction of a browsing session described at §2.3. Switched off on September 12, 2026. Recordings already made are held by our analytics provider for 30 days from the recording and then deleted.
- Heatmap — an aggregate map of where visitors clicked and how far they scrolled on a page. §2.3.5.
- Analytics device identifier — the randomly generated value our analytics library stores in your browser to group one visit's events together. Not derived from anything about you; still an identifier, and still Personal Information here. §3.2, §9.2.2.
- Consent choice — the single value written to your browser's local storage recording whether analytics are granted or denied. Never transmitted to us. §3.1.
- Consent-required region — the thirty countries listed at §2.1, plus any visit whose country cannot be determined.
- Hashed address value — the salted SHA-256 digest stored in place of an IP address on an App Hub download audit record. Pseudonymous, not anonymous. §9.2.1.
- Service provider — a business that processes Personal Information on GairCor's behalf and on its instructions, listed at §4.
- Aggregate daily counts — day-level totals and rates derived from analytics events, holding no identifier and not reconstructible into one. §10.2 row 5.
- Effective date — the date at the head of this document, set by hand when the text changes. §17.1.
