Find, qualify, and draft government bids with every sentence traced to its source.
EveryShall is an agentic bid operating system for small services firms selling to federal, state, and local government. A mesh of specialized agents finds solicitations, applies your go/no-go rules, extracts every requirement verbatim, and drafts with span-level citations. A human always submits.
A compliance matrix tracks every "shall" in a solicitation. The name is the promise.
One solicitation, six handoffs, one record.
Each agent consumes a typed artifact from the previous one and produces the next. Nothing passes between agents except schema-validated artifacts, and every handoff is a Ledger entry.
Small firms lose bids they could have won, for reasons that have nothing to do with quality.
Federal law sets a government-wide goal that 23% of prime contract dollars go to small businesses. In fiscal year 2025, nearly 28% of federal prime contract dollars, about $179 billion, went to small businesses. Reaching that money means responding to solicitations, and responding is where small firms without proposal staff fall down.
Found late
Opportunities are spread across SAM.gov and dozens of separate state, local, and education portals with no common schema. By the time the owner sees one, half the response window is gone.
Pursued on instinct
Without a deterministic fit check against NAICS codes, set-asides, value, and past performance, firms spend nights on bids they were never eligible for.
Disqualified on a detail
A 120-page package holds hundreds of obligation statements across Sections L, M, and C. Miss one page limit, one form, or one "shall", and the bid is out regardless of quality.
Six agents. Each does one job, calls deterministic tools, and writes to the Ledger.
Models reason about what to do next. Tools do the doing: source polling, document normalization, rule evaluation, retrieval, table construction, export. The split is what makes the output checkable.
Scout
Ingests new solicitations from SAM.gov and the state and local portals you configure, deduplicates them, and downloads every attachment.
Fit
Scores each solicitation against your go/no-go rules, NAICS codes, set-asides, and past performance, and writes out the reasons for the score.
Compliance
Reads the full solicitation package and builds a matrix of every "shall", "must", deadline, format rule, and required form.
Drafter
Produces an outline and first-draft sections. Every sentence is tied to one of your documents or to the solicitation, or it is flagged as unsupported.
Reviewer
Checks the draft against the compliance matrix and lists gaps, unsupported claims, and page-limit problems before you see it.
Ledger
Records every decision, source, model call, and human edit in an append-only log you can open for any bid.
Language models do four jobs here. Everything else is deterministic code.
The value of a model is judgement over unstructured text. The risk of a model is invention. We use models only where judgement is needed and wrap each use in a schema, a budget, and a check.
| Step | Done by | Model tier | Guardrail |
|---|---|---|---|
| Polling sources, fetching and hashing attachments | Code | none | Cursor-based, rate-limited, idempotent |
| Normalizing PDF, Word, and scanned pages to anchored text | Code, OCR for image-only pages | none | Spans keep (doc hash, page, char range); OCR pages marked |
| Hard go/no-go rules: NAICS, set-aside, value, geography, certifications | Rules engine | none | Pure function; runs before any model call |
| Soft fit scoring against capability and past performance | Model | Small | Fixed dimensions, cited reasons, schema-validated |
| Selecting candidate requirement sentences | Code (lexical: modal verbs, imperatives, enumerated instructions) | none | Exhaustive over the whole package |
| Structuring each candidate into a requirement record | Model | Large | Verbatim text byte-checked against source span; temperature zero |
| Retrieving passages from firm documents | Code (hybrid lexical + vector, re-ranked) | Embeddings | Partitioned per firm |
| Drafting sections from retrieved passages | Model | Large | Writes only from supplied passages; must cite per sentence |
| Exact-matching numbers, dates, names against cited spans | Code | none | Automatic flag on mismatch |
| Verifying each sentence against its cited spans | Model | Large | Separate call, sees only sentence and spans; temperature zero |
| Coverage, page counts, export, Ledger hashing | Code | none | Deterministic; export stamped with matrix and Ledger state |
Eight rules every agent and tool must obey.
These are the contracts between components. They are enforced in code, and violations fail the step rather than degrade the output.
Artifact handoff protocol
Agents never talk to each other directly. Each produces a typed artifact (opportunity, rule result, requirement set, section, verdict) wrapped in an envelope: artifact_type, schema_version, producer, run_id, sha256. The next agent consumes only artifacts from the previous step, validated against the schema for that version.
Tool-call protocol
A tool call is a JSON envelope: tool, args, idempotency_key. It returns result, result_sha256, duration_ms, and an error object on failure. Each agent has an allow-list of tools; a call outside the list is rejected before execution. No tool performs network egress except declared source connectors, and none writes to an external system.
Model-call protocol
Every model call carries model identifier, prompt version, temperature (zero for extraction and verification), a JSON schema for the response, and token and time budgets. Responses that fail schema validation are retried with the validation error appended, up to a fixed count, then the step fails. Inputs, outputs, and token counts are written to the Ledger.
Citation protocol
A citation is the tuple (doc_sha256, page, char_start, char_end). A sentence may carry zero or more citations. Zero citations means the sentence is unsupported by definition. Numbers, dates, names, and identifiers in the sentence must appear in at least one cited span, checked by exact match before any model-based verification.
Verification protocol
Verification is a separate model call that receives only the sentence and the text of its cited spans, never the draft context, and returns supported, partially_supported, or unsupported with a one-line reason. The drafting model's own citations are inputs to verification, not evidence. Verdicts are recorded per sentence and per matrix version.
Ledger protocol
Entries are canonical JSON over (seq, at, actor, event, payload, prev_hash), hashed with SHA-256. The chain is verified before every export and on request. Redaction replaces payload content with a marker and records a redaction event, so the chain remains verifiable after deletion.
Human-in-the-loop protocol
Four actions require a named human and produce a Ledger entry attributed to that user: go/no-go decision, acknowledgement of a flagged sentence, matrix edit, and export. Submission is not an action in the system at all; it happens outside it, by you.
Source connector protocol
Each connector declares its source, the published rate limit it honors, its cursor field, and its attachment policy. Polling is incremental by cursor. Attachments are fetched once, hashed, and deduplicated. Amendments create a new opportunity version and a requirement diff for open bids.
Load your profile once. Review what arrives.
Load your profile
Capability statement, past performance, resumes, certifications, NAICS codes, and go/no-go rules as structured conditions. Documents are hashed, normalized, and indexed in your firm's own partition.
Opportunities arrive scored
Scout polls sources by cursor. Hard rules run first and short-circuit. Survivors are scored on fixed dimensions with cited reasons. You mark go or no-go; the decision is a labeled record.
Matrix and draft are built
Compliance extracts every obligation verbatim into a versioned matrix. Drafter writes from retrieved passages with span citations. Reviewer verifies each sentence independently and computes coverage.
You review and submit
Edit in place, acknowledge or fix flags, export to .docx or .pdf stamped with the matrix hash and Ledger head. Submit through the portal yourself.
A matrix you can audit.
An illustrative sample built against sample solicitation language. Every row is a verbatim requirement with its type, due point, and whether the response addresses it.
COMPLIANCE MATRIX · 5 of 41 requirements shown · illustrative sample, not a live solicitation
| Ref | Requirement (verbatim) | Type | Due | Status |
|---|---|---|---|---|
| L-1 | Offeror shall submit a technical volume not exceeding 15 pages, 12-point font, single-spaced. | Format | With proposal | Addressed |
| L-2 | Offeror must provide three past performance references for work of similar size and scope within the last five years. | Past performance | With proposal | Addressed |
| C-4 | Contractor shall designate a Program Manager with a minimum of five years of relevant experience. | Staffing | With proposal | Gap |
| K-9 | Offeror must complete and sign Section K representations and certifications. | Forms | With proposal | Addressed |
| M-2 | Questions shall be submitted in writing no later than 10 calendar days before the closing date. | Deadline | Closing minus 10 days | Addressed |
Properties of the system, stated precisely.
Each of these is a design invariant enforced in code and observable in the Ledger. None is a benchmark or a claim about accuracy.
| Property | Mechanism | Where you can see it |
|---|---|---|
| Exhaustive requirement candidates | Lexical detection of obligation language over the whole normalized package; the model structures candidates but never selects them | Matrix, with source page and character range per requirement |
| Verbatim requirements | Extracted text is byte-compared to its source span; mismatches are rejected | Requirement record, source field |
| Span-level citations | Each sentence stores (document hash, page, character range) for every source used | Sentence record, editor hover |
| Independent verification | A second model pass sees only the sentence and its cited spans; numbers and names are exact-matched first | Review report, sentence flags |
| Schema-validated model output | Every agent output is validated against a JSON schema before use; invalid output retries then fails | Ledger, run entries |
| Versioned prompts and matrices | Prompt version and matrix hash recorded on every call and export | Ledger, export stamp |
| Tamper-evident audit trail | Append-only Ledger with each entry hashing the previous one; exportable as JSON | Ledger export, chain verification |
| Firm isolation | Retrieval indexes and storage are partitioned per firm; a workflow is bound to one partition | Architecture page |
| No submission path | No agent has a tool that writes to any external system; no portal credentials are stored | Tool manifest per agent |
Sources and formats
We list only what is live. Connectors are added one at a time and tested against real postings before they appear here.
| Source | Scope | Status |
|---|---|---|
| SAM.gov Contract Opportunities | Federal solicitations, pre-solicitations, sources sought, and awards, via the public API | In build |
| State and local portals | Added individually; named here when live | Planned |
| Your documents | PDF, Word, spreadsheets, and plain text; stored encrypted per firm | In build |
| Export | Compliance matrix and drafts to .docx and .pdf; Ledger to JSON | In build |
What we can say, and only that.
Encrypted at rest and in transit
AES-256 at rest with a separate key per firm; TLS 1.2 or higher for every connection.
Not used for training
Your documents draft your bids and nothing else. We do not train models on them, and our providers are contractually barred from doing so.
Isolated per firm
Storage, retrieval indexes, and workflow executions are partitioned per firm, and cross-firm reads are tested to fail.
Audited end to end
Every automated decision and model call is a hash-chained Ledger entry. Export the chain and verify it without us.
Deleted on request
Documents, drafts, and derived indexes removed within 30 days; Ledger payloads redacted, chain preserved.
Never submits
No portal credentials are stored and no tool can write to an external system. Submission is a human act, by your staff, every time.
Full security and data page, including what we do not yet have.
Asked on most first calls
Does EveryShall submit bids?
No. It finds, scores, extracts requirements, and drafts. A named person at your firm reviews, edits, and submits through the portal. That is a design rule, not a missing feature.
Does it train on my documents?
No. Your documents are used only to score your opportunities and draft your bids. We do not train or fine-tune models on them, and our model provider is bound by terms that prohibit using customer inputs or outputs for training. The Security page has the details.
Which portals does it cover?
SAM.gov for federal opportunities. State and local portals are added one at a time as we build and test each connector. The Platform page lists exactly which ones are live.
Which AI models does it use?
Two tiers of large language model: a smaller, faster model for classification and fit scoring, and a larger model for requirement extraction, drafting, and verification. Every model call records the model identifier, prompt version, and token counts in the Ledger, so you can see exactly which model produced what.
What does it cost?
Pilot pricing is set per firm during the first call and stated in writing. We will publish a price list once pilot pricing is stable.
Can I export what it produces?
Yes. Compliance matrices and drafts export to .docx and .pdf. Your documents remain yours and are deleted on request.
What happens when it gets something wrong?
It will sometimes be wrong. Unsupported sentences are flagged rather than hidden, the Reviewer lists gaps against the matrix, and the Ledger shows where every statement came from so you can check it. A human reads everything before it leaves your firm.
How are requirements found? Could it miss one?
Candidate sentences are selected lexically, by modal verbs and imperative forms, across the entire normalized package, so selection is exhaustive rather than sampled. A model then structures each candidate, and the verbatim text is checked byte-for-byte against the source span. It can still miss requirements phrased without obligation language, which is why the matrix is editable and every human addition is versioned.
How are citations verified?
A citation is a document hash, page, and character range. A separate verification pass sees only the sentence and its cited spans and returns supported, partially supported, or unsupported. Numbers, dates, and names are exact-matched against the span first. Anything not supported is flagged in the editor and cannot be exported without a per-sentence acknowledgement.
What about scanned or image-only PDFs?
Image-only pages are OCR'd and marked as such. Citations into OCR'd pages carry an OCR marker so reviewers know to check the original image.
Can I export the audit record?
Yes. The Ledger for any bid exports as JSON, including the hash chain, so it can be verified independently of us.
Who is behind it?
A single founder, so far. The About page has the name, the company details, and the reason it exists.
We are onboarding a small number of pilot firms.
Bring a live solicitation to the first call. We will build its compliance matrix while you watch.