Platforms

What each piece is responsible for

The architecture page lists what Archer depends on. This one explains why each dependency exists, what it is deliberately not allowed to do, and what breaks when it is unavailable.

The rule these choices follow

Each platform owns one thing, and no platform is trusted to enforce a rule that Archer can enforce itself. The pricing engine is the clearest case: it is a pure library with no network access and no database connection, so a bad response from any service below cannot produce a wrong price. It can only produce no price, which is a failure a person notices.

Anthropic — reading the solicitation

A 200-page solicitation states its scope across tables, appendices and paragraphs written by someone who was not thinking about a parser. Claude reads it into a structured shape: sites, areas, square footage, fixture counts, service frequencies, wage rules, deadlines and required forms.

What it is not allowed to do is price anything. It reports what the document says; every number that reaches a bid comes from the engine, applied to requirements a person has reviewed. A model that hallucinated a square footage would produce a visibly wrong extraction for someone to correct, not a quietly wrong price.

If it is unavailable: uploads still work. Archer falls back to a keyword pre-scan and marks the bid as needing the requirements filled in by hand. Nothing is lost; the reading is worse and the bid says so.

Supabase — the system of record

Three separate jobs, which is worth separating because they fail differently.

ComponentResponsible forDeliberately not
PostgresBids, requirement versions, priced models, scenarios, pricing models, company profiles, org membership and invitations.Enforcing tenancy. Archer connects with a service-role credential, so the boundary is application code — stated plainly on the architecture page.
StorageThe uploaded solicitation, in a private bucket, filed under the owning organization.Serving anything publicly. Files leave only by signed, expiring URL after an access check.
AuthGoogle sign-in, the session cookie, and the trigger that claims an invitation on first sign-in.Deciding what a signed-in person may see. Authentication and authorization are separate; being signed in grants nothing on its own.

If it is unavailable: Archer is down. This is the one dependency with no fallback, and pretending otherwise would be dishonest — it holds the data.

Vercel — delivery

Hosting, TLS, and the edge network. Deployments come straight from the main branch: every change is built, typechecked and tested before it ships, and a deployment can be rolled back to any previous one.

Vercel holds no bid data at rest. Requests pass through it; nothing is stored there.

Market data — public sources only

Wage and contract-award data comes from public federal sources. These are read-only and receive nothing: no customer data is ever sent to a market-data provider, so a competitor cannot learn what you are bidding by watching them.

Live market adapters have not been verified end to end. Where a provider cannot be reached, Archer falls back to a stored figure and labels it — a bid never silently swaps a live rate for a stale one. The same discipline applies to union agreement rates, which are carried as approximate with a source link, never as fact.

Google Fonts and avatars — the honest footnote

The typeface and the profile picture in the app bar are loaded from Google on every page view. No bid data reaches them, but a visitor’s IP address does, which makes Google a subprocessor for page loads whether or not anyone intended it. Named here because a thorough review will find it, and finding it unlisted is worse than finding it disclosed.

How they fit together

A bid moves through them in one direction. Vercel receives the upload and puts the file in Storage. The intake package parses it and asks Anthropic to read it. The result is reviewed by a person and written to Postgres as a requirement version. The engine — touching none of these — prices it. The export package turns that into a workbook, a PDF or a proposal.

Each arrow crosses a boundary where the data is already checked and the caller is already known. Nothing downstream re-derives who is asking, because that answer was settled once, at the edge, from the session.

Want this in a questionnaire format?

We will fill in your standard vendor assessment rather than ask you to read a web page.

For the dependency inventory and the tenancy detail, see Architecture. For policies and controls, see Security.