How can we help?

Progress Lab delivers guidance from AI experts & a mission-aligned AI platform that enables progressive groups to use pre-built workflow tools and collaborate to create customized AI solutions within a robust security and transparency framework. The Progress Lab was founded a progressive operator and AI executive who know the work and technology and an AI scientist with over 15 years of experience building products for academic researcher and Fortune 500 companies.

It's for the people who actually run campaigns and nonprofit programs: finance and development directors, communications staff, data and ops leads, organizers and campaign managers. Our platform is built for the people doing the work to make their communities stronger and who want to use AI in ways that are consistent with their values.

The Progress Lab is invite-only, so there's no public sign-up page. A workspace admin adds you by email, and you get an invitation with a temporary password. If you are an admin and would like more information email hello@progresslab.ai.

Once you recieve an email with an invitation link, you sign in with that temporary password, set your own, enroll in two-factor authentication, and accept the terms of use and privacy poliy.

If you're not sure who your admin is, it's usually whoever set up your organization's workspace. If the invitation never shows up, check your spam folder first, then ask them to send it again.

You'll set it up the first time you sign in, and use it at each login. Two-factor is required on every account, to enhance security for your organization.

You'll need an authenticator app on your phone. Any standard one works, including whichever your organization already uses (examples include Google Authenticator or Microsoft Authenticator).

1. Sign in with your email and temporary password.
2. Scan the QR code with your authenticator app.
3. Check that the app lists the account as ProgressLab — that's the right entry.
4. Type the six-digit code the app shows to confirm.

After that, every sign-in asks for a fresh code.

Two things worth doing right now. If your authenticator app offers backup or sync across devices, turn it on. And know that there's no self-service reset: if you lose the app, a workspace admin has to reset two-factor on your account before you can get back in.

If a code gets rejected, the cause is almost always your phone's clock. The codes are time-based, so a phone that's a minute off produces codes the sign-in screen won't accept. Turn on automatic date and time and try the next code.

What it means: Your six-digit codes lived only on that device, and there's no self-service reset. Until two-factor is set up again on a device you have, you can't sign in.

What to do: Ask a workspace admin to reset two-factor on your account. Tell them the email address on the account and that you've lost your authenticator app. Once they've reset it, your next sign-in walks you through enrolling the new phone.

If it keeps happening: Turn on your authenticator app's backup, or move to one that syncs across your devices, so the next new phone doesn't lock you out.

What it means: Passwords can't be looked up or recovered by anyone, including support, so the fix is always to set a new one.

What to do: Start a password reset from the sign-in screen and follow the email that arrives. If nothing shows up, check your spam folder, then ask a workspace admin to reset your account. Either way you'll still need a current code from your authenticator app afterwards, because two-factor is separate from your password.

If it keeps happening: Store the password in a password manager. And note that a rejected six-digit code is a two-factor problem, not a password problem.

The first time you sign in, a full-screen page asks you to accept the Terms of Use and the Privacy Policy before you can go any further. You have to open both documents and check both boxes. Until you do, you can't continue. That's because we want you to understand what The Progress Lab will and will not do with your data. We're proud of our policies and our team is happy to answer any questions you might have before signing.

It isn't only a first-day step. When either document is updated, the same page appears at your next sign-in so you can review the new version and accept it. Nothing else in the app is reachable until that's done, so it's worth taking the two minutes to read what changed.

Four tabs, four jobs.

• Chat is where you ask questions and get help working faster and smarter. The platform can search the web, read the documents in your project, explore and ask questions about your database, build spreadsheets, draft reports, and run plugin skills like donor research or a daily briefing. Factual answers come with a list of sources.
• Compose is where you bring data in. Upload a spreadsheet or pull a file from Google Drive, and it gets matched against what you already have, so the same person across four different lists ends up as one individual instead of four.
• Data is where you view your database records. Search by name, email, phone, or city and get contact details, giving history, districts, and the source of every field. It covers your imported records plus public campaign-finance data.
• Reports is where you create, save and automate reports that keep you informed. You describe what you want in plain language, publish it, and it re-runs on its own schedule and keeps its history.

A rough rule for where to go: for workflows are to explore start with Chat, to onboard new data choose Compose, to look for a specific record click Data, and to create a chart, graph or table to answer a question select Reports.

To sign out, open the avatar menu at the right end of the topbar and choose Sign out.

Sign-ins expire after a stretch of 15 minutes of inactivity, and when that happens you'll see "Your session has expired — please sign in again." That's working as intended: an unattended laptop with your data open is a real risk, so we don't leave you signed in indefinitely.

Sign back in with your password and a fresh code from your authenticator app, and you'll pick up where you left off.

ProgressLab is built for a desktop browser. Use a current version of Chrome, Safari, or Edge, and keep the window reasonably wide. Below about 900 pixels the four tab labels collapse to icons, and work like reviewing an import or building a report gets cramped.

It will load on a phone, and reading a conversation or checking a report is fine there. Anything involving files, tables, or side-by-side review is much easier on a laptop. If you're heading into call time or a data cleanup, do it on a desktop.

It can help you research, summarize documents and data files, look things up on the internet, build files for you and help you complete complex workflows, all inside one conversation. Some of the tools the platform uses to help you complete tasks:

• Web Search. Search current information from outside the platform.
• Project Document Context It reads the files attached to the project you're working inside and uses them to inform task execution.
• Database Access It can reference imported records plus has access to public campaign-finance data.
• Spreadsheet Creation Ask for a list and you get a file you can download.
• Report Creation Describe what you want tracked and it drafts the report that you can save and rerun in the Reports tab.
• Plugin Skills Pre-built workflows to help with common tasks like donor research, call-time prep, schedule optimization, briefings, communications.

You don't need to select a tool and there's no syntax to learn. Ask in plain language, and it decides what to use and shows you what it's using while it works.

Good questions are specific and say what the answer is for: "Pull every donor in Dane County who gave over $1,000 in 2024 and put it in a spreadsheet for call time." That single question touches the database, the matching behind it, and a file at the end.

Machines make mistakes (just like we do sometimes!) so it is important for humans to verfiy critical information. Some examples include:

• Double-checking numbers headed for a filing, a press release, a grant report, or a board deck. Check them against the source. Every answer shows where its figures came from, so this is a two-minute job, not an afternoon.
• Donation totals that don't match your other tools. Usually an explainable difference rather than an error.
• Matching people. Our entity resolution is industry leading, but not perfect. Two records for the same person can stay separate. Our team can help you create measurements to ensure these tools are working properly with you data.
• Anything outside the app. It won't send email, post anything, move money, or write to your CRM. It drafts; you send.
• Memory. It doesn't know what you discussed in a different conversation, and it can't see documents from a project you aren't inside.
• Election information. It's restricted to four approved sources, so it will sometimes say it can't confirm something rather than guess. The tool gets you to a draft fast. Your judgment is what ships, and that's the design, not a gap we're papering over.

The platform names it for you, based on your first question and its answer. The title appears in the left sidebar once that first exchange finishes, so a brand-new conversation may sit untitled for a few seconds. Titles exist to help you find things later, not to be precise. One habit keeps them useful: start a new conversation when you switch topics rather than changing subject halfway through an old one. A conversation covering three unrelated things ends up titled after the first.

Open the left sidebar on Chat. Every conversation you've had is listed there, grouped by the project it belongs to, and anything you started outside a project sits in its own group. Click one to reopen it with its full history intact. If you can't spot it, check the other project groups first. It's easy to start a conversation inside one project and go looking for it in another. Conversations you've deleted are not displayed.

It's doing the research before it starts writing. When a question needs a web search, a pass through your project documents, or a database query, the platform runs all of that first and then writes one answer built on what it found. Roughly 15 seconds of Thinking is normal on a research-heavy question, and simple questions come back much faster. The cards that appear while you wait tell you which tool it's on, so the pause isn't a black box.

Those are tool activity cards, one for each thing the platform does before it writes. You'll see a card when it searches the web, reads a document from your project, queries the people and donor database, builds a spreadsheet, drafts a report, or runs a plugin skill. They appear in the order the work happens, and they stay in the conversation afterwards, so you can look back later and see how an answer was put together. There's nothing to click. They're a running account of the work, not a prompt for you.

Every factual answer ends with a Sources list, and for election information that list can only contain four sites. The platform is restricted to Vote411.org, Ballotpedia.org, VoteSmart.org, and FEC.gov for anything about candidates, races, ballots, or election administration. That isn't a preference it can be talked out of. If those four don't have it, it will tell you it can't confirm the answer rather than fill the gap from somewhere less reliable.

For everything else, sources come from wherever the answer came from:

• Web search results, listed with their links.
• Documents in the project you're working in, named by file.
• Records in the people and donor database, which trace back to the specific source file and row they were imported from (E-05).

Two reasons this matters. You can check any number before it goes into a filing or a memo. And when a funder, a reporter, or your board asks where a figure came from, you have an answer that doesn't rest on trusting the software.

If an answer arrives without sources, treat it as the platform's own reasoning rather than research, and ask it to check.

Use the stop button while a response is in progress. The platform stops where it is and keeps the partial text in the conversation, so you don't lose what it had already written. That's useful when you can see an answer heading the wrong way: stop it, then send a short correction instead of waiting out a long response you don't want. Work it finished before you stopped, like a spreadsheet it had already built, stays with the conversation. There's no cleanup needed. Just ask your next question.

Ask for a spreadsheet and you get one, as a download card right in the conversation next to the answer. Click it to download the file to your computer, or choose Save to Drive to put it in Google Drive if you've connected Drive.

A few practical notes:

• The card stays in the conversation, so you can come back tomorrow and download it again.
• Where the file belongs depends on where you were. Inside a project, it's the project's file. Outside one, it's yours personally (C-07).
• Save to Drive only appears when Drive is connected. If the connection has lapsed you'll see "We couldn't find that — it may have been moved or removed" (K-12).

One habit worth keeping: open the file before you send it anywhere. It's built from a query the platform wrote based on how you asked, so a date range that's a year off or a filter that's too narrow shows up as a shorter list, not as an error. Skim the row count and a few rows and you'll catch it.

Yes. Use the export option in the conversation header and you get the whole exchange, your questions and the platform's answers together, as one PDF. It's the simplest way to hand a piece of research to someone who doesn't have an account, or to keep a record of how a number was arrived at before it went into a filing. Reports export separately, to PDF or CSV , and spreadsheets the platform built for you download as their own files. If you need help from our support team, they may ask you to save your conversation as a PDF and email it to us.

Start with a middle sized model like Claude Sonnet or OpenAI GPT 120B. They are workhorses that can handle most tasks, like setting up a Plugin for the first time. For simpler or more repetitive tasks, like doing a simple web search or organizing messy data into a table, try a smaller model like Claude Haiku. Every model in the picker shows an energy score and a safety and bias grade, drawn from peer-reviewed research with published methodology. That's deliberate. You aren't locked into one vendor, and you shouldn't have to choose blind between a lighter model and a stronger one. The trade-off is in front of you, and you can lean on our team to help answer questions you have along the way.

Because the conversation's memory lives in the region that's handling it. Every conversation runs in one of two US regions, Virginia (US East) or Oregon (US West), and once you send your first message that conversation stays put.

Everything the platform knows about your exchange so far is held in that region. Moving the conversation mid-stream would mean leaving its context behind, and an platform that's forgotten the first half of your conversation is worse than one that stayed where it started. So the region fixes itself at your first message.

If you picked wrong, start a new conversation and choose the other region. Nothing is lost. The old conversation stays where it is and stays readable.

Within one conversation, yes, completely. It has the whole thread and you can refer back to anything in it without repeating yourself. Across conversations, much less. Treat a new conversation as starting fresh.

That's what projects are for. A project holds documents, and the platform reads every document in the project you're working inside. Your case statement, your program list, your finance plan, your compliance rules are then present in every conversation in that project without you pasting anything in. Plugins go a step further: each keeps a project profile with your campaign's settings, and every skill reads it before it runs, so a donor brief in March uses the same targets as one in July.

The practical version:

• One-off context. Say it in the conversation.
• Context you'll need repeatedly. Add it to the project as a document.
• Settings a plugin needs. Run the plugin's setup once. It writes the profile and working skills read it.

If an answer feels like it forgot something, check which project you're in first. Documents in another project aren't visible from here.

A project is a container for one campaign, race, or program.

Make a project when the work has its own facts and its own files. One per race, one per ballot measure, one per program or cycle. Don't make one per week or per meeting. A project you'll open twice adds something to navigate without adding context.

Everything inside a project stays together, which cuts both ways: deleting a project archives every conversation in it.

Open the project and add the files to it, either by dragging them in or by browsing and picking them. Each file can be up to 20MB.

The platform can read CSV, DOC, TXT, JSON, PDF and XLSX documents. Once a file is in the project, every conversation inside that project can use it, and conversations outside it can't.

If a file is larger than 20MB, split it into smaller ones. If it's a data export you want searchable across people rather than readable in one conversation, bring it in through Compose instead.

For documents you add to a project, the platform reads CSV, DOC, TXT, JSON, PDF and XLSX.

Compose accepts: CSV, XLSX, PDF, and DOCX. Compose can also make direct connections to data sources via API.

The short version of the difference: project documents are things you want the platform to read alongside a conversation. Compose is for data you want matched to people and made searchable across the workspace.

Open the project the documents live in and ask in plain language. The platform reads the project's files as part of answering, so "what's the total in this donor list" or "summarize the memo I added" works without you pointing at a specific file.

The one rule worth memorizing: the platform only sees a project's documents while you're inside that project. A conversation started outside it, or in a different project, can't reach them. If an answer looks like it's ignoring your file, check which project you're in. That's usually the whole problem.

Things that help:

• Name the file if the project holds several and you want one in particular.
• Ask for numbers as a table or a spreadsheet if you'll need to work with them afterwards.
• Check anything before it goes into a filing or a press release. The platform is good, not infallible, and a messy spreadsheet is exactly where it can slip.

For a file you only need once, attach it to that single conversation instead. For data you want to search across people, use Compose.

Open the project, find the file in the project's file list, and delete it there. It's gone from the project right away, and the platform can't read it in any new conversation after that.

Conversations that already used the file keep their text. An answer that quoted or summarized the document stays exactly as it is, because it's saved as part of the conversation. What changes is that the platform can no longer go back to the file for anything new.

If you're replacing a file rather than removing it, add the new version first, then delete the old one so the platform doesn't read both.

Three levels, largest to smallest.

• Workspace is your organization. Everyone signs in to it, it holds the data you import, and it's where members get invited, roles get set, and usage limits live. Most people belong to exactly one.
• Team is a group of people inside the workspace, with a name and a color. Teams are how admins organize who's who, and plugins can be set up differently per team, so the comms team's settings don't have to match the finance team's. You can belong to more than one team.
• Project is a body of work: one race, one program, one ballot measure. It holds conversations, documents, and each plugin's settings for that work. Projects belong to a single person.

If you want a picture for it: the workspace is the building, teams are the departments, projects are the files on your desk.

The practical difference is reach. Data brought in through Compose belongs to the workspace, so it's searchable from anywhere in it. Documents belong to a project and are only visible while you're inside that project. Who can see which projects and conversations is a workspace-level setting, set by your admin.

Compose takes the messy lists you already have and turns them into one clean set of people. You give it a CRM export, a spreadsheet a board member emailed you, a PDF of event attendees, and it reads each one, works out what every column holds, and finds the places where the same person shows up more than once.

That last part is the hard part. Margaret A. Chen in your CRM. Maggie Chen in the fundraising spreadsheet. M. Chen at an old address in the event list. mchen@ in the volunteer sign-up. Four rows in four systems, one actual person. Sorting that out by hand is the work that quietly eats a staffer's week every cycle, and it's the work Compose is built to take off your desk. You don't need to standardize your headers, remove duplicates, or fix formatting first.

Compose accepts CSV, XLSX, PDF, and DOCX. You can upload a file directly, pull one in from Google Drive, or bring it from a connected source.

Spreadsheets give the cleanest results. A good file has:

• One row per person
• A single header row at the very top, with no title or logo rows above it
• Real column names, however odd. Compose recognizes more than 50 kinds of field, so "PERSON_FNAME" is fine
• No merged cells

PDFs and DOCX work for things like printed event lists and reports. You don't need to clean the file up first. For larger data sets, connect via API.

Open Compose, choose your file, and start the import. After that you don't have to do anything. Compose reads the file, works out what each column is, matches the people in it against records you already have, and merges them, showing you which stage it's on as it goes.

You'll know it worked when your Records Reconciled count goes up and you can find someone from the file over in Data. The step-by-step walkthrough covers each screen with screenshots if you'd rather follow along.

Connect Drive from Compose, sign in to your Google account, and pick the files you want to bring in.

Only the files you explicitly pick are shared. ProgressLab asks Google for the narrowest permission there is: it can open the specific files you choose in the picker, and nothing else. It can't browse your Drive, list your folders, or see a file you haven't handed it. That holds every time you import, so each file stays a deliberate choice you make.

Nothing happens to data you've already imported. Those records stay exactly where they are, still searchable, still showing which file and row each value came from.

What stops is future access. You won't be able to import new files from Drive, and "Save to Drive" won't appear on files the platform makes for you until you reconnect. If you follow an old link to a Drive file after disconnecting, you'll see "We couldn't find that — it may have been moved or removed."

You can disconnect and reconnect as often as you like.

Data gets into Compose three ways: upload a file, pull it from Google Drive, or connect another system. Google Drive is the one to reach for today.

The connector list inside Compose is the one to trust. It shows what you can connect right now. Check there first.

If the system you need isn't available yet, talk to our team about ways to onboard your data.

It goes through five stages, and Compose shows you which one it's on.

Uploading. The file moves into ProgressLab. Nothing has been read yet.

Classifying. Compose reads your header row and the values under it and works out what each column actually holds: first name, employer, city, amount given.

Transforming. It puts those values into a consistent shape. Phone numbers, dates, state abbreviations, and capitalization all get straightened out. This is the tedious cleanup you'd otherwise be doing in a spreadsheet at 11pm.

Matching. Every row is compared against people already in your data, and against the other rows in the same file. Entity resolution technology is built into the platform. LLMs are not utilized for this functionality.

Merging. Confident matches fold into a single record that keeps every source behind it.

When it's done, the people from your file are searchable in Data, and every field on a record still points back to the file and row it came from. Nothing is overwritten silently.

It reads your header row and the values underneath it, and matches each column against more than 50 known field types. First name, last name, employer, occupation, mailing address, phone, email, amount, date given, and so on.

Headers in the wild are rarely tidy, so Compose doesn't rely on them alone. "DONOR_FNAME", "Home Ph", and "Employer/Occ" are all recognizable. So is a column named nothing useful at all, because what's in the column is evidence too. A column labeled "Contact" full of values with an @ in them is an email column, whatever the header says.

You can check its work. Compose shows what it decided for each column, along with how confident it was, so you can scan the ones it was least sure about rather than reviewing all of them. If a column was read wrong, the most reliable fix is to give it a clearer header in the source file and import again. You can also correct individual values later on a person's record in Data, where each field shows the file and row it came from.

A stalled import shows a warning icon, with a retry or reprocess option. What it means: the import stopped partway through a stage. The file is usually the cause: an unexpected layout, a damaged spreadsheet, or a header row that isn't at the top. What to do: retry the job first. If it stalls at the same stage again, delete it, check the file has one clean header row and no merged cells, then upload it again. If it keeps happening: split the file into smaller ones and import them one at a time. If that fails, contact support with the file name and the time you started it.

Four cards, four different questions.

• Records Reconciled. How many unique people you have in your database after duplicates were matched up. This is people, not rows. Importing 5,000 rows covering 4,000 people moves it by about 4,000.
• Platform Matches. Records from your imported data that match to our platform recordsn (donor data that comes with The Progress Lab platform).
• Sources Connected. How many connected data sources you draw from using an API or the platform. If you see "1" listed, that is The Progress Lab platform data that comes with your access.
• Total Imports. The number of files uploaded to Compose.

Workspace Owners (admins) are the only users with this control. There's a delete-all-data control in the danger zone of your workspace settings, and it does exactly what it says. Every record you've imported is removed. It cannot be undone. There's no archive behind it, no restore, and no support request that brings the data back.

Because of that, it's built to be hard to trigger by accident:

• You have to type the confirmation exactly. Clicking through isn't enough.
• A progress counter shows records being removed as it works, so you can see it's running on a large amount of data rather than wondering whether it froze.
• It won't start while an import is running. Let the import finish or delete it first. If you try anyway, you'll see "We're still finishing your previous request, or you've hit a limit. Please wait a moment and try again."

A few things worth knowing before you use it. Public campaign-finance data isn't yours to delete, so people will still turn up in Data from public sources after your own records are gone.

Two things: the records you've imported, and public campaign-finance data we maintain for you.

Your side is whatever you've brought in through Compose — donor exports, volunteer lists, board spreadsheets, event RSVPs. The public side is federal filings from the FEC, state finance reporting agencies and state contribution files, covering the contributions that committees are legally required to disclose.

The two sides are matched together. A donor who appears in your CRM export and in three separate filings shows up as one person with one giving history, not four rows you reconcile by hand.

That's the point of it: one search instead of five. Most teams check the CRM, then ActBlue, then the advocacy tool, then a board spreadsheet, then a web search. Here that's one query, and every value on the result shows which source it came from.

What isn't in there: anything you haven't imported, and anything that was never publicly disclosed. Contributions below a federal or state itemization threshold don't appear in public filings at all, so they'll only be in your own data. That's the most common reason a total here looks different from a total somewhere else.

A person record opens as one panel with everything known about that person, grouped into sections:

• Contact: name, email, phone
• Address: the addresses on file for them
• Demographics: attributes carried in from your imports or public files
• Voter Registration: registration details, where a state file supplies them
• Districts: the districts their address falls in
• IDs: the identifier this person carries in each system they came from
• Tags: labels applied to the record
• Provenance: which file and which row each value came from

Below those sit the giving sections: a donation summary, the FEC and state committees they've given to, and their individual transactions.

Not every section is full for every person, and that's expected. A record built entirely from public filings will have giving history and little else. A record from your own CRM export may have rich contact details and no voter data. Blank doesn't mean broken; it means no source you've connected reported that value.

If something on the record is wrong, you can edit it right there on the panel.

Giving history sits in three parts on every person record, widest view to narrowest.

Donation summary is the top-line picture: what they've given, across what span.

FEC Committees and State Committees list the committees they've given to, split between federal and state. This is the fastest read on what a donor actually cares about and who else is already talking to them.

Transactions are the individual contributions: date, amount, and the committee that reported it.

Read them in that order. The summary tells you whether you're looking at a steady small-dollar donor or someone who maxes out. The committee lists tell you where they sit politically. The transactions tell you their rhythm, which is usually the useful part before a call: whether they give at the end of a quarter, whether they gave in the primary, whether they've gone quiet since last cycle.

Two things to keep in mind while you read. Committee names are not candidate names, so a contribution to a candidate you know will appear under that committee's registered name. And what's here is what was publicly reported plus what you imported. Contributions too small to be itemized were never disclosed, so no tool has them.

Every value on a person record traces back to the file it came from and the row inside that file. The Provenance section on the record is where you see that trail.

It exists because these records are built from several sources at once. One person can arrive from your CRM export, a state filing, and an event sign-in sheet, each carrying a slightly different address. When sources disagree, provenance is how you settle it: you can see that one address came from a 2019 event list and the other from a voter file updated this year, and decide which you trust. That's a ten-second check instead of an email thread.

It covers public data too. A transaction traces back to the specific filing it was reported in, so if a number gets challenged you can point at the filing rather than at us.

This is the honest part of an automatic matching system. The matching is good, but it isn't perfect, and a merge you can't inspect is a merge you can't trust. Provenance is what makes a wrong value something you can find and fix rather than something mysterious.

Use the source type filter to narrow results to your own imported records or to public campaign-finance data, then sort the list to bring the people you want to the top. Results are paged, so if what you need isn't on the first page, either page forward or tighten your search terms.

One thing to watch: a filter stays on until you clear it. If a search comes back thinner than you expected, check whether a source filter is still applied from last time.

Yes. Open the person's record and edit the field directly on the detail panel. Use it when you know something the data doesn't: a corrected spelling, a new phone number, an address that's gone stale. Click the edit button at the top of the record panel to edit. What your edit changes: the record here in ProgressLab.

What it doesn't change: the original file you imported, the public filing the value came from, or the record in your CRM. Nothing is written back to another system, and a public filing can't be corrected from here. That's between the filer and the agency that collected it.

What it means: they're almost certainly there, but your search text or a filter isn't matching them.

What to do: try a spelling variant, a nickname (Bob for Robert), or a maiden name. Search by email or phone instead of name. Clear the source type filter if one is on. If you imported them recently, the import may still be matching records, so check the status in Compose.

If it keeps happening: search just part of the last name. If that still comes back empty, contact support with the person's name and the file you imported them in.

Almost always because the two tools are counting different things, not because one of them is wrong. Four differences explain nearly every mismatch:

Committee names aren't candidate names. Money is reported to a committee, and that committee's registered name can look nothing like the candidate's. If your other tool searches on the candidate name, it will miss contributions we're counting, or count ones we've attributed elsewhere.

ActBlue appears as a conduit. Contributions routed through ActBlue are reported by ActBlue and passed through to the committee. Depending on how each tool treats that conduit row, the same contribution can be counted once, counted twice, or credited to ActBlue instead of the candidate.

Date ranges differ. Filing period, calendar year, election cycle, and fiscal year all produce different totals for the same donor. Check what window each tool is using before you compare a number to a number.

Small contributions fall below itemization thresholds. Anything under the federal or state reporting threshold is never itemized in a public filing. If your CRM has those and the public data doesn't, your CRM total will be higher, and for that donor it's the more complete one.

What to do: compare one donor, one date range, one committee at a time. That isolates which of the four it is in a couple of minutes. The transactions list on the record shows every contribution in the total and the filing it came from, so you can see exactly what we're counting rather than take the number on faith.

Search when you want one person, fast. Ask the platform when the answer covers more than one person, or involves a comparison, or needs to come out as a file.

Search wins when:

• You have a name and you need their record now
• You're checking an address or phone number before a call
• You want to see exactly what's on file and where each value came from

The platform wins when:

• You need everyone who matches a set of conditions
• You want totals, groupings, or a comparison across a date range
• You want the result as a spreadsheet or a saved report
• You want research and context around a donor, not just their fields

The practical difference is that search shows you what's stored, and the platform does work with it. Typing "lapsed donors in Dane County who gave over $500 in 2022" into search won't get you far, because that's a question, not a lookup. Ask it in Chat instead.

Both read the same data, so you won't get two different sets of numbers. When you're not sure, start with search — it's quicker, and moving to Chat afterward costs you nothing.

The public campaign-finance data is public record. FEC filings and state contribution files are collected and published by the agencies that require them, and research is exactly what they're published for. We do not charge for this data.

Two limits are yours to observe. Some jurisdictions restrict using filed contributor information for solicitation or commercial purposes, and those rules vary by state. And your own imported data is governed by whatever you told people when you collected it.

This isn't legal advice, and we can't give you any. If you're building a program on this data, run it past your compliance counsel first.

A report is a saved question that re-runs on a schedule and keeps its history. You write it once in plain language, something like "weekly total raised by county," and from then on it answers itself on the cadence you set.

Three things make a report different from a one-time answer in chat:

• It re-runs on its own, so you don't have to remember to ask again.
• It keeps every past run. You can open a snapshot and see exactly what the numbers were on a given date.
• Its results show as a table or a chart you can pin to your dashboard and export to PDF or CSV.

You don't need SQL, a BI tool, or an analyst to build one. You describe what you want in the report builder chat and the builder writes the query, with a live preview beside it so you can see the numbers before you commit. If you can explain the question to a colleague, you can build the report.

Reports live under the Reports tab. A new report starts as a draft, private and not running, until you publish it. Need a more complex report that isn't generting on its own? Just contact support and we will try to help.

Ask once, use chat. Ask every week, build a report.

Chat is for the question you have right now: who gave over a certain amount last quarter, what does this file say, draft me a list. You get the answer, you use it, you move on. The conversation stays in your history, but nothing re-runs and nothing updates.

A report is for the question you'll keep asking. It re-runs on the cadence you set, keeps every past result, and can be pinned to your dashboard so the current number is waiting when you open it. That's what turns a Monday fundraising check-in or a monthly board update into something that takes no work at all.

The two are closer than they look. If you notice you're asking the platform the same thing every week, that's the signal to make it a report. And the report builder works the way chat does, so you're not learning a new tool.

One real difference: a report answers one fixed question repeatedly. When you need to follow a thread, ask a follow-up, or change the question halfway through, chat is the better place to be.

You describe it in plain language and the builder writes it. Open Reports, start a new report, and tell the builder chat what you want to know — something like "total raised by month for the past year, as a bar chart." It drafts the query and shows a live preview next to the conversation. Reply in the same conversation to adjust anything that isn't right. When the preview looks the way you expected, name it, set a cadence, and publish. No SQL, no BI training, no analyst. The step-by-step walkthrough covers the whole path.

A draft is private and doesn't run. Publishing makes it live: the report runs immediately, then keeps to its cadence from there.

While a report is a draft:

• Only you can see it.
• It doesn't run, on a schedule or otherwise, so it has no results and no history.
• You can change anything: the question, the chart, the name, the cadence.

When you publish:

• The first run starts right away, so you get results without waiting for the next scheduled time.
• The report joins your saved reports and starts building run history.
• It becomes available to pin to your dashboard.

Drafts are the right place to work. Build the question, preview it until the numbers look like what you expected, and publish when you'd be comfortable with someone else reading it.

If you publish and the first run comes back empty, that usually means the question is narrower than you intended or the data hasn't been imported yet, not that publishing failed.

You set both in the builder before you publish — and you can change either one afterward. The name is what you'll see in the sidebar and on your dashboard, so make it specific: "Weekly raised by county" beats "Fundraising." The cadence is how often the report re-runs on its own. Changing the cadence later doesn't erase what's already in your run history; the report simply starts keeping to the new rhythm. If you need numbers sooner than the next scheduled run, refresh the report by hand instead of changing the cadence.

There are five: table, bar, pie, line, and scatter. Pick the one that matches the shape of your question.

• Table for when the exact numbers matter, or when you have more than a handful of columns. Best for anything someone will read row by row, like a call list or a committee breakdown.
• Bar for comparing amounts across categories. Raised by county, gifts by source, totals by event.
• Pie for showing parts of one whole. It works with a few slices; past about six it becomes a color-matching exercise, and a bar chart reads more clearly.
• Line for anything over time. Cumulative raised, weekly gift counts, month over month.
• Scatter for the relationship between two numbers, such as giving capacity against actual giving, where each dot is a person.

If you're not sure, preview it as a table first. A table always shows you the plain truth of the data, and once you can see the shape, the right chart is usually obvious. Preview runs the query without saving, so trying two or three costs you nothing.

Whichever you choose, the underlying rows stay exportable to CSV, so anyone who wants the raw figures can have them.

Yes. Preview runs the query and shows you the results without saving anything. It's how you check your work before a report becomes real: you'll see the actual numbers and the chart, drawn from your data, next to the builder conversation. Nothing is published, no schedule starts, and no run history is created. Preview as many times as you like, adjusting the question and previewing again, until the results look like what you expected. Then name it, set the cadence, and publish.

Open the report and refresh it. A published report runs on its own cadence, but an on-demand run gets you current numbers immediately, which is useful before a finance meeting or right after a big import finishes. The refreshed result is saved into run history like any scheduled run, so it doesn't disturb the schedule or overwrite what came before. If you see "We're still finishing your previous request, or you've hit a limit. Please wait a moment and try again." then a run is already going. Give it a minute and check back.

Drag it from the sidebar into an open slot on your dashboard. The dashboard holds four reports at a time: enough for the numbers you want in front of you every morning, few enough that it stays readable. Choose the four you'd check without being asked. Raised to date, this week's gifts, new donors, whatever your version of that is. A report has to be published before you can pin it, since drafts don't run and would have nothing to show. The walkthrough covers it in four steps.

Yes. Every run a report has ever done is kept, and you can open any of them. Run history is the list of those runs, each with its date. Opening one shows a snapshot: the results exactly as they stood on that date, not recalculated with today's data.

That's more useful than it sounds:

• You can answer "where were we this time last month" without rebuilding anything.
• You can show a board or a funder the number as it was when you reported it.
• If a total moves in a way that surprises you, you can walk back through the runs to find when it changed; often that's the week a new file was imported.

Snapshots don't move. A run from three weeks ago will always show three-week-old numbers, even after new data lands, and that's the point of keeping them. For today's figures, look at the most recent run or refresh the report by hand.

Run history starts at publication. A report you've kept as a draft has none, because drafts don't run.

Export from the report itself, as either PDF or CSV. PDF gives you the report as it looks on screen, chart and numbers and title together, which is what you want for a board packet or an email to a candidate. CSV gives you the underlying rows, which is what you want when someone needs to sort, filter, or drop the figures into a spreadsheet. Both export what's currently shown, so if you need a particular date's numbers, open that snapshot from run history first and export from there.

Empty or odd numbers usually mean the question was narrower than you meant, not that anything broke. What it means: the query returned nothing or the wrong slice. Common causes are a date window that misses your records, a filter that's too tight, data that hasn't been imported yet, or a report published so recently that its first run hasn't finished. What to do: check the date range, then widen the question in the builder and preview it. Confirm the records exist by searching for one in Data, then refresh the report. If it keeps happening: note the report name and what you expected to see, and contact support.

A plugin is a packaged set of campaign workflows you set up once and then just ask for in chat. Four are available today:

• Fundraising: donor research, call-time prep, event planning.
• Campaign Scheduler: turning a pile of scheduling requests into an optimized candidate schedule, with drive times built in.
• Briefcase: daily briefings and event prep briefs.
• Comms: strategy, tracking, drafting, and pre-publish screening.

They exist to give back the hours that go into manual prep. Two examples of the kind of work they're built for: a finance intern uploaded a bundler contact list and got back 43 prospects over $1,000, each with research and a suggested ask. On the scheduling side, a monthly candidate schedule built in about 30 minutes instead of two days, with roughly 30% less drive time and about 3.5 more hours of call time a month. Those are examples, not guarantees. What you get depends on your data, your race, and how much you've told the plugin about both.

None of this requires hiring a data engineer or an AI specialist. You set up the plugin for your project by answering a short setup conversation, then start asking for the work.

Installed plugins sit at the bottom of the left sidebar. Click one to see its details and the list of skills it can do. That list is the fastest way to find out what's actually available to you, since each skill is one job described in plain language, and you run it by asking in chat. The sidebar appears on Chat and Reports; if you don't see it, open it with the sidebar toggle at the far left of the topbar. If a plugin you expected isn't there, ask your workspace owner.

A skill is one job a plugin does. The Fundraising plugin, for example, has a skill for donor research, one for call-time prep, and one for event planning — three separate jobs, one plugin.

Thinking in skills is useful because it's how you talk to the platform. You don't open a skill or fill in a form. You ask for the job. "Research this donor before my call at 3" is the donor research skill. "Build me a call sheet for Thursday" is call-time prep. The platform picks the right one and runs it.

A few things hold true across all of them:

• Each skill reads your project's plugin profile every time it runs, so it already knows your campaign's details.
• Skills produce something you can use: a brief, a call sheet, a schedule, a draft, not just a paragraph in the chat window.
• A skill can be put on a schedule, so a daily briefing arrives without anyone asking for it.
• Skills never rewrite your profile. Only the setup conversation does that.

Setting up a plugin is a conversation, not a form. Go into the project you want to configure and start the plugin's setup. It asks one or two questions at a time, in plain language: what the campaign is, who the candidate is, how you work. At the end it writes a project profile that every skill in that plugin reads from then on. It takes a few minutes, once per project. The walkthrough runs through it with the Fundraising plugin and ends with a finished donor brief.

A project profile is one file per plugin per project that holds your campaign's settings, and it's the reason skills give you consistent answers instead of starting from scratch every time.

Here's how it works. When you set up the Fundraising plugin for a race, the setup conversation asks about the campaign, the candidate, how you like asks framed, what you need flagged. That goes into a profile. Every time a skill in that plugin runs, whether that's donor research today or call-time prep in three weeks, it reads the profile first. So the briefs you get in October rest on the same assumptions as the ones from July.

Three things worth knowing:

• One profile per plugin per project. Fundraising and Briefcase keep separate profiles, and a different project gets its own set.
• Working skills read the profile and never write to it. Only the setup conversation changes it, which means your settings can't quietly drift mid-cycle.
• When something in the profile is wrong or out of date, re-run setup rather than correcting each skill as you go. Fix it once and every future run picks it up.

Ask for it in chat, in your own words. Make sure you're inside the project the plugin is set up for, then say what you want done: "Research Maria Delgado before my meeting this afternoon," "Build a call sheet for Thursday," "Give me today's briefing." You don't need the skill's exact name. The platform picks the right skill, reads your project profile, and runs it. Research-heavy skills take longer than an ordinary chat answer, so expect it to think for a while before anything appears.

Re-run the plugin's setup conversation. It updates the sections you change rather than wiping the profile and starting over, so you can correct one thing, like a new finance director or a revised goal, without redoing the whole setup. Do this whenever the facts of the campaign move; every skill picks up the change on its next run. The profile belongs to the project rather than to you personally, so anyone working in that project sees the same settings, and your update applies to their runs too.

Yes. You can give a skill a run time, a timezone, and the weekdays it should run. A daily briefing at 6am on weekdays is the common case: it's ready when you open the laptop, without anyone asking. Set the timezone to where you actually are rather than where headquarters is, or the timing will drift by an hour when the clocks change. A schedule can be changed or turned off later. The walkthrough sets one up end to end and shows you the next run time.

Yes. The same plugin can be configured differently for each team. That matters when one workspace covers several programs — the field team and the finance team both want Briefcase, but they need very different briefings. Configure the plugin per team and each gets its own settings, so a skill run by someone on the finance team follows finance's setup rather than field's. If you're not sure which team you're in or how yours is configured, ask your workspace owner.

Plugin outputs render in the app — a donor brief or a briefing preview appears in the conversation, formatted to be read rather than dumped as raw text. From there you have the same paths as any other work: a generated spreadsheet arrives as a download card, and you can save it to Google Drive if Drive is connected. To pass a brief to someone else, export the conversation as PDF. If what they need is the underlying numbers rather than the write-up, ask for the data as a spreadsheet and send that instead.

Your workspace is the outermost container: one organization, one set of members, one set of admin settings. Everything else lives inside it.

Teams are groups of people within the workspace. You create a team, give it a name and a color, and assign members to it. Teams are how you organize staff by function, and they're also how the same plugin can be set up differently for different groups, so your finance team and your comms team each get settings that fit their work. You can be on more than one team.

Projects are where the work actually happens. A project is one campaign, one race, or one program, and it holds its conversations, its documents, and its plugin profiles together. The platform only reads a project's documents when you're working inside that project, which is what keeps one race's files out of another race's answers.

The short version: the workspace is the building, teams are the departments, projects are the folders on each desk.

Admin controls live at the workspace level, including invites, roles, seat and spend limits, and privacy settings. Day-to-day work happens at the project level. Teams sit in between, and a small workspace can run perfectly well without creating any.

Click the gear icon in the topbar, to the right of the four product tabs. Workspace settings open in three panes:

• Overview: a 14-day usage chart and a feed of recent activity
• Members & teams: invite people, set roles and spend limits, create and manage teams
• Settings: your workspace name, data privacy, and the danger zone

Administrative actions belong to workspace owners. If you're a member and you try one, you'll see "You don't have permission to do that."

Open workspace settings with the gear icon, go to Members & teams, and add a new member. You'll enter four things: their email address, their name, their role, and a spend limit for their account.

They get an invitation by email, and they set up two-factor on first sign-in, which is required for everyone. Invitation is the only way into a workspace. There's no public sign-up, so nobody joins without an admin adding them.

If you're setting up a whole team at once, invite everyone first and create teams afterward. It's easier to sort people into groups once they're all in the list.

There are three roles, and the difference is mostly about who can change the workspace rather than who can do the work.

Workspace owner. Runs the workspace. Owners get the administrative side of the gear menu: inviting and removing members, setting roles, creating and deleting teams, setting seat and spend limits, changing the workspace name and privacy settings, and the danger zone. If an action changes the shape of the workspace or what it costs to run, it belongs to an owner.

Member. The role most of your staff will have. Members do the actual work: chatting with the platform, importing data in Compose, looking people up in Data, building and publishing reports, running plugin skills. They see their own usage as a percentage of their limit. They can't invite people, change roles, or move limits, and if they try they'll see "You don't have permission to do that."

Teams live in Members & teams in workspace settings. Create one by giving it a name and picking a color, then assign members to it. The color is a visual tag, so choose something you'll recognize when you're scanning a list.

Teams are good for three things:

• Grouping staff by function: finance, comms, field, data
• Giving a plugin different settings for different groups, so the same plugin fits each team's work
• Keeping the member list readable once the workspace grows past a dozen people

You can change a team's name, color, and membership whenever you like. Renaming doesn't disturb anyone's work.

Deleting a team can be refused. If something is still attached to it, the delete comes back as "We couldn't process that request. Please check your input and try again." The fix is to empty the team first: move its members somewhere else, check that nothing is still configured against it, then delete. You'll see the same message if you try to create a team with a name that's already in use, in which case pick a different name.

Open Members & teams, find the person in the list, and edit them to change their role, spend limit, or team. You can remove them from the same place, and changes take effect immediately.

Removing someone ends their access, so they can't sign in. Their work doesn't leave with them: records they imported stay in your data, published reports keep running on their schedule, and documents they added stay in their projects. Their conversation list is tied to their account, so if a conversation holds something the organization needs, export it as a PDF before you remove them.

Your workspace comes with a set number of seats, and each member you invite takes one. The member list in Members & teams is effectively your seat count.

When every seat is used, new invitations won't go through and you'll get an error instead of a sent invite. Two ways forward: remove a member who has left the organization, which frees their seat right away, or have your seat limit raised.

Seats and spend limits are different controls. A seat is the right to sign in at all. A spend limit caps how much a member can use once they're in.

Data privacy settings sit in the Settings pane of workspace settings, below your workspace name. The pane holds your workspace-level privacy choices, and it sits alongside a set of protections that are on for everyone and can't be turned off.

The always-on parts, so you can answer them without opening anything:

• Two-factor is required on every account, with no exemptions
• Data is encrypted in transit and at rest
• Everything runs in US regions, and you pick Virginia or Oregon when a conversation starts
• Zero Data Retention is enforced with the model provider, so your data isn't kept by the model and isn't used to train it
• Messages are stored for your own history and for audit, which is deliberate: an organization accountable to a board needs a record

Changes in this pane apply to the whole workspace, so tell your team before you make one rather than after.

If you're filling in a funder or vendor security questionnaire, those five points cover most of it. For the more specific questions, such as key management, subprocessors, or retention measured in days, get the answer from our support team for your account.

The danger zone at the bottom of the Settings pane deletes your workspace's data. It does what it says, and it can't be undone.

Who can do it: a workspace owner. It isn't available to members.

What it destroys: the records you've imported and reconciled. Every person, every matched donation row, every trace back to the source file it came from. Anything built on that data loses its footing, so reports come back empty and searches in Data return nothing.

How the product slows you down on purpose:

• You type a confirmation phrase, so there's no accidental click
• A progress counter runs while the deletion works, and large workspaces take a while
• It won't start while an import is running. Wait for the import to finish, or delete that import first

There is no undo, no grace period, and no copy on our side to restore from. If there's any chance you'll want this data again, export what matters first, confirm the files actually opened, and only then type the confirmation.

Honest advice: this usually isn't the tool you want. If you're clearing out one bad file, delete that single import in Compose instead and leave the rest alone.

No. Nothing you type, upload, or import into ProgressLab is used to train an AI model.

The arrangement behind that is called Zero Data Retention, and it's enforced with the provider that runs the models. In practice it means:

• Your question goes to the model which is held in The Progress Lab environment, the answer comes back, and no copy of either is sent to the model provider. They don't have your data to train on.
• Nothing from your workspace goes into a Progress Lab training set, either. Not your chats, not your project documents, not your donor records.
• This holds for every model in the picker, not just the default one.

Your messages are still stored inside ProgressLab, because you need your conversation history and your workspace needs an audit trail. That storage is ours, it sits in US regions, and it's encrypted. It's a different thing from a model provider keeping your data, and it's worth keeping the two straight when someone on your board or your funder's staff asks the question.

If you need this in writing for a client, a funder, or a compliance review, the Privacy Policy is the document to point at.

In the United States. ProgressLab runs on Amazon Web Services in US regions only, and your data isn't processed or stored outside the country.

There are two regions: Virginia (US East) and Oregon (US West). You choose one for a conversation in the Model & footprint panel under the composer. The choice locks after your first message, because the conversation's memory lives in the region that started it. If you want the other region, start a new conversation.

Region matters for two reasons. The first is simply where the work happens, which some organizations have to be able to document. The second is energy: the two grids aren't equally clean at the same hour, so the region you pick changes the footprint of the answer.

Everything else you keep in ProgressLab, including your imported records, your project documents, and your reports, stays in US infrastructure regardless of which region a given conversation ran in.

Yes, in transit and at rest, on every account. Data moving between your browser and ProgressLab is encrypted, and so is data sitting in storage. There's no setting to turn on and no plan tier that unlocks it.

That's deliberate. Security features that cost extra get skipped by exactly the organizations that can least afford a breach, so encryption and two-factor are simply how the product works, for everyone, from the first sign-in.

Because campaign and donor data is a target, and a password on its own doesn't protect it. Political and progressive organizations get phished constantly, and one reused password can expose an entire organization.

So two-factor is required on every account, with no exceptions and no opt-out. You set it up with an authenticator app on your first sign-in, and the app will list the account as "ProgressLab".

One thing to know up front: there's no self-service reset. If you lose your phone or replace it, an admin has to reset two-factor on your account for you.

Your conversations are yours. They appear in your sidebar and nobody else's, and other members of your workspace don't browse them the way they'd browse a shared folder.

Two things to hold alongside that:

• Messages are stored. They're kept so you have your history and so the workspace has an audit trail. Stored isn't the same as visible, but it does mean a conversation isn't gone from the record just because you removed it from your sidebar.
• Projects are shared context. Documents you add to a project are available to the platform for anyone working inside that project. Treat a project's files as team material, not personal notes.

Workspace admins can see usage in the Overview pane: how many queries, how much energy, and spend as a percentage of a limit. That's activity, not content.

The practical rule: if you're about to type something you wouldn't want sitting in an audit record, that's a good signal to handle it another way.

Don't upload anything you couldn't defend keeping in a shared work system. In practice, leave these out of chats, project documents, and imports:

• Social Security numbers and other government ID numbers. Nothing here needs one to match a donor.
• Full payment details. Card numbers, security codes, bank account and routing numbers. Your payment processor holds those; the platform doesn't need them.
• Sealed or privileged material. Anything from counsel, anything under a protective order, anything from a personnel or legal matter.
• Health information, or other sensitive personal detail about a donor or a staff member that isn't relevant to the work.
• Credentials. Passwords, keys, and logins for your CRM, your bank, or your email.

Names, addresses, emails, phone numbers, employers, giving history, tags, and voter file fields are all fine. That's what the system is built for.

Two practical notes. If a spreadsheet has one bad column, delete the column and then import, rather than skipping the file entirely. And if something sensitive is already in, tell your workspace owner instead of quietly leaving it there.

You saw both on your first sign-in, in the full-screen gate that asks you to open and check each document before you can continue. The links in that gate are the canonical copies and are always available at www.progresslab.ai.

When either document changes, the gate comes back and asks you to accept the new version. That isn't a glitch, and it isn't routine housekeeping either: it means something material changed. The version and date at the top of the document tell you which one moved. If your organization reports to a board or a funder on how it handles data, a version bump is worth an actual read rather than a click-through.

Send it to our security contact at security@progresslab.ai, and send it before you're certain. A suspicion reported early is far more useful than a confirmed problem reported late.

Include what you saw, when you saw it with a rough time and your timezone, the account or workspace involved, and a screenshot if you have one. Don't paste the sensitive data itself into the report.

If you think an account has been taken over, tell your workspace owner at the same time. They can reset two-factor and remove that account's access straight away while we look into it.

No. Our system is not designed to prepare your compliance reports &we don't tell you what's legal.

ProgressLab includes public campaign-finance filings from the public disclosure systems for research, and every field on a person record traces back to the source file and row it came from. That's genuinely useful for compliance work, because you can show where a number came from and when it was filed.

What it isn't is a compliance product. We don't file anything, we don't check contribution limits for you, and nothing the platform writes is legal advice. Solicitation rules, aggregation limits, and state-by-state restrictions are yours to observe. For those, talk to your compliance counsel.

Because running an AI model uses electricity, and we'value transparancy and respect your right to make informed decisions about how you use this technology. Every model in the Model & footprint panel carries an energy score right where you choose it, so the cost of a choice is visible while the choice is still open. Showing the data lets you align how you use AI with what your organization says it stands for, and gives you real figures to point at rather than a general good intention. All AI companies could make this information transparent.

Choices we eanble you to make:

• Pick a smaller model when a question doesn't need a large one. Most questions don't.
• Choose the region running on the cleaner grid at that moment.
• Schedule a question for a clean window so it runs at the cleanest hour of the day.

Your usage dashboard adds it all up, so at the end of a quarter you can say what your AI use actually cost rather than what you assume it did.

It's an estimate of the Carbon Intensity used to answer your question. Carbon intensity is the amount of carbon released per unit energy by the power station powering the selected data center. Carbon intensity varies by region, fuel mix, demand, and time of day.

Virginia and Oregon aren't equally clean at the same time of day, which is why the same question can carry a different footprint depending on where and when it runs.

What it isn't:

• It isn't a meter reading. Nobody has a wire attached to the specific chip that answered you. It's a model of energy efficiency, built from published figures.
• It isn't precise to the decimal. Treat it as a reliable way to compare options, not as an auditable figure for a sustainability filing.

Where it's genuinely good is comparison. The gap between the regions or between times of day in the same region can be significant, so every choice made contributes to the overall reduced environmental impact of ProgressLab's AI.

It's a risk classification for how a model performs on bias and safety testing, shown next to the model in the Model & footprint panel so you can weigh it before you pick. Details about each model's score and the methodology can be found by clicking Safety Details.

The "Low, Medium, High" classifications come from peer-reviewed research (when available) with a published methodology and from audits from the AI companies themselves, not from our own opinion of the models.

How to read one:

• A "Low" risk label means the model did well across the categories that were tested and that a broad set of data exists measuirng its safety and performance.
• A "Medium" label indicates that either safety and performance scores were lower or some key metrics are missing or haven't been evaluated yet. Newer models with no independent evaluations often falln in this bucket. It's a reason to be more deliberate about what you send that model and to read the answer more closely.
• A "High" risk label can mean one of two things, either scores on independent evaluations show real reasons to question safety and performance or no data is available at all. ProgressLab does not offer these models in our model selector, but we do show you the data in the model safety documentation.

A clean window means your question waits and runs at the hour when the grid powering it is cleanest. You set it in the Model & footprint panel under the composer: instead of running now, choose the clean window, and ProgressLab schedules the question against a 24-hour forecast of grid demand.

You don't have to wait around for it. Close the tab, do other work, and you'll get a banner when the answer is ready. It suits anything you don't need this minute, like a weekly research pull, a long analysis, or something you're lining up the night before.

It depends on the question you are asking.

A clean window costs you nothing in quality. Same model, same answer, it just arrives later.

A smaller model is a real trade. Haiku is fast, low-energy, and perfectly good at summarizing, drafting, and straightforward lookups. On hard analysis or long chains of reasoning, Opus is better and you'll notice.

The honest guidance: leave it on the default for most work, drop to smaller models for routine drafting, and move up to larger models when a question needs it. Re-running a disappointing answer on a bigger model costs more energy than picking the right one first.

Your sign-in timed out. Sessions are set to time out after 15 minutes of inactivity. What to do: Sign in again with your email, password, and a code from your authenticator app. Text still sitting unsent in the message box won't survive the sign-out, so copy anything long before you go. If it keeps happening: Being signed out several times in one working session without down time isn't normal. Tell support which screen you were on and roughly what time, and include your browser.

What it means: One of three things, sharing one message: a conversation is still working, a job is already running, or you've reached a spend limit. What to do: Check in this order. 1. The conversation. If it still shows "Thinking" or a Stop button, the platform hasn't finished. Wait, or press Stop and re-ask. 2. Compose. An import still moving through its stages blocks some actions until it's done. 3. If neither, it's a limit. Usage shows as a percentage of your limit; at 100% you're paused until it resets or a workspace owner raises it. Limits are set per user and per workspace. If it keeps happening: If nothing is running and you're nowhere near your limit, contact support with the time and what you were doing.

What it means: The failure is on our side, not in anything you did. Your input was fine. What to do: Wait a few seconds and try the same thing again. Most of these clear on the first retry. If you were part-way through writing something, copy your text before you retry so you don't lose it. If it keeps happening: Two failures in a row on the same action is worth reporting. Send support what you were doing, the time it happened, and a screenshot showing the message.

What it means: Probably nothing. The platform does its research before it writes, so typically about 15 seconds of "Thinking" is normal on questions that need a web search, your documents, or a database lookup. Large requests could take one or two minutes to respond. What to do: Watch the small activity cards. If they're still changing, it's working — leave it. If nothing has moved for a minute or so, press Stop, which keeps whatever text it had, and ask again more narrowly. Haiku 4.5 comes back fastest if you just need the answer. If it keeps happening: Note the question and roughly how long you waited, and send it to support.

What it means: The import stalled in one of its five stages. Large files genuinely do sit in Matching for a while, so give it time before deciding it's stuck. What to do: Open Compose and look at the job. A stalled import shows a warning icon with a retry option — use it once. If it stalls again, delete that import and upload the file fresh, after checking the file opens cleanly and has a proper header row. If it keeps happening: Send support the file name, its size, and which stage it stops at. Note that clearing all your data won't run while an import is still going.

What it means: Nothing matched what you typed. Almost always it's a spelling variant, a filter still switched on, or a record that hasn't finished importing. What to do: Work through these. 1. Search less — last name alone beats a full name. 2. Try variants: nicknames, maiden names, hyphenated spellings, middle initials. 3. Search by email, phone, or city instead of name. 4. Clear any source-type filters on the results. 5. If you imported recently, check the import has finished merging. If it keeps happening: Confirm the person is actually in the file you imported, then contact support with the name and the search you tried.

What it means: Either the password is wrong, or the six-digit code isn't matching. Codes are tied to the clock, so a phone running a minute fast or slow will be rejected every time. What to do: Turn on automatic date and time on your phone, then try a fresh code. Check you're reading the entry whose issuer shows as "ProgressLab" — with several accounts in one authenticator app it's easy to grab the wrong one. If a code is about to roll over, wait for the next one. If it keeps happening: New phone, or lost the authenticator? There's no self-service reset: ask a workspace admin to reset two-factor on your account.

What it means: The connection to Drive has lapsed or been revoked, or the file picker was blocked before it could open. What to do: Open Compose, find your connected sources, and reconnect Drive. If the picker never appears, allow pop-ups for this site in your browser and try again. Data you've already imported is unaffected either way. Remember we only get the files you pick, one at a time, so a file you didn't select won't be there. If it keeps happening: If your organization manages Google accounts, ask your Google admin whether third-party app access is restricted. Otherwise contact support.

Reach support at support@progresslab.ai and include five things (if you have them): 1. What you were doing, step by step 2. What you expected to happen 3. What you saw, with the exact wording of any message 4. A screenshot of the whole screen, not just the error 5. Roughly what time it happened, and your timezone If it keeps happening: Say up front if it's blocking your whole team. For account access, like a two-factor reset, a role change, or a spend limit, your workspace owner or admin can usually sort it faster than we can.