For prime contractors and capture teams
You are not evaluating a product, you are deciding whether a name on a teaming agreement creates risk your programme absorbs after award. The disqualifying fact belongs at the top: no authorization, no certification, no equivalency claim. What follows is which teaming shapes remain honest given that, and which one is closed.
A capture runs on a clock somebody else set. Between the draft solicitation and the submission there is a compliance matrix to satisfy, a technical volume to write, past performance to select, and a team to assemble — and every teammate added is another set of representations, another security posture to describe, and another organisation whose problems become yours after award.
So the question about a small teammate is rarely whether the capability is interesting. It is whether they will survive contact with the programme: whether their claims hold up in a technical evaluation, whether their security posture creates a finding, whether they can produce documentation on the timeline, and whether their answer to a hard question is a real answer or a sales one.
The failure that costs most is the late discovery. A teammate’s authorization position, subcontracting status or data-handling limitation surfaces during proposal review, or worse, after award — and the workaround is engineered under deadline by the prime’s own people.
There is also the socioeconomic dimension, which is real and is not the same conversation as capability. Subcontracting goals have to be met and evidenced, and a teammate who helps with one but is weak on the other creates a different problem than a teammate who is the reverse.
And most capture leads have been told by a small technology company that it was ready for a federal programme, and have found out during evaluation that ready meant something narrower than it sounded.
A cloud-delivered capability with no authorization cannot sit in a place on a federal programme that requires one — and if that is discovered after teaming rather than before, the cost is the prime’s.
So it is stated plainly. We hold neither a FedRAMP authorization nor a FedRAMP certification, at any impact level, and we make no equivalency claim. That closes one teaming shape completely: we cannot be the authorized cloud service in a position that requires authorization, and nothing in a negotiation changes that.
What it does not close is the other three, and they are worth naming because a capture lead can evaluate them quickly. First, delivery inside your already-authorized boundary, where the authorization in play is yours and ours is not the relevant question. Second, the commercial or non-federal portion of a portfolio, where the requirement does not attach at all. Third, a sponsored path, where a programme need is real enough to justify the authorization work and the sponsorship exists to support it.
Each of those is a different agreement with a different risk profile, and which is viable depends on the solicitation rather than on our preference. A capture lead can usually tell within one conversation, which is the point of putting the constraint first.
The thing we are actually claiming is narrow: an operating layer for the administrative and management flow around a programme — where work sits, what it waits for, what has aged past its own threshold, and what evidence exists for each action taken. That is useful on many programmes and it is not a mission system, and describing it as one would be the kind of overreach that makes a teammate expensive.
How early a disqualifying constraint is known — measured by the constraint stated in the first conversation, against the usual case of discovery at proposal review.
Whether a teammate claim survives technical evaluation — measured by claims written narrowly enough for an evaluator to verify each one, rather than capability language.
Documentation delivered against a capture calendar — measured by requested artefacts delivered by your dates, with any shortfall stated at teaming rather than at submission.
Programme management flow, where the scope allows it — measured by elapsed time and waiting across deliverable, action-item and approval workflows, decomposed against your baseline.
Evidence available for a contracting officer question — measured by action-level records with authority and timestamp, produced during the work rather than reconstructed.
Risk introduced by adding this teammate — measured by limitations enumerated in writing before signature, so the risk is a known quantity rather than an assumption.
any authorization, any equivalency, any certification, and any ability to sit in a position on a federal programme that requires one. We also do not claim past performance we do not hold, and we will not represent a scope on your bid that we cannot execute. A teammate who overstates on your proposal has created your problem, not theirs.
Inside your authorized boundary: the capability is delivered within an environment you already hold authorization for, under your controls and your continuous monitoring. The relevant authorization is yours, our lack of one is not the governing question, and the technical conversation is about deployment rather than about assurance claims.
On the commercial or non-federal portion: many primes carry a commercial book, internal operations, or programme-adjacent work where the requirement does not attach. That is straightforward ground, and it is often where a working relationship should be proved before anything federal is proposed.
On a sponsored path: where a programme need is real and durable enough to justify the authorization work, that is a conversation about sponsorship, timeline and cost — with the honest note that this is a long path with no guarantee of outcome, and no capture should depend on it completing.
And the shape that is closed: acting as an authorized cloud service in a position requiring authorization. There is no version of that we will agree to, including on a bid where somebody believes the risk is acceptable.
The first thing owed is the disqualifying fact, unprompted and early. A teammate who lets a prime discover a limitation during proposal review has transferred their problem to somebody with less time to solve it, and doing that once ends the relationship correctly.
The second is claim discipline on your bid. Every representation we make in a technical volume should be narrow enough that an evaluator can verify it. Where we cannot support a claim, we will say so before it is written rather than after it is challenged.
The third is documentation on your calendar. Capture timelines are not negotiable and a teammate who treats them as if they were is a risk regardless of capability. Where an artefact does not exist, the honest answer is that it does not exist, delivered early enough for you to decide what to do about it.
And operational access is not permission to train. Programme data does not become material improving anything serving another organisation, including another prime.
A written statement of our assurance position, in language that can go into a teaming file without being reinterpreted. It says what is held, what is in progress, and what is not held at all, using a status vocabulary narrow enough that "designed for" cannot be read as "audited against".
A written statement of scope limitations, including the position we will not occupy. That document exists so a compliance lead can decide quickly rather than through a sequence of calls.
And representations we can actually stand behind. If a required representation is one we cannot make truthfully, the correct outcome is that we are not on the bid — and telling you that during teaming is worth more than an accommodation that fails at evaluation.
A scoping conversation against a specific solicitation or programme, aimed at determining within one call which of the three shapes applies — or that none of them does.
The output of that conversation should be a decision rather than a follow-up. Bring the requirement that concerns you and we will tell you whether it closes the door, and if it does we will say so rather than propose a path around it.
If a shape is viable, the next step is small and non-federal: prove the working relationship on internal or commercial work before anything appears on a bid. A teammate you have not worked with is a risk on a proposal regardless of what the documentation says.
And if you are early enough that the solicitation is still a draft, the useful thing is the written limitations statement, filed now, so the question does not have to be re-asked under deadline later.
On many bids you should not, and the fastest thing we can do for your capture is tell you which those are. Where it makes sense is a position where your authorization is the one in play — delivery inside a boundary you already hold — or on portfolio work where the requirement does not attach. If the solicitation requires an authorized service in the position being proposed, the answer is that we are not a candidate, and you should get that in the first call.
Correct, which is why the page does not say it. The claim here is that no authorization and no equivalency is held, full stop, and no path is offered as though it were an outcome. If a programme need is real enough to justify sponsoring that work, that is a specific conversation with a timeline and a cost and no guarantee — and no capture should be built on it completing.
That is the failure this page is organised to prevent, and the mechanism is narrowness: every representation should be small enough that an evaluator can verify it against something. Where a claim cannot be supported, we will say so before it is written into a volume rather than after it is challenged. Ask for the written limitations statement early — it exists specifically so a compliance lead can decide without a sequence of calls.
They do, and they are a separate conversation that should not be blended with the technical one. Whether we help with a particular goal depends on our status at the time and on the specific requirement, and it is a question to answer factually and early rather than to imply. Capability fit and socioeconomic fit are two independent tests and a teammate should pass or fail each on its own terms.
The administrative and management flow around it: where deliverables and action items sit, what they are waiting for, what has aged past its own threshold, and what evidence exists for each action taken with the authority under which it was taken. That is a narrow claim and deliberately so. It is not a mission system, we will not describe it as one in a volume, and if the programme need is a mission system then we are not the teammate for it.