The Dev Agency and Bench Admission Standard: Engage, Trial-Only, or Decline

This standard is for the engineering manager, technical founder, or sourcer who has a shortlist of outsourced development or staff-augmentation firms, each offering a bench of named engineers, and has to decide before anyone gets repo access which firm to sign, which gets only a scoped paid trial, and which to turn down. It sets a pass criterion for each public-evidence check on the firm and on every named engineer. It says what each piece of evidence proves and how it gets faked, and it maps every failed criterion to a fixed verdict. What you get is a verdict plus a filed evidence sheet. A second reviewer working from that sheet should reach the same verdict.

What does the admission standard decide?

It gives exactly one verdict, Engage, Trial-Only, or Decline. The verdict covers one record: the firm, its payee entity, its named engineers, and the proposed contract, all graded together. A firm that passes while its bench fails gets no verdict of its own, and the same goes for a bench that passes while the firm fails.

Terms used throughout:

• Staff augmentation: the vendor supplies engineers who work inside your team under your direction, instead of delivering a scoped project.
• Bench: the named engineers the vendor proposes to put on your work.
• Payee entity: the legal entity that actually receives your payments. It can differ from the entity that signs the contract.
• Front company: an entity set up to look like an ordinary IT services firm while hiding who controls it or who does the work.
• Proxy: a person who stands in for someone else at account creation, at interviews, or in person.

The three verdicts:

• Engage: sign the contract. Access follows your normal onboarding.
• Trial-Only: a scoped, paid trial in a sandbox repo with no production access. The trial exists to close named gaps in the evidence. When it ends, the firm is regraded.
• Decline: no contract and no trial. The reason is recorded so the firm can't simply resubmit the same record.

This standard does not replace a legal sanctions determination, and it does not assess code quality. It answers a narrower question that comes first: is this firm who it says it is, and are these engineers the people who will do the work?

Why grade the firm and its bench as one record?

The people who sell you an outsourced firm are mostly not the people who will build your software. So evidence about the firm says almost nothing about the bench, and evidence about the bench says almost nothing about the firm.

Source: Refolk's index. The four engineer-family mismatches had top titles of Founder, CEO, Web Designer, and BD executive.

The ratio exists because sales staff put the vendor's marketing phrase in their headlines and engineers don't. If you search on the vendor's own terminology, you map the sales team. Even the 13 "engineer" matches are unreliable, since 4 of them carry non-engineering titles. This is the mechanism behind the bait and switch with senior developers: the record you're shown on the call is built by people who won't touch your code.

That changes how you look. Search for engineers at the named firm by role, stack and tenure, not by the firm's sales vocabulary. Refolk takes that request in plain English and returns profiles joined across GitHub, LinkedIn and the open web, so you see the firm's actual engineering population next to the bench it proposed.

Grading the record as a whole also fixes the other common problem with agency checklists. They hand out weighted scores, and two reviewers weight things differently. This standard has no weights. Every criterion is Pass, Fail, or Not established, and fixed rules turn those grades into a verdict.

The admission criteria: what each check proves and how it lies

The record has nine criteria: six on the firm (C1 to C6) and three on each named engineer (E1 to E3). Each one has a pass condition you can grade from evidence, and each has a known way of looking like a pass when it isn't.

Firm criteria

Engineer criteria

What each piece of evidence actually proves

Evidence gets stronger the closer it gets to the specific person doing the specific work. Most of what vendors put in front of you sits in the outer layers.

The government advisories point to the same split. The OFAC, State and FBI advisory on DPRK IT workers and the later joint alert from agencies in 11 countries list many red flags. Four of them can be checked before signing: names on sanctions lists, domain age against claimed history, rating clusters, and a mismatch between payee and entity. Video presence and location can only be checked after contact. That is why C1, C2, C4 and C6 come first in the procedure and E3 continues after signing.

How to grade: the verdict rules

The verdict follows from the grades and nothing else. Any hard-gate failure is a Decline. Any other failure, or any criterion left Not established, caps the firm at Trial-Only. Engage requires every criterion to pass.

How the edge cases resolve:

• An engineer fails E1. That engineer comes off the bench and the firm is capped at Trial-Only. The rest of the bench is graded without them. A proposed replacement is graded from scratch.
• The vendor offers to fix something. Grade what is on paper at grading time. If the vendor fixes the payee or the contract, regrade the new paper. Don't grade a promise.
• A Trial-Only firm finishes its trial. Regrade only the criteria that were Fail or Not established. If they now pass, the verdict is Engage. If any still fail, the verdict is Decline. There is no second trial.

This rule is what makes two reviewers agree. Most disagreement in vendor vetting comes from one reviewer filling a gap with goodwill and another refusing to. Taking that discretion away keeps it from creeping back into the verdict.

The admission procedure, step by step

Eight steps, in a fixed order. The cheap desk checks that can produce a Decline come first, and the slow client contact and live controls come after. The firm-level desk work takes about three hours. Each engineer adds 30 to 60 minutes, and client confirmation adds 1 to 5 days of waiting.

Notes on the steps that need judgement

Step 1. Screen every entity, not just the name on the website. The front-company pattern relies on a legitimate-looking selling entity with a different payee behind it. OFAC has designated a Chinese entity, Shenyang Geumpungri Network Technology, as a DPRK front company. For UK engagements, OFSI publishes its own advisory on North Korean IT workers.

Step 2. Front companies copy the signals of a legitimate firm. The DOJ seized 17 domains designed to appear as domains of legitimate, U.S.-based IT services companies. Two China-based firms, Yanbian Silverstar and Volasys Silverstar, employed at least 130 DPRK IT workers and generated at least $88M over about six years. A domain registered after the firm's claimed founding year, with no archived site and no documented rename, is a hard-gate Fail.

Step 4. No neutral source publishes a procedure or a confirmation rate for case-study clients, so this standard defines the procedure: reach the client through its own website, switchboard or published contact address, and ask a yes/no question. A reference contact the vendor supplies doesn't count, because the vendor chose it.

Step 6. Grade the engineers by the people they are, not by the firm's name. You're looking for named people at a named firm with a specific stack, and that is the query to run:

For step 5, the same approach shows departures. Asking Refolk for a firm's former employees who left in the last 12 months, along with their current employers, gives you a departure count without relying on the vendor's own headcount claim.

The evidence sheet

File one sheet per firm. The second reviewer grades from this sheet alone.

FIRM:
CONTRACTING ENTITY:
PAYEE ENTITY:
PARENT:
DIRECTORS:
REVIEWER / DATE:

C1 Sanctions and registry | Pass / Fail / Not established | entities screened + timestamp | incorporation date
C2 Operating history | Pass / Fail / Not established | domain registered | earliest archive | claimed founding
C3 Named client | Pass / Fail / Not established | client | channel used | date confirmed
C4 Review provenance | Pass / Fail / Not established | verified count | not verified count | cluster dates
C5 Headcount and tenure | Pass / Fail / Not established | engineering headcount | departures noted | builds software Y/N
C6 Payee | Pass / Fail / Not established | payee = contracting entity Y/N

ENGINEER:
E1 Identity | Pass / Fail / Not established | profiles compared | conflicts
E2 Footprint | Pass / Fail / Not established | repo | commit email match Y/N | stack match Y/N
E3 Interviewee = worker | Pass / Fail / Not established | image capture dates | match Y/N

CONTRACT: replacement timeline | named-engineer clause | IP vests on | interview rights
HARD GATE FAILED:
ANCHOR TEST:
VERDICT: Engage / Trial-Only / Decline

The client confirmation message

Subject: Quick yes/no on a vendor reference

Hello,

I am evaluating [firm name] as a software development vendor. They list your organisation as a client for [project description, as the vendor states it].

Could you confirm with a simple yes or no whether your organisation worked with them on this? I am not asking for details of the work or any opinion of the vendor.

If this is the wrong inbox, I would be grateful for a pointer to the right one.

Thank you,
[name, title, company]

How this standard goes wrong: failure modes and false positives

Each check below can pass while the thing it is meant to prove is false, and each has a counter-check. Most of a bad admission decision comes from these, not from skipping steps.

A Verified review is read as a verified project

On Clutch, a reviewer must log in through LinkedIn, Google or a company email, and software compares their digital footprint with what they typed into the form. That proves who the reviewer is. It doesn't prove the project happened. Clutch reports rejecting about 10% of submitted reviews for signs of falsified information, and it still displays reviews it couldn't confirm, labelled Not Verified and excluded from the score. So a raw review count overstates the evidence. At least one website sells Clutch reviews and advertises a 96.8% "analyst-verified rate". Clutch hasn't published what share of its reviews are unverified, so check the labels on each profile yourself.

Counter-check: count only Verified reviews. Fail C4 if the majority of them landed in one short window, or if no reviewer's company appears on the firm's client list. The OFAC advisory names a related pattern: several developer accounts getting high ratings from one client in a short period.

A verified review proves who wrote it. It does not prove the project happened.

The firm-level badge is read as a vetted bench

A third-party source says phone-based reviews are only available to agencies that pay for certain listing products. That claim hasn't been confirmed against Clutch's own pages, so don't rely on it either way.

The industry tag counts the wrong employers

Firms tagged "IT services" or "outsourcing" in public profile data include BPO and publishing-services companies. In the sample below, the top employer among Indian matches was Minacs, and Scientific Publishing Services also appeared.

Source: Refolk's index, Senior Software Engineers at firms tagged IT services or outsourcing. Percentages are derived.

Counter-check: for C5, confirm the employer actually ships software before you count its headcount as engineering capacity. Also look at concentration. When 43% of a small country sample sits at one firm, that firm's profile hygiene dominates the result.

Title drift on a correctly matched engineer

A profile can come back for the right firm and still show a current title that isn't engineering. Among the 7 Ukraine matches above, one profile's current title is "Junior Sergeant" at the National Guard of Ukraine. Roughly one profile in seven in each sample lacked an exact title match. That could be a stale profile, a second job, or a borrowed identity, and the profile alone won't tell you which.

Counter-check: E1 needs the current title, dates and stack to agree across every profile. A conflict is a Fail for that engineer, whatever the explanation.

An empty GitHub graph, or a full one

Private contributions are hidden by default, and when an engineer opts in they are completely anonymized. Commits are attributed to a profile through the commit email. An engineer whose client work is all private therefore looks empty, and nobody has published how often that happens. A full graph is no better as proof of identity: the advisories describe workers using legitimate professional networking accounts belonging to others.

Counter-check: grade E2 on commit emails on repos the firm credits to a client, not on the contribution graph. If none exist, grade E2 Not established and use the trial for an observed work sample.

The interview is treated as identity proof

The FBI warned: "Sometimes an individual is employed to pass the initial interview, but the on-the-job work is completed by a different individual." The joint alert says workers use proxies to create accounts, sit interviews and even make in-person contact, and that they often try to avoid being paid by direct deposit. The OFAC advisory adds that one client account and one developer account sharing a single payment account means the developer is paying themselves. It also flags the same document templates turning up across different developer accounts.

Counter-check: E3 needs images captured at the interview and compared with images from later meetings. C6 needs the payee to be the contracting entity. Neither can be replaced by a better interview.

Bench stability and the contract terms that must hold

Expect the bench to change. Even at the best attrition rate the large firms report, a four-engineer bench is close to a coin flip for staying intact over a year, so the replacement and named-engineer clauses decide what you actually get.

Source: attrition rates as reported for Infosys and Wipro. Survival math is derived and assumes independent, constant-rate departures.

The large Indian IT firms report 12 to 14% voluntary attrition. Wipro reported 13.8% in one quarter while its headcount fell by 6,716. A Gartner analyst said "20-30 per cent attrition rates are not sustainable". No one has published a tenure threshold you can read off public profiles. So C5 grades the trend you can see (stable or growing engineering headcount, departures you can account for) rather than a number, and you should write down any local threshold you adopt.

Contract terms the record must contain

No neutral industry body publishes a staff-augmentation contract standard, and every source on this is written by a vendor. Where those vendors agree, treat it as the floor:

• Replacement: the first replacement is free and arrives within 10 business days. "Replacement guaranteed" with no timeline fails.
• Named engineers: the engineers you interviewed are the engineers who work. A substitute goes through E1 to E3 before starting.
• Interview rights: you can interview every proposed engineer and every replacement.
• IP assignment: IP vests on creation (the position of Bluelight and BEON) or on payment (which Axented calls acceptable). IP that vests when the vendor declares the project complete fails. Axented flags this as unacceptable.
• Termination: 30 days' notice or less.

If any of these terms is missing, the contract fails and the firm is capped at Trial-Only until the paper changes.

Keeping the verdict current

A verdict describes the record on the day it was filed. Regrade the affected criteria whenever the record changes, and recheck the hard gates on a fixed schedule even when nothing seems to have changed.

Regrade when:

• The bench changes. Every replacement goes through E1 to E3 before getting access.
• The payee or contracting entity changes. Rerun C1 and C6 before paying the next invoice.
• Images stop matching. A mismatch in the ongoing E3 capture is a hard-gate failure on the live engagement. Suspend access and regrade.
• A Trial-Only trial ends. Regrade only the open criteria, then record Engage or Decline.
• Sanctions designations or advisories are updated. Rerun C1 against the current designations and read the new red flags against your E3 and C6 controls.

Where the evidence base is thin, this standard says so in the verdict rules rather than hiding it. Nobody has published a client-confirmation rate, a false-negative rate for private GitHub work, or a public-profile tenure threshold. If your team builds local data on any of these, write the threshold into this standard as policy and date the change.