Parse a Pre-Bid Invitation
Turns the first two pages of an agency's invitation to bid into cropped images, framed the same way on every submission, ready to place in the bid form.
Overview
Contractors bidding public work don't get to design their own paperwork. The agency sends an invitation to bid, and the response has to carry pieces of that invitation back inside the submitted packet. New York City's Department of Housing Preservation and Development (HPD) works this way: an invitation goes out, and what comes back is a bid packet that reproduces the invitation's own pages in the places the form expects them.
Doing that by hand is screenshot work. Open the invitation, export a page, crop off what doesn't belong, save it somewhere, then paste it into the right spot in the bid forms. It is twenty minutes of nothing, per bid, and it is exactly the sort of task that gets skipped under deadline and then bounces the submission.
This tool does that step, for one document. It reads the first two pages of the invitation you were sent and renders a fixed region of each as an image. The framing was measured against this agency's form, so it does not have to be worked out per run and does not drift between bids. The output is two images, registered with the package, that a later call drops into the bid form's two image positions.
Nothing about it is generic. It was written because a customer bids HPD work and HPD's invitation looks the way it looks — the clearest example in this catalogue of a tool built for exactly one agency's document.
What It Does
| Capability | What it means for you |
|---|---|
| First two pages | The invitation's first and second pages become images; a third or fifth page does not |
| Fixed framing | A set region of each page is captured, rather than the whole sheet |
| Same every bid | Those regions never change, so the pages come out framed identically on every submission |
| Registered with the package | The images become package files a placement call takes by name — no manual export, save and re-upload |
When the Agent Chooses This Tool
Only one of the three workflows can call this: contractor bid packages. Appraisal and coating QA runs have no such tool, and which workflow runs is settled by the package you started, not by anything the agent works out.
Inside that workflow it is barely a choice. The run is told to parse the invitation as a named step, and two conditions gate it. An upload identified as the invitation to bid has to exist — if none does, the run stops and asks you for one. And it has to have arrived in the run happening now: re-running a package over an invitation uploaded earlier skips this step, and the image placement that depends on it.
In sequence, it is the last of the preparation steps, before the bid form itself exists:
- The invitation is parsed here, producing the two page images.
- One bid form is added — always the same one, declared without deliberation.
- Its fields fill from the invitation and from anything you typed with the request.
- The two images are placed, one per position.
- The invitation's middle pages are carried into the packet as ordinary pages.
Steps 4 and 5 are not competing options, which is the part worth understanding. The first two pages travel as images because the bid form has positions expecting them; the middle pages travel as pages; the last page is left out because the form already carries it. The invitation itself is never placed into a position — only the two images made from it. A short invitation skips step 5 entirely.
If parsing fails, the run is told to stop and report it rather than retry.
Inputs and Outputs
Takes: the uploaded invitation to bid. It has to belong to the package being assembled; one from another package is refused.
Returns: two images, identified so the placement step knows which is the first page and which is the second. An invitation shorter than two pages is refused instead.
Example
A contractor on HPD's pre-qualified list receives an invitation to bid for an Open Market Order job. They upload the invitation — seven pages — and type a short note about crew rates, then ask for the bid package.
The run parses the invitation, and its first two pages come back as cropped images. The bid form is added and its fields fill from the invitation and from the note about rates. The two images go into the form's two positions. Pages three through six are carried into the packet as ordinary pages; page seven is left out, because the form already carries it. The finished parts are merged into one submission-ready PDF.
The estimator spends their time on numbers. The screenshot-and-crop step, which nobody was ever paid for, doesn't happen.
Limits
- It reads the first two pages and nothing else. A third page, a fifth page, an attachment bound into the back — none of them become images. They are not lost, because the packet carries them through as ordinary pages, but content on them arrives as a page rather than as an image in a form position.
- One region of the second page is blanked before its image is made. That area comes through empty by design; anything written there is not in the packet.
- Nothing checks that the document is the one the framing was measured against. A different agency's solicitation, or a redesigned version of this one, is cropped to the same regions anyway — the images come out wrong rather than refused.
- It produces images, not data. It does not read the solicitation number, the due date or the scope out of the invitation. Those values reach the bid form through the ordinary filling step.
- It does not decide placement. Which image belongs in which position is a separate call.
- The framing is fixed in the tool itself. If the agency changes its invitation, the framing has to be re-measured and shipped — there is no setting anyone can turn, before a run or during one.
- Nothing here checks bid eligibility, validates compliance with the solicitation, or submits anything. It prepares pages; the bid remains yours to review and file.
Built for One Workflow
General document tools are table stakes. Every vendor can merge and flatten a PDF. What actually decides whether a workflow can be automated is whether the awkward, specific step in the middle — this agency's invitation, that carrier's supplemental, this lender's addendum — has a tool that handles it properly.
Those tools get built per customer workflow during implementation. That is the work described on /pricing: the setup that turns a general document agent into one that knows your paperwork.
FAQ
Does this work for invitations to bid from other agencies?
Not as written. The framing was measured against New York City HPD's invitation and is fixed in the tool. Worse than simply not working: nothing checks the document first, so another agency's solicitation is cropped to the same regions and the images come out wrong rather than refused. A different agency's document needs its own framing, built during setup.
Does it extract the bid due date and solicitation number?
No. This tool produces page images. Those values reach the bid form through the ordinary filling step, which reads the invitation as a source document.
Why images instead of just including the PDF pages?
Both happen, over different parts of the document. The bid form has two positions that expect the invitation's first two pages reproduced inside it, so those two are rendered as images. The invitation's middle pages are carried into the packet as ordinary pages instead. They are not alternatives to weigh up.
What happens if HPD changes the layout of its invitation?
The framing has to be re-measured and shipped. There is no fallback in the meantime: the same regions are captured from the new layout, so you get mis-framed images rather than an error. It is not something the agent can work out, and not a setting anyone can turn.
Can you build one of these for the forms our agency sends us?
Yes — that is how this one came to exist. A workflow-specific tool is written for the document your workflow actually revolves around, as part of implementation. See /pricing for how that setup works.