Privacy Policy

1 Scope

This policy explains how Labor Production Services, LLC ("LPS", "we") handles personal information in connection with the resourceboard.io website and the Resource Board software (together, the "Service").

It covers three different groups of people, and what we do differs meaningfully for each:

• Website visitors — anyone browsing the site or submitting an enquiry.
• Account holders — people who log in to Resource Board.
• Workforce members — employees whose records a customer enters into the Service, who may never interact with us directly.

2 The most important thing to understand

Where LPS decides how and why information is used — our website, our own account records, our billing — we are responsible for it, and this policy governs directly.

3 What we collect

From website visitors

If you submit the enquiry form, we receive the name, company, work email, and — if you provide them — phone number, approximate field headcount, and any message you write. Form submissions are captured by Netlify on our behalf.

We do not use advertising trackers or third-party analytics cookies on this site. Our hosting provider records standard server logs, including IP address, for security and operational purposes.

From account holders

Email address, display name, assigned role and permissions, and authentication records including sign-in timestamps. Passwords are managed by Google Firebase Authentication and are never visible to us.

We also keep a record of changes to an account: which administrator last changed its role or permissions and when, whether the account was migrated from an earlier version of the Service and when, whether it is flagged as an LPS internal account, and — where the Service asks account holders to accept its terms of use — which version of those terms was accepted and at what time. This exists so that a change to someone's access, or an agreement they entered into, can be accounted for afterwards. It is kept for as long as the account exists.

Workforce records entered by customers

Resource Board is built to manage field labor, so customers enter information about their people. Depending on how a customer configures it, this can include:

We do not require or request Social Security numbers, dates of birth, financial account details, health records, or any government identification, and customers should not enter them.

4 How information is used

• To operate the Service — authenticating users, displaying the board, generating reports, executing scheduled transfers.
• To support customers — responding to requests, diagnosing problems.
• To send notifications — where a customer enables them, by email and SMS, about assignments and schedule changes.
• To administer the business — invoicing, renewals, and account correspondence.
• To respond to enquiries — following up on the form on this website.

5 Service providers

We rely on a small number of vendors to run the Service. Each processes information only as needed to provide its function:

We may add or change providers as the Service develops, and will update this list.

Email sent by our scheduled processes comes from an address we control on our own domain — info@laborproductionservices.com — and replies are directed to the same address.

Backups are not held by a vendor. Full snapshots of the database are taken on a schedule and written to a private directory on a computer we control, with filesystem permissions restricting access to the operator account. They are not stored with a cloud provider, and they are not encrypted at rest. A snapshot contains everything in the database at the moment it was taken, including the workforce information described in Section 3.

The assistant features send board data to Anthropic. Several optional features — question answering, planning, schedule analysis, and timecard scanning — work by sending information to Anthropic's API. What is sent depends on the feature and includes employee names, roles, teams, skills, statuses, vacation dates, project assignments, staffing requests, and, for timecard scanning, the image file itself. These features run on an API key that the customer supplies and stores in their own browser, so the request is made under the customer's own account with Anthropic and is governed by the customer's agreement with them. We do not send anything to Anthropic without a customer-supplied key present. Customers who do not want board data leaving the Service should not enter a key.

6 Text messages

The Service is built to send SMS notifications, and will do so once carrier registration is complete and a customer enables the feature. No messages have been sent to any workforce member to date. When SMS is enabled, messages relate to work assignments, transfers, and schedule changes, and are delivered through Twilio, our messaging processor, which receives the recipient's phone number and the message content and is listed as a sub-processor in Section 5. Message frequency varies with activity — typically a few messages per worker per month, concentrated around assignment changes. Message and data rates may apply.

How consent is obtained

No SMS is sent to anyone without consent recorded against that person first. This is enforced by the software, not by policy: the check runs on our servers inside the only code path that can reach Twilio, so a message to a number with no recorded consent is refused and never sent. There is no way to send a message from the Service that bypasses it.

Consent is obtained by the employer, not by LPS. The employing contractor asks the worker in person — during onboarding or at the jobsite — whether they agree to receive text messages about their work assignments. In-person verbal consent is the only method the Service supports: there is no web form, no keyword opt-in, and no bulk enrolment.

The contractor records that answer against the employee's record, and the Service stores who recorded it, the date, and that the method was employer attestation. The default state is that nobody has been asked, and no message is sent to a person in that state. Where a person has not been asked, their record displays that SMS will not reach them, and the person scheduling the work is told that no text was sent and why.

Stopping messages

Reply STOP to any message to opt out, or HELP for assistance. STOP, STOPALL, UNSUBSCRIBE, CANCEL, END and QUIT are all honoured. An opt-out is recorded against the phone number and suppresses every future message to it; it takes precedence over the employer's attestation, so an employer cannot restart messages by re-recording consent. Only the recipient can, by replying START. Opting out ends messages from the Service but does not remove the person's record from their employer's board. Carriers are not liable for delayed or undelivered messages.

Text messaging data is never shared for marketing

No mobile information — phone numbers, opt-in records, or consent data — is sold, rented, or shared with third parties or affiliates for marketing or promotional purposes. Phone numbers and message content are disclosed only to Twilio, our messaging provider, and onward to the recipient's mobile carrier, for the sole purpose of delivering the message described above. Text-messaging originator opt-in data and consent are excluded from every other category of sharing described in this policy.

7 Retention

• Customer data is retained for as long as the customer's subscription is active. We do not delete it automatically when an agreement ends.
• At the end of an agreement. On written request we will provide the customer with a complete export of their data and then permanently delete it, both within thirty (30) days of the request. The export is a single file covering the customer's entire record — including the restricted and classification data that the in-application backup does not cover. Deletion removes the customer's board, its user accounts and memberships, the address-to-account lookup for those users, and the entries identifying that customer in our scheduled-process logs.
• Backups. Snapshots are taken on an hourly schedule when the database has changed, and the fourteen most recent are kept — in practice a window of two to three weeks. Older snapshots are deleted automatically. Because a snapshot is a copy of the whole database, data deleted from the Service continues to exist in any snapshot taken before the deletion, until that snapshot rotates out. Snapshots retained outside that rotation for migration purposes are deleted at the same time as the active data.
• Staffing requests that have been fulfilled or voided are deleted from the database automatically twenty-one (21) days afterwards.
• Classification records described in Section 9b are never deleted while the customer's data is retained, and are removed when it is.
• Enquiry form submissions are held by Netlify and deleted on request. We do not operate an automatic expiry for them.
• Business records such as invoices are retained as long as required for tax and legal purposes.

8 Your rights and requests

If you are an employee in a customer's board

Contact your employer. They control what is recorded about you, they can correct or remove it, and they are the party that decides retention. If you contact us directly, we will refer you to your employer and, where we can identify the relevant customer, let them know you asked.

If you are a customer or account holder

You can access and correct your data directly within the Service, and account holders with backup permission can export the contents of a region as a file at any time. Deleting an employee record removes it from the database immediately. It does not remove the classification records described in Section 9b, notes written about that person elsewhere in the Service, or scheduling history — those are removed only when the customer's data as a whole is deleted, as described in Section 7. For anything you cannot do within the Service, write to us; we will respond within thirty (30) days.

If you submitted the enquiry form

Write to us and we will delete your submission.

Depending on where you live, you may have additional rights under state privacy law. We will honor applicable rights and will not discriminate against anyone for exercising them.

9 Security

Access to the Service requires authentication. Data is encrypted in transit, and our database and hosting providers state that they also encrypt it at rest. The database backups described in Section 7 are an exception: they are protected by filesystem permissions on a machine we control, and are not encrypted. Some permissions are enforced at the database level rather than only in the interface — in particular, the ability to change records is restricted by role and that restriction is enforced by the database, not by the screen.

Read access is broader than write access, and we would rather say so than imply otherwise. A person signed in to a customer’s board can generally read the workforce and project records for the regions they are assigned to, including records the interface does not display to them. Customers should treat anything entered into the Service as visible to their own staff who use it.

No system is perfectly secure. We do not claim the Service is immune to compromise. If we discover a breach affecting personal information, we will notify affected customers within thirty (30) days of discovery, and will cooperate with them in meeting their own notification obligations — the employer, not LPS, holds the direct relationship with the people whose records are in a board.

9a What the database enforces, and what it does not

This section separates two things that are easy to conflate. Some limits are enforced by the database itself and hold regardless of what the interface shows. Others are choices the interface makes, which a determined person with a valid login could work around. We describe them separately because presenting the second as the first would overstate the protection.

Enforced by the database

• Procurement records — the Long Lead Tracker — are administrator-only, for reading as well as writing. Vendor names, vendor contact details, lead times and the procurement history of an item are not readable by ordinary users of a customer's board, including supervisors and field staff.
• Where the Service records an internal classification of a person, that record cannot be edited or deleted by anyone using the Service, including administrators. Entries are add-only.
• Only an administrator can add such an entry, and the entry must identify the administrator making it. A person cannot record an entry in someone else's name, and cannot backdate one.
• Changing records — as opposed to reading them — is restricted by role at the database level.

Not enforced by the database

• Free-text notes recorded against a project or a scheduled task are written only by administrators — no foreman, manager or viewer can create one — and are readable by everyone signed in to that customer's board, including field staff. They are shown in the interface, not merely reachable in the database. This is deliberate: notes explain why a task moved, and the people doing the work are the people who need to know. It also means a note is visible to staff on other projects, and we have no way today to limit a note to one project's participants. Customers should not record anything about an individual in a project note.
• Workforce records are readable by any user assigned to the region they belong to. The interface shows a person only what is relevant to their role; the database permits more. Customers should treat anything entered about an employee as visible to their own staff who use the Service.

We would rather a customer know the second list exists than discover it. We are narrowing it, and this policy will be updated as items move from the second list to the first — not before.

9b Records about a person that the Service keeps permanently

Where an administrator records an internal classification of an employee — for example marking someone as not eligible for reassignment — the Service records who made the change, when, and the reason they gave. A reason is required to apply such a classification. Removing the classification is also recorded, and does not erase the original entry.

These entries cannot be edited or deleted from within the Service by anyone, and they are not removed when the classification is lifted. They are deleted only when the customer's data is deleted, as described in Retention.

Administrators should assume the reason they enter will be read later — by their own organisation, by us if we are asked to investigate, and potentially by the person concerned.

9c Employees whose records are held here

The people described in this Service are usually not the people who agreed to it. Our customer is the employer. The individuals whose names, contact details, availability and internal classifications are recorded are that employer's workforce, and most of them have no account and may not know the Service exists.

We act on the employer's instructions in respect of those records. We do not have a direct relationship with the individuals concerned, and the rights described in Section 8 are exercised through the employer, not through us. If you are an employee of one of our customers and want to know what is recorded about you, to correct it, or to contest an internal classification, that request goes to your employer. We will support them in answering it, and we will tell you to contact them if you approach us directly.

We say this plainly because an employee has no practical way of knowing otherwise, and because a classification recorded here can be consequential.

10 Children

The Service is a workplace tool and is not directed to children. We do not knowingly collect information from anyone under 16. Customers should not enter records for anyone under the minimum legal working age in their jurisdiction.

11 Changes to this policy

We may update this policy as the Service develops. The effective date at the top will change. Material changes affecting customers will be notified by email to the account contact. Continued use after a change takes effect constitutes acceptance.

12 Contact

Questions, requests, or complaints about privacy:

Labor Production Services, LLC
info@laborproductionservices.com