The Masked Relationship Model requires offshore teams to produce high quality deliverables that appear authored entirely by the prime. That invisibility preserves the prime’s brand and reduces the risk of compliance problems or disqualification in SLED procurements. In practice the model means offshore contributions are internal only, never shown to evaluators, and never traceable through document metadata or communication logs.

• Evaluator clarity matters. Evaluators must perceive a single, unified authorial voice across the proposal, not multiple contributors. Agencies often expect the prime to be fully accountable for the submission. - Compliance risk is real. Metadata, tracked changes, or visible subcontractor mentions can trigger reviews or disqualification. - Brand and relationship protection are critical. The prime’s reputation and future work depend on consistent tone, formatting, and ownership of outputs.

• Zero visibility: never appear in final documents, client-facing emails, or submission portals. - Attribution control: remove author names, comments, and tracked changes before any handoff. - Metadata cleaning: clear document properties, hidden fields, headers, and PDF metadata and validate with prime tools when available. - Prime identity shielding: adopt the prime’s voice, vocabulary, and formatting so deliverables read as internal work. - Internal-only workflows: deliver only to the prime’s proposal manager or capture lead, not directly to clients.

1. An offshore writer drafts the technical approach in the prime’s approved template. 2. The writer runs the metadata checklist, accepts or rejects tracked changes, deletes comments, and re-saves a clean copy. Validate with the prime’s scanning tool if provided. 3. The writer sends the clean file to the prime’s proposal manager only. The prime integrates the content, adjusts voice if needed, and handles final submission. 4. The prime performs the final export to PDF and uploads to the portal, ensuring no residual metadata or edit histories are exposed. This sequence prevents accidental visibility at submission stage.

RSP: Remote Service Provider, use freely in internal communications between offshore staff and the prime, never in documents sent to evaluators or the client. SLED: State, Local, and Education, the government market segment for many proposals. Use in internal planning and status reports; avoid placing SLED as shorthand inside final proposal narratives that evaluators read. DES: Washington Department of Enterprise Services, cited as an example of state-level expectation for unified authorship. Refer to DES in internal research or prime briefings where agency rules are discussed. CDT: California Department of Technology, a common SLED authority with strict subcontractor visibility rules; keep references to CDT internal unless the prime authorizes inclusion. DIR: Texas Department of Information Resources, known for checks that can flag metadata inconsistencies; treat DIR guidance as operational constraints when preparing submission files. OGS: New York Office of General Services, often cited for requirements that proposals appear authored by the prime; use OGS examples during voice calibration and template setup.

Internal-only context: Use these abbreviations in shared workspaces, chat threads with the prime, and internal checklists. Keep a short glossary file attached to internal folders so every offshore contributor uses the same terms. Client-facing content: Replace abbreviations with full, prime-approved wording or remove them entirely from evaluator-facing narratives, resumes, org charts, and past performance entries. Attribution control requires that no offshore references appear in final deliverables. Metadata and submission checks: Even if an abbreviation is removed from visible text, it can persist in comments, tracked changes, or properties. Run the prime’s metadata-cleaning checklist before delivering any file.

Internal handoff: Create a single internal brief that lists RSP, SLED, and the applicable agency acronym (for example, DES). Mark the brief InternalOnly and circulate it on the prime-approved channel. Use the glossary to ensure consistent usage across writers. Preparing an evaluator-facing deliverable: Convert internal drafts into the prime’s template, remove all abbreviations or expand them per prime style, accept or reject tracked changes, delete comments, and export a clean copy for validation. Use the metadata checklist to confirm no hidden fields remain.

Memory aid: Flashcard prompt — front: “RSP”; back: “Remote Service Provider, internal only in client-facing contexts.” Review daily during proposal week. Immediate checklist (3 items): 1) Confirm glossary terms appear only in InternalOnly files, 2) Run metadata-cleaning tool and validate with the prime, 3) Ensure final copy uses prime wording not offshore shorthand.

Use the glossary as your source of truth, keep abbreviations confined to internal channels, and always validate files through the prime’s submission workflow before anything leaves the internal environment.

Offshore teams must avoid any direct client-facing presence and any trace in submission metadata; common expectations include never appearing in proposal documents, email threads, client communications, or submission metadata. Practically, that means all deliverables flow only to the prime point of contact, not to clients or portals, and RSPs must cease work at the point the prime takes over submission tasks. These boundaries reduce visibility risk and make the prime the single accountable author for evaluators and agencies.

Primes own client relationships, final editing, submission logistics, and compliance certification, while RSPs provide draft content, analyses, and internal tools that stay internal-only until the prime integrates them into prime-branded artifacts. For RSPs, the implication is a shift from delivering polished, client-facing files to delivering clean, attribution-safe work products and clearly labeled internal drafts for prime review, following the prime’s templates and voice calibration guidance.

Metadata cleaning and attribution control become mandatory responsibilities. Before any handoff, RSPs must clear document properties, accept or reject tracked changes, delete comments, inspect hidden fields, and resave as a clean copy so files pass prime validation tools. RSPs must also avoid using offshore templates or external file sharing links and must never forward documents directly to clients because small metadata leaks can trigger compliance reviews or disqualification.

Because the prime must appear as sole author, primes will expect tight voice and formatting alignment, fast turnarounds for edits, and strict adherence to revision rules; mismatched tone, inconsistent formatting, or delayed responses increase visibility risk and can harm the partnership. RSPs should establish an agreed escalation path for uncertain cases and a short feedback loop with the prime’s proposal manager to resolve voice or attribution concerns quickly.

Use prime-approved templates and voice only. Match the prime's formatting, terminology, and tone so deliverables read as if created by the prime. Primes expect exact brand and stylistic alignment when offshore teams contribute to content.

Keep work internal and draft-only. Matrices, working notes, and analysis must remain internal, not inserted into final deliverables or submission artifacts.

Always remove metadata and hidden traces before any handoff. Clear document properties, remove author fields, accept or reject tracked changes, delete all comments, inspect headers/footers and embedded objects, then save a clean copy. Many primes require a final metadata scan or prime tool validation before acceptance.

Route all deliverables only through the prime. Send work to the prime's proposal manager or capture lead, not to clients or public portals. Avoid direct client emails, joining client calls, or uploading to submission systems from offshore accounts.

Practical checklist to follow before any external handoff: 1. Convert work into a prime-branded template and apply the prime's voice. 2. Accept or reject all tracked changes. 3. Delete all comments and review hidden fields. 4. Clear document properties and author metadata. 5. Save as a new, clean file or export to a format required by the prime. 6. Run any prime-supplied metadata scanner or validation tool and fix flagged items. 7. Rename the file to the prime's naming convention and deliver only to the designated prime contact via the approved internal channel.

Clear title, author, company, last saved by, and other document properties. These items can reveal contributor names and organizational traces, and must be removed before delivery. The course checklist highlights clearing properties and revision history as a required step to prevent metadata leakage.

Accept or reject all tracked changes and delete all comments, including those in headers and footers. Resolved or hidden comments can still contain names or notes. The checklist lists accepting or rejecting tracked changes and deleting comments as mandatory actions.

Inspect headers, footers, text boxes, embedded Office objects, and hyperlinks for hidden text or fields. Remove or replace embedded objects that carry author or path information. The checklist warns that hidden fields and embedded objects often contain metadata and must be inspected.

Save a fresh copy after cleaning. Exporting or saving as a new file reduces the chance of stray revision history carrying over. The checklist recommends re saving as a clean copy before validation.

Avoid direct uploads or final submissions from accounts that reveal offshore contributors. Cloud version histories and sharing logs can expose edit histories. Where possible, hand a cleaned file to the prime for final upload through the prime's account, so submission records show only the prime. The materials treat version history exposure and upload permissions as critical risks to manage.

Only named prime staff handle client contact and submissions. All offshore contributors report to a designated prime proposal manager or capture lead, not to clients. The prime manages client relationships and all submission logistics, so offshore teams never act as client-facing representatives.

Send nothing to clients. All deliverables, questions, and draft materials go to the prime contact only. Do not forward documents, calendar invites, or meeting notes to client addresses. The course materials list emailing clients and joining client calls as prohibited actions.

Do not accept calendar invites from clients. If a client sends an invite that includes offshore participants, decline and notify the prime immediately. The prime will reissue any required meetings, or supply a prime point of contact to represent the team.

If accidentally included on a client email or invite, take these steps in order: 1) Do not reply to the client, 2) Immediately notify the prime contact with a screenshot and timestamp, 3) Remove yourself from the thread or calendar entry, 4) Follow any corrective actions the prime requests. Prompt reporting is essential so the prime can remediate and preserve compliance.

Read three representative prime documents aloud, or use a text-to-speech tool. Note these concrete features: average sentence length, frequency of short sentences, preference for compound or simple sentences, punctuation patterns (commas, semicolons), whether the prime favors active or passive constructions, and common sentence openings such as "However," "In addition," or plain nouns. The guidance for voice calibration highlights mirroring sentence rhythm and studying past deliverables as a benchmark for style matching.

1. Collect samples: pick two final, client-facing proposals or narratives that the prime used. 2. Measure rhythm: compute average sentence length by counting words in 10 randomly chosen sentences from each sample. 3. Capture patterns: list three common sentence openings, two frequently used transition words, and whether the tone is formal, conversational, or technical. 4. Create three short rules: one for sentence length (for example, "70 percent sentences 12 to 20 words"), one for punctuation habits, and one for voice (for example, "use active voice for task descriptions"). 5. Keep the guide visible when drafting, and add examples from the prime to illustrate each rule.

• Mirror sentence length distribution, not exact wording. If the prime mixes short emphasis sentences with longer explanatory sentences, reproduce that mix. - Read drafts aloud to match cadence. If your wording feels staccato where the prime is flowing, combine or split clauses until the rhythm aligns. - Copy structural habits, such as where the prime places bullets versus integrated sentences, and how many sentences typically appear before a bullet list. - Use the prime's exact transitions and preferred terms. Swap in approved terminology rather than offshore phrasing. - Run a blind read by a colleague who knows the prime's samples but not the author. If they think the text could come from the prime, the rhythm match is effective.

• Sentence length distribution aligns with prime samples. - Common transitions and openings match prime usage. - Paragraphs contain the same mix of short and long sentences. - Vocabulary swaps use prime terminology. - A quick read-aloud confirms cadence consistency.

Make mirroring a routine step, not an afterthought. Build a small library of prime examples and a two to three rule micro-style guide for each prime contractor. Regularly validate rhythm with a blind read by someone familiar with the prime's voice. Consistently matching sentence rhythm supports a unified voice and reduces visibility risk for offshore teams, a core aim of voice calibration techniques.

Matching vocabulary means selecting the exact words, labels, and short phrases the prime uses for concepts, roles, and deliverables. Prefer the prime’s name for programs, teams, processes, and technology, not an offshore equivalent. Vocabulary alignment is part of following the prime’s templates and past deliverables as voice benchmarks.

• Collect the prime’s style guide, glossary, and any brand or proposal templates before drafting. These sources are primary evidence of preferred terminology. If a formal guide is not available, request sample proposals or previously submitted sections to study.
• Build a short, searchable glossary that maps offshore terms to the prime’s chosen terms. Keep entries concise, for example: offshore term, prime term, where it appears (e.g., personnel bios, solution description), and one short usage note.
• Add the glossary to your team’s working folder and require reviewers to check new language against it before delivering work to the prime.

• Synonym substitution. Avoid swapping in synonyms that feel natural offshore but differ from the prime’s usage.
• Literal translations. If a term is translated inside the offshore team, prefer the prime’s original term.
• Overcorrection. Do not invent new prime-specific terms. Confirm uncertain terms with the prime contact rather than guessing.

• Confirm all role and deliverable names match the prime glossary or samples.
• Run targeted find-and-replace for known offshore-to-prime mappings.
• Ask a prime reviewer to sign off on any uncertain terminology before the final pass.
• Validate output in the prime’s template so visual context reinforces vocabulary choices.

1. Clear document properties and metadata. Remove author, company, device identifiers, and any revision history stored in document properties. Use the application’s Document Properties or Info panel to remove these fields, and check for embedded metadata in objects. 2. Accept or reject all tracked changes. Ensure no tracked edits remain visible or discoverable. After accepting or rejecting, save a new copy to avoid carrying hidden markup forward. 3. Delete all comments and annotations. Remove comment threads and any resolved comment text. Even resolved or hidden comments can include offshore names.

Inspect headers, footers, and embedded objects. Check for names, initials, hidden text boxes, embedded spreadsheets, templates, or images that may contain identifying information. Clear or replace any such content with prime-approved elements.

Convert to PDF correctly and then recheck. PDF exports often retain author or device metadata and sometimes embedded comments. After exporting, inspect PDF properties and remove or sanitize any remaining metadata before delivery.

Validate with prime-approved tools. If the prime provides a metadata scanner or checklist, run your file through it and resolve anything flagged before delivering the file to the prime’s proposal manager.

Open Properties and confirm no offshore names appear. Verify no visible or hidden comments, no tracked changes, and no author fields. Confirm file name follows prime rules and contains no offshore identifiers. Ensure only the prime uploads final materials to client portals.

Delete author, company, and device information from the file properties or document inspector. These fields often carry the clearest identifying traces.

Remove or purge version and revision metadata so the file does not reveal the RSP workflow or timestamps.

Ensure no markup remains in the final deliverable; even hidden markup can expose editors or comments.

Run the prime’s metadata scanner or follow their validation checklist before handing the file upstream.

Treat metadata cleaning as a required gate before any external-facing delivery, not an optional cleanup task. Metadata leakage can trigger compliance reviews or disqualification in SLED procurements.

• Headers and footers: Running headers can contain author names, file paths, or draft notes. Double click to view them rather than relying only on property cleanup.
• Hidden text and content controls: Authors can hide text or use content controls that stay invisible in normal view. Use the editor view that reveals hidden text.
• Embedded objects and OLE items: Charts, spreadsheets, and inserted documents often carry their own metadata and revision history. Open each embedded item and inspect its properties.
• Form fields and document variables: Forms, fields, and bookmarks can embed values tied to a user or system. Check field codes and form settings.
• Images and attachments: Photos and inserted files can include EXIF or author info. Inspect image metadata and any attached files.
• Macros and scripts: Macros can embed author comments or external links. List and review macros, and remove or disable them if not needed.
• PDF hidden layers and attachments: PDF exports can retain metadata, invisible layers, comments, and embedded files. Use a PDF tool that scans hidden content.

1. Reveal invisible content in the source file. Use View options to show hidden text, and switch to Draft or Outline view to surface content controls and fields.
2. Inspect headers and footers manually. Search for email addresses, local file paths, or draft labels. Replace or blank any identifying items.
3. Open every embedded object. For each chart or inserted document, choose to open the source object and check its document properties and comments. Remove or sanitize metadata within the embedded item.
4. Review macros and form fields. Export a macro list and remove any personal identifiers. Convert form fields to static text where possible.
5. Save a copy and export to PDF. Use the PDF application s remove hidden information or sanitize feature to detect lingering comments, attachments, or invisible layers.
6. Run a metadata scan with the prime s approved tool, or use a local inspector like Document Inspector in Word and a trusted PDF tool, then confirm the file passes the prime s acceptance checks.

• Microsoft Word: View Hidden Text, Draft view, Developer tab to see content controls, and Document Inspector to detect comments, properties, and document server data.
• Adobe Acrobat Pro: Use Remove Hidden Information, Sanitize Document, or Preflight checks to find hidden layers, attachments, and metadata.
• exiftool: Command line utility to inspect and remove image EXIF metadata if images are part of the deliverable.
• Embedded object review: Right click an embedded chart or object and choose to open or convert to source format. Treat each embedded file as a separate file to inspect.

You finished a narrative section in Word. Before sending to the prime, switch to Draft view, reveal hidden text, and open headers. You discover a local path in a footer and an embedded Excel chart. Open the chart, remove author properties inside Excel, save the chart content, then remove the original embedded object and reinsert the sanitized version. Export to PDF and run the PDF hidden content scan. Finally, submit the sanitized file to the prime s validator and confirm a clean result.

• View hidden text and content controls.
• Manually inspect headers and footers.
• Open every embedded object and sanitize its metadata.
• List and review macros, then remove or disable as required.
• Scan images for EXIF data and strip if present.
• Export to PDF, run a hidden content scan, and confirm with the prime s validator.

Where hidden metadata commonly lives.

What to look for: author, company, last modified by, and product/device strings. These appear in file properties and in exported PDFs. A quick property check often reveals an offshore username or company label. The course notes call out document properties as a primary source of leakage.

What to look for: visible markup, resolved comments, and reviewer initials in revision history. Even comments that appear resolved can retain author metadata. Open the review pane and search for any reviewer names or orphaned notes.

What to look for: exported PDFs that retain author, application, or creation timestamps. Conversion can leave behind embedded metadata or stray comments that survive the export process. The materials warn that PDF metadata is a submission-stage risk.

Properties and author fields. Comments and tracked changes. Headers, footers, and embedded objects. File and image names, and exported PDF properties. Cloud version history and sharing links.

Evaluators notice differences in fonts, spacing, headers and footers, color use, and document layout as signs that multiple teams contributed to a document. File-level traces such as author names, device IDs, timestamps, and revision history create the same effect even when visible styling looks consistent. The course materials list these exact risks and link them to evaluator scrutiny in SLED procurements. PDF exports can preserve author metadata or hidden comments that undo careful cleanup at the Word stage.

• Document properties: author, company, last saved by, and creation and modification timestamps. Remove or replace with prime-approved values. - Tracked changes and comments: accept or reject edits and delete all comments, even resolved ones, before exporting. - Headers, footers, and embedded objects: check for hidden fields, retained footers, or objects that contain organization names or metadata. - Styles and fonts: enforce the prime's template styles for headings, body text, bullets, and captions to avoid mixed fonts or spacing that draw attention. - File name and versioning: follow prime naming conventions exactly. Never include offshore team identifiers or local device paths. - PDF conversion: flatten annotations, remove embedded comments, and sanitize PDF metadata after conversion; some primes require additional scanning tools.

1. Apply the prime-approved template across every file, then use a find-and-replace for fonts and paragraph spacing. 2. Accept or reject all tracked changes and delete every comment. 3. Clear document properties and remove hidden XML or custom XML parts. 4. Save a clean copy, then export to PDF using settings that strip metadata. 5. Run the prime's metadata scanner or a verification checklist to confirm no residual identifiers remain.

• Use only the prime template and approved fonts. - No tracked changes, no comments. - Clear author, company, and timestamp fields. - Inspect headers, footers, and embedded objects. - Name files per prime conventions. - Convert to PDF with metadata stripped and validate with the prime's toolset.

Being copied into client threads. Even a single offshore address in a client thread creates an email footprint that can flag subcontractor involvement, and it can expose attachments or earlier drafts that contain metadata. The Masked Relationship Model requires that offshore teams avoid appearing in client communications, and the prime manages all client relationships and submission logistics.

Route every external message through the prime. Send all draft outputs and questions to the prime’s proposal manager, not to the client, and wait for the prime to send any external email. The course material highlights that all work should flow through the prime’s internal reviewers and capture lead.

Notify the prime immediately. Provide the full message, recipient list, timestamp, and any attachments. The prime is responsible for client communication and for managing compliance and submission logistics, so they must lead containment and any follow up.

Recipient fields verified, no client addresses present. Message routed to the prime’s proposal manager or approved alias. Attachments scrubbed for metadata and comments, then validated with prime tools if available.

Never appear in client threads. Let the prime handle all external email. Always deliver drafts and files to the prime first, cleaned of metadata. Validate with any prime tools before anything goes external.

• Always follow the prime's exact naming standard. If the prime provides a template or prefix, use it verbatim. The prime owns visible attribution for final deliverables.
• Never include offshore office codes, country names, team member initials, contractor tool names, or local workstation IDs. These elements count as offshore identifiers and create immediate risk.
• Use only ASCII characters and simple separators such as underscores or periods. Avoid spaces, nonstandard punctuation, and accented characters that may be transformed by submission portals.
• Include only required tokens. Common safe tokens are prime abbreviation, solicitation or section code, document type, and version number. Keep the order consistent across all files.
• Use two-digit versioning, for example v01, v02, to avoid accidental sort-order problems during packaging.

• PrimeAbbrev_SolID_SectionCode_DocType_v01.pdf
• PrimeAbbrev_PastPerf_ClientName_Year_v01.pdf
• PrimeAbbrev_TechVolume_TabNumber_Attachment_v01.pdf These templates are examples to illustrate safe tokens. Confirm and use the prime's exact template where provided, because primes expect a unified output identity.

• Confirm the prime's naming standard and apply it exactly. Do not improvise.
• Remove all offshore identifiers from file names and folders at every save and export step. Even internal drafts should not embed visible offshore cues. The masked model requires prime only attribution and internal only workflows.
• Save a clean copy and run the prime's file validation tools, if available. Some primes scan submissions for metadata and naming anomalies.
• When exporting to final formats, check the exported file name that will be uploaded. Some export tools attach a source filename to metadata or to the exported filename itself.
• Deliver files only to the prime's designated uploader or proposal manager. Offshore teams must avoid direct upload to client portals to prevent accidental exposure.

• Ask for a one line naming policy from the prime and store it in a shared checklist. Follow that line exactly.
• Automate safe filenames at export by using a saved export preset or macro that inserts only approved tokens.
• Treat any file name that references internal workflows or tools as an internal artifact. Remove or rename before preparing evaluator facing materials.

Correct upload permissions mean the prime or an authorized prime representative performs the final transfer to the client portal using prime-controlled accounts and roles. Offshore teams must not perform direct uploads to client portals, and the prime typically manages submission logistics and account ownership to avoid visibility risks. When permissions are wrong, edit histories, uploader metadata, or residual links can expose offshore involvement.

• Offshore accounts with upload or owner rights on client portals.
• Shared editor links or folders that preserve edit or version histories.
• Temporary tokens or credentials left active after handoff.
• Files uploaded from cloud accounts that reveal contributor emails or device IDs in access logs.

1. Finalize locally and lock content. Ensure the deliverable is the prime-branded final copy and that tracked changes and comments are resolved before transfer.
2. Transfer to the prime using an approved channel. Use the prime-approved secure transfer method rather than client portals. Deliver only to the prime point of contact responsible for submissions.
3. Confirm prime uploader identity and role. Ask the prime to confirm which account and role will be used to upload, and when the upload will occur.
4. Prime performs the upload. The prime uses its own portal credentials or the client portal account the prime controls to submit the file.
5. Revoke and verify. After handoff, remove any shared links, revoke temporary access, and request proof of upload such as a system receipt or confirmation log.

• Notify the prime immediately so they can coordinate with the client to remove or replace the file.
• Revoke any credentials or shared links used in the error.
• Ask the prime to reupload a clean copy from the prime account and to confirm removal of the accidental file from the portal.
• Log the incident and the corrective steps for future process improvement.

Role and communication boundaries: Only the prime communicates with evaluators and uploads final materials. Do not email clients, join client calls, or appear in submission portals. All deliverables go to the prime for final assembly and upload.

Clear document metadata: Remove author, company, device IDs, timestamps, and revision history. Verify headers, footers, and embedded object properties are clean. Remove all markup: Accept or reject tracked changes, delete all comments, and confirm no hidden text remains in the file.

Prime-only upload: The prime should perform the final packaging and portal submission to prevent accidental exposure from RSP accounts. Keep a signed handoff record showing who delivered the final clean files to the prime. This reduces risk during agency review.

Recovery steps: 1. Pull the original source file, remove comments and accept all changes, inspect headers and embedded objects, and re-save as a fresh file copy. 2. Export a new PDF, then open and inspect PDF properties to confirm author fields are blank. 3. Run the prime’s metadata scanner and obtain signed confirmation from the prime’s proposal lead before re-submitting to the prime for upload.