
A subcontracted build reads as your team's work only when the brief holds four things the other firm can obey without asking you. The product's vocabulary, including what it refuses to say. The structure of the code, rather than the names of the variables. The acceptance sentence you already sold, including an accessibility level if you sold one. And a model voice that lives in your repository, which you can re-score with the subcontractor out of the room. A Figma file and a Slack thread are how a second firm's habits become the thing your client can see.
Cosmetic instructions fail because authorship is not in the cosmetics. Caliskan-Islam, Harang, Liu, Narayanan, Voss, Yamaguchi and Greenstadt showed that source code carries a fingerprint that survives the obvious clean-up (Caliskan-Islam et al., De-anonymizing Programmers via Code Stylometry, 24th USENIX Security Symposium, 2015). On the hard version of the test — 250 programmers from the 2014 Google Code Jam, each with nine solutions to the same set of problems, the easiest nine, so the classifier could not cheat by recognising which problem it was looking at — a random forest on their code-stylometry features reached 91.78% accuracy. Keeping only the features with information gain raised that to 95.08%. A mixed-year sample of 250 programmers, nine files each drawn across different problems, reached 98.04%, and the authors write that this figure may be higher because the mix includes properties of the solutions as well as of the programmers. Use 95.08%. It is the number from the test where everyone did the same job.
What the classifier used is the part an agency can specify. Of about 120,000 features, 928 carried information gain. 44% of those were syntactic, 1% were layout, and the rest were lexical. Layout is spaces, tabs, and where the brace sits. That is the 1%. An off-the-shelf obfuscator that renamed functions and variables, stripped comments, and removed whitespace, while leaving the structure of the program alone, "produced little detectable change" in accuracy on a sample of 20 programmers (same paper, section 4.3.3). Their stronger tool, Tigress function virtualisation, did cut information-gain accuracy, from 95.91% to 67.22% on 20 programmers, and the authors note the result is neither readable nor maintainable, and about nine times slower. A brief that says "use our naming" attacks the slice that does not identify anyone. A brief that specifies how a module is cut, what a function is allowed to do, and which error shape is legal is specifying the syntactic habits the classifier was reading.
Hold the study to what it measured. These are Google Code Jam solutions, short contest programs in C and C++, on the order of 70 lines, not a React application under a client's design system. The authors also report that the same approach applies to Python. It is not a measurement of your repository. It is a measurement that, when people solve the same problem, style is still enough to tell them apart, and renaming is not a disguise. Contest code is the generous case for a brief, because the problem was identical. A real product gives the second firm more room to be visible: the tasks differ, and the authors' own account of the 98.04% result is that solution properties leak into the fingerprint alongside style. Hiding the author by editing names is the intervention their weak obfuscator already failed.
The first object in the brief is vocabulary, and it is shorter than a brand book. What the product is called. What a customer is called. The words the client has asked you never to use. What a wrong answer is, in one sentence the subcontractor can score against. If the client's users say "load" and the model says "shipment," the client does not need a classifier. Write the list. Ten lines is enough. A forty-page voice document that nobody opens is how the default voice ships, and the default voice is the other firm's.
The second object is structure. Name the module boundaries, the shape of an error, the test that must exist before a change merges, and the places a new file is not allowed to appear. This is the syntactic brief. It is also the only brief a new engineer on your own payroll could follow, which is the test: if a hire who has never met the subcontractor cannot produce a change that passes review, the brief is a vibe and the fingerprint will be theirs. Dedicated team or staff augmentation is the purchase sitting under this paragraph. Staff augmentation drops a person into a method you already operate, so this brief is that method, written down. A dedicated team is the case where you do not have a lead directing the work every day, which is when an unwritten method gets replaced by the one they brought with them.
The third object is the acceptance sentence you already sold, copied into the subcontract without softening. If you sold a performance bar, an accessibility level, and a runbook, and the subcontract says a merged pull request, you bought less than you sold, and the gap shows up in the client's review. The Web Content Accessibility Guidelines make that sentence writable, because the success criteria are testable on purpose. The W3C states that they exist "to allow WCAG 2.2 to be used where requirements and conformance testing are necessary such as in design specification, purchasing, regulation, and contractual agreements," at three levels — A, AA, and AAA — and that Level AAA "is not recommended" as a general policy for entire sites, "because it is not possible to satisfy all Level AAA success criteria for some content" (W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation). WCAG 2.2 adds nine success criteria, and the specification names them: Focus Not Obscured (Minimum), Focus Not Obscured (Enhanced), Focus Appearance, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry, Accessible Authentication (Minimum), and Accessible Authentication (Enhanced). "AA, including the nine WCAG 2.2 added" is a sentence a reviewer can fail. "Make it accessible" is a mood. If you sold no accessibility level, do not invent one in the subcontract to look thorough. Write that none was sold, so none is owed.
The fourth object is the model voice, and it is the one agencies leave in the subcontractor's account. The system prompt, the examples, and the score you re-run belong in your repository, not in a chat transcript on someone else's laptop. You should be able to run the score with the subcontractor out of the room and get the same failures. What to keep when you subcontract AI is the vendor account, the production keys, and the golden set. This article is the brief that tells them what "sounds like us" means, so that set has a tone to score rather than only a fact to check. If you cannot write ten examples of a good answer and three of a bad one, you do not have a voice yet. You have a hope that their default will pass for yours, and their default is a fingerprint a client can hear in one conversation.
Clients do not read abstract syntax trees. They read the empty state, the error, and the sentence the assistant uses when it refuses. Those strings are lexical, which is the largest slice of the features that carried information gain, and they are the slice a non-engineer can see in one sitting. Give the subcontractor the strings themselves. The empty state. The error. The refusal. The subject line of the email the product sends. A product with one vocabulary is what a shared workspace has to be anyway. Gigbase, an agency operating system we built put agencies, admins, and team members in one permission model, with an assistant that admins train on their own help content, because the words and the permissions constrain each other. That engagement is direct work, under the client's name. Agency subcontracts stay off this site, under the same non-disclosure we would sign with you. The shape is the point. Nothing in it is a headcount or a duration.
The brief is not the contract, and it is not the price. What belongs in a white-label subcontract is the paper: assignment, non-solicit, who may speak to the client. The brief is the specification that paper does not contain. A price can be right and the work can still arrive in another firm's voice, and you will pay, inside the margin you thought you had, to rewrite it before the client does. Disclosure is a separate decision, and it is yours. Some agencies tell the client there is a second firm. Some do not. A white label software development partner can work either way, under your domain and your tools, or with an introduction you choose to make. If you disclose, you still want one product, so the vocabulary, the acceptance sentence, and the voice stay in the brief. What you can drop is the demand that a second author be invisible inside the code. If you do not disclose, you cannot drop the structure. That is the part a technical reviewer on the client's side can see without being told a second firm exists.
Three situations where this brief is the wrong document. You are placing a person into the client's repository under their lead. Their method is the brief, and writing yours on top of it is how the client sees two styles and holds you responsible for both. The client has asked to meet the people doing the work. Give them the meeting. A disguise that contradicts a meeting fails in the meeting. And you have no house style of your own. A style invented the week the subcontract starts is a third fingerprint — yours, theirs, and the document's — and the client is who notices that the product suddenly has a new voice. In that case the first week is spent writing the four objects from work you have already shipped, or telling the client the team is new. Asking a subcontractor to invent your firm is how both of you become visible.
Someone who did not write the brief, and did not write the code, has to read the diff against the four objects before the client sees the build. If the person who sold the work is the only reviewer, the review happens between calls, and the second firm's defaults ship because nobody had the afternoon. Name the reviewer in the brief. Give them the ten example answers. Give them the module rules. A brief with no named reader is a memo.
Before kickoff, read the brief against one change you have already shipped and would show a client. If that change would fail the brief, the brief is a fantasy and the subcontractor will fail it in public. If you cannot find a change that passes, you are buying a second product and hoping the client calls it the first. Our pricing publishes the model and not a rate, because the rate is not what makes the work yours. The four objects are. Write them down, put them in the repository the subcontractor commits to, and keep the copy that lets you score the voice after they have logged out.
Find this useful? Tell Google to show you more of it.
