F. Third-Party Contractor Onboarding

Wasteology engages external build teams under time-and-materials or fixed-scope contracts — Korza (SOF engagement, 2026) is the live reference implementation, and Mars/Orbit is an example of a fully externally-built system now integrated into our monitoring and governance. This section standardizes the full lifecycle so every future engagement starts from a known-good baseline rather than being re-invented per vendor. The controls here are not bureaucracy for its own sake: they protect IP ownership, prevent production-data exposure, and ensure the code we accept can actually be operated by our team after the contractor leaves.

---

F.1 Engagement Lifecycle

Every external build engagement passes through six phases. The phase table below is the canonical checklist; the PO owns sequencing and gates.

Phase	Name	Duration (typical)	Wasteology owner	Contractor deliverable	Gate to next phase
0	Intake & Scoping	1–2 weeks	Product Owner (PO)	Vendor proposal / SOW draft	Signed NDA; architecture proposal accepted
1	Contracting	1–3 weeks	PO + Legal	Signed contract + DPA + security questionnaire	All docs signed; access-request form submitted
2	Environment Setup	3–5 days	Platform owner (kgray)	Contractor provides static egress IPs, personal emails for Entra B2B invite	Sandbox DB provisioned; ADO guest access granted; contractor can run a smoke test
3	Build & Communication	Project duration	PO (weekly cadence)	Working code in our ADO repo, weekly written status, demo per sprint	—
4	Acceptance & Handoff	1–2 weeks	PO + platform owner	Handoff runbook, operational docs, knowledge-transfer session	All acceptance criteria met; credentials rotated; guest access revoked
5	Offboarding	≤ 3 days after Phase 4	Platform owner	—	Checklist signed off (see §F.6)

PO decision point

The PO approves the gate from Phase 1 → 2 (environment provisioning) and from Phase 3 → 4 (acceptance). Do not provision production-adjacent resources until Phase 1 is fully closed.

---

F.2 Requirements We Impose on Contractors

These are non-negotiable defaults. Each item must appear explicitly in the contract or SOW.

F.2.1 Source Control in Our ADO

Recommended standard: All code produced under the engagement lives in a repository under dev.azure.com/wasteology/Wasteology/. We create the repo; we own it from day one. Contractors push to feature branches and open PRs against main or a long-lived develop branch we designate.

How it works: The contractor is invited as an ADO guest (see §F.4). They clone our repo over HTTPS using a time-boxed Personal Access Token (PAT) we provision, scoped to Code (Read & Write) on that specific project. They do not bring their own GitHub org or Bitbucket instance. If a contractor-side repo pre-exists (e.g., a vendor template), they migrate it into our ADO at Phase 2.

PO decision point

If the vendor insists on GitHub (as Mars/Orbit does), require a dedicated GitHub org/repo that we own and that integrates into our ADO pipelines — not their personal/company org. Mars runs on a separate Azure subscription (Wasteology-Orbit, 60e2b27e-fc5d-4b4b-81a9-ae650e8f2adf) with its own GitHub Actions CI; this is acceptable because Wasteology owns the org and the subscription. Document the deviation.

F.2.2 Branching, CI, and Code-Review Standards

Recommended standard: Contractors follow the same branching and CI conventions as internal developers (see Section B — Developer Environment & CLI Standards).

• Feature work: feat/<short-description> branches off main (or develop if we designate one for the engagement).
• Every PR requires at least one Wasteology-side approval before merge. The PO or platform owner is the default approver; they may delegate to a designated internal technical reviewer.
• CI must pass (lint, tests, type-check) before the approval is given. PRs that disable or skip CI steps are rejected.
• No direct pushes to main. Branch protection is enforced in ADO with a minimum-reviewer policy.

How it works: Configure ADO branch policies at repo creation (Phase 2): require 1 reviewer, require linked work item, block completion on active comments. Set the Contributor role for contractor guest accounts — not Project Administrator.

PO decision point

If the engagement is a short spike (< 2 weeks), the PO may waive the work-item linkage requirement but not the reviewer requirement.

F.2.3 No Production Data or Production Access

Recommended standard: Contractors never access wasteology (prod DB), the Prod Azure subscription (a5a6818e), or any live customer-facing endpoint.

How it works: The sandbox model (§F.4) enforces this at the infrastructure level. The contractor's Entra B2B guest account is never granted RBAC on the Prod subscription. All data they work with is either synthetic, the daily-refreshed sandbox snapshot, or anonymized exports approved by the PO.

PO decision point

If a contractor needs to observe a specific production behavior for debugging, the platform owner joins a screenshare and drives — the contractor watches. No direct credentials are shared.

F.2.4 Security Baseline

Contractors must meet the following minimum security requirements, attested via the security questionnaire (§F.3):

Requirement	Detail
MFA enforced	All team members accessing our ADO or Azure resources must have MFA enabled on their identity. Verified via Entra B2B conditional access policy.
Least-privilege access	Roles are scoped to the specific repo and sandbox DB. No subscription-level access. No azure_pg_admin unless explicitly required and time-boxed.
No credentials in code	Secrets, connection strings, passwords, and API keys must never appear in source files or commit history. Violation is grounds for immediate access revocation. Secrets are retrieved at runtime from Azure Key Vault or environment variables injected by CI (see §F.4).
No data exfiltration	Contractor team members must not copy production or sandbox data outside the Azure network boundary — no CSV exports to personal devices, no third-party analytics tools connected to the sandbox.
IP allowlisting	Static egress IPs for every contractor developer and CI runner must be provided at Phase 2 and added to the Azure PG firewall rules. Dynamic IPs are not accepted.
Dependency vetting	Any new third-party library must be disclosed in the PR description. The internal reviewer checks for known CVEs and license compatibility.

F.2.5 IP Ownership

Recommended standard: All code, schemas, configurations, and documentation produced during the engagement are Wasteology work-for-hire and assigned to Wasteology Group in the contract. Contractor retains no license to reuse deliverables for other clients.

How it works: Standard work-for-hire clause in the MSA/SOW. Reinforced by the code living in our ADO from day one (not migrated at the end).

F.2.6 Definition of Done

A deliverable is not "done" until:

1. Code is merged to main in our ADO repo (or the designated integration branch) with all CI checks green.
2. At least one Wasteology-side PR approval is on record.
3. The feature is deployed to a Wasteology-controlled environment and smoke-tested by the internal reviewer (not self-certified by the contractor).
4. Any schema changes are delivered as a versioned Alembic or Flyway migration (not ad-hoc DDL run by hand).
5. Relevant lat.md sections are updated or a PR to update them has been opened by the contractor (internal reviewer merges it).
6. No open Severity 1 or Severity 2 defects in that feature area.

---

F.3 Documentation Contractors Must Complete

The table below is the canonical checklist. Items marked Pre-start must be completed before Phase 2 (environment setup) begins. Items marked Handoff are required before Phase 4 closes.

#	Document	Timing	Owner	Purpose
1	Mutual NDA	Pre-start	Legal / PO	Protects Wasteology's proprietary information (customer data schemas, business logic, trade secrets) and the contractor's own IP disclosed during scoping.
2	Data Processing Agreement (DPA)	Pre-start	Legal / PO	Required under GDPR/CCPA if the contractor will handle any personal data. Even with the sandbox isolation model, the DPA must be in place because sandbox schemas include real account/location master data.
3	Security Questionnaire	Pre-start	Platform owner	Self-attestation covering: MFA status for all team members, code-review practices, secret management, background check policy, incident response contact, data-retention policy for work artifacts. Template provided by Wasteology (see Appendix F-A).
4	Access-Request Form	Pre-start	Platform owner	Lists every person on the contractor team who needs access: full name, work email (used for Entra B2B invite), GitHub/ADO handle, static egress IP(s), and the specific ADO repos and DB roles being requested. One form per engagement; updated if team composition changes.
5	Solution / Architecture Proposal	Pre-start (Phase 0)	PO	Contractor's proposed technical approach: data model, service boundaries, external dependencies, hosting model, and how the deliverable integrates with existing Wasteology systems. Reviewed and approved by the platform owner before any code is written.
6	Data-Handling Plan	Pre-start	PO	Describes what data categories the contractor will access, how they will be stored/processed, who on the contractor side will see them, and how they will be deleted at offboarding. Must explicitly state "no production data" or document any approved exception with PO sign-off.
7	Sprint / Delivery Plan	Phase 2	PO	Milestone breakdown, sprint cadence, and demo schedule tied to ADO work items. Gives both sides visibility into when deliverables are expected and what acceptance looks like.
8	Handoff Runbook	Handoff (Phase 4)	Contractor (reviewed by platform owner)	Step-by-step operational guide for the delivered system: how to deploy, how to roll back, environment variable reference, monitoring setup, common failure modes and remediation. Must be accurate enough for the platform owner to operate the system without contractor involvement.
9	Operational Documentation	Handoff (Phase 4)	Contractor	Architecture diagram (C4 or equivalent), data-flow diagram, dependency list, known limitations, and any deferred work items. Submitted as PRs to lat.md/ (preferred) or the Wasteology internal docs site.
10	Knowledge-Transfer Session	Handoff (Phase 4)	Contractor delivery lead	Live walkthrough (recorded) covering the codebase structure, key design decisions, and anything that is not obvious from the docs. Minimum 2 hours. Attended by the PO and platform owner.

PO decision point

On small engagements (< $20k or < 6 weeks), items 6 and 10 may be simplified (data-handling plan can be a paragraph in the SOW; KT session can be 30 minutes), but items 1–5 and 7–9 are always required.

---

F.4 Environment & Access Model

F.4.1 Isolated Sandbox Database (Korza Precedent)

Recommended standard: Every external build team that needs database access gets a dedicated sandbox database — never the dev (wasteology_dev) or prod (wasteology) databases.

How it works (Korza as template):

• A new Postgres database (wasteology_<engagement>_sandbox) is created on pg-wasteology.postgres.database.azure.com (same cluster as dev/prod, but isolated by database boundary).
• A daily Prefect flow refreshes the sandbox by dropping and restoring a set of approved source schemas from dev/prod snapshots. The Korza refresh runs at 3:30 AM ET via korza-sandbox-refresh-daily. Any data the contractor writes into refreshed schemas is wiped at the next cycle — this is by design, not a bug. Schemas the contractor owns exclusively (e.g., their own migration schema) survive refreshes.
• Grants are preserved across the drop/restore cycle by the flows/sandbox_refresh/grants.py snapshot-and-replay helper, so the contractor's roles don't need to be re-applied manually each morning.
• Role hierarchy: <engagement>_admin (DDL, Alembic) → <engagement>_service (runtime service account) → <engagement>_dev (individual human logins). Passwords are stored in the Wasteology Bitwarden vault under a dedicated engagement folder.
• Static egress IPs provided by the contractor are added to the Azure PG firewall rules as named rules (e.g., korza-guilherme-dev, korza-gcp-extraction-dev). Dynamic IPs are not accepted. New team members require a firewall rule update before they can connect.
• The Sling connection WASTE_PG_<ENGAGEMENT> is added to the platform owner's local ~/.sling/.env so ops db can manage roles on the sandbox. The contractor does not have access to this connection entry.
• Schema access is deliberately narrow: the contractor gets only the schemas needed for their scope. Example: Korza gets bins_trashy, wdp_ref, dbt_prod, sof_* (refreshed daily), plus their own bins state schema (persistent). They do not get wasteology_ops write access; any schema they want added to the prod wasteology_ops goes through a migration PR reviewed by the platform owner.

PO decision point

If the engagement does not require database access (e.g., a pure frontend or CLI tool), skip database provisioning. If the engagement requires a separate Azure subscription (as with Mars/Orbit), document it explicitly and budget for the subscription cost.

F.4.2 Entra B2B Guest Access (ADO + Azure)

Recommended standard: Each contractor developer is invited as a Microsoft Entra B2B guest using their work email. They authenticate with their own identity provider (MFA enforced via conditional access on our tenant).

How it works:

• PO or platform owner sends a B2B guest invitation via the Azure portal or az ad invitation create. Contractor accepts via email link.
• Guest accounts are added to the ADO organization at the Basic access level (not Stakeholder — Stakeholder cannot create PRs).
• Guest accounts are assigned the Contributor role on the specific ADO project, not Project Administrator or Project Collection Administrator.
• Guest accounts are added to a security group named ext-<engagement> in ADO. This group is the assignee for any RBAC grants so that revoking the group at offboarding cleanly removes all permissions.
• Guest accounts are never granted RBAC on the Prod Azure subscription (a5a6818e). RBAC grants on the Dev subscription are limited to what the engagement strictly requires (typically none — the sandbox DB handles data access).
• RBAC role assignments require a User Access Administrator (ABS or CGreco) or Owner (ashull) per the governance runbook. The platform owner (kgray) submits an access request; it does not self-approve for contractor grants.
• Guest accounts are time-boxed: the Entra invitation is configured with an expiry aligned to the expected engagement end date plus a 30-day buffer. Set a calendar reminder to review before expiry.

Note on managed identities: Wasteology's tenant has a restriction on service-principal (app registration) creation. Contractor-run automated workloads that need Azure identity use managed identities provisioned and owned by Wasteology (<engagement>-mi), not SP credentials created by the contractor. The contractor's CI/CD pipelines authenticate via secrets we inject into their pipeline environment, not via SPs they register themselves.

F.4.3 Secrets via Key Vault, Not Shared Files

Recommended standard: No secret values are ever shared as plaintext (Slack, email, .env files committed to the repo, or hardcoded in source).

How it works:

• Wasteology provisions a Key Vault secret (or a Bitwarden entry in the engagement vault) for each credential the contractor needs.
• For contractor CI/CD running in ADO: secrets are injected as pipeline variables (marked secret, sourced from Key Vault via the AzureKeyVault@2 task or equivalent). The contractor's pipeline definition references the variable name; the value never appears in logs or YAML.
• For contractor CI/CD running outside ADO (e.g., GitHub Actions for a GitHub-hosted repo): Wasteology creates a dedicated managed identity with a federated credential, and the contractor's pipeline exchanges a GitHub OIDC token for an Azure access token — no long-lived secret.
• Contractor developers who need a connection string for local development use their individual <engagement>_dev Postgres credentials stored in their own password manager. Wasteology does not maintain a shared "dev credentials" file.
• Secrets guard: Any PR that introduces a secret value (API key, password, connection string) in source code or committed config is rejected immediately. The internal PR reviewer checks for this explicitly.

F.4.4 Network Boundaries

Boundary	Policy
Azure PG firewall	Contractor static egress IPs only; no "allow all Azure services" or 0.0.0.0/0 rules
Prod subscription	No contractor access (no RBAC, no firewall rules pointing to contractor IPs)
VNet / private endpoints	Not required for sandbox (public endpoint with IP allowlist is acceptable for the sandbox DB); production uses private endpoints and is contractor-inaccessible by design
Key Vault	Contractor never has direct KV access; credentials are pushed to them via pipeline variables or Bitwarden entries at rotation time

---

F.5 Communication Strategy & Cadence

F.5.1 Single Points of Contact

Role	Wasteology	Contractor
Engagement owner / decision authority	Product Owner (PO)	Delivery lead (named in contract)
Technical escalation	Platform owner (kgray)	Technical lead (named in contract)
Day-to-day async	PO or designated internal reviewer	Any team member via ADO PR / Board comments

All formal communications (status, blocker escalation, change requests) are between the named contacts. Contractor team members do not DM the COO or other Wasteology staff outside the established channels without going through their delivery lead first.

F.5.2 Communication Cadence

Cadence	Format	Owner	Notes
Daily (async)	ADO Board — contractor updates their active work items to current status	Contractor	No standup call required; board must reflect reality
Weekly	Written status report (email or ADO wiki page)	Contractor delivery lead	Template: work completed this week / work planned next week / blockers / risks. Sent by EOD Friday.
Per sprint (bi-weekly recommended)	Live demo + retrospective	Both	Contractor demos against acceptance criteria. PO accepts or rejects. Platform owner reviews any infra/security items. Recorded.
On blocker	Immediate Slack message to PO	Contractor delivery lead	A blocker is anything that will delay a milestone by > 1 day. No waiting for Friday status.
On security incident	Immediate email to PO + platform owner	Contractor delivery lead	Any suspected credential exposure, data leak, or unauthorized access attempt is reported within 1 hour of discovery.
On scope change	Change request document (ADO wiki or email)	PO	No scope change is implemented without written PO approval.

F.5.3 Shared ADO Board

The contractor's work items live on the Wasteology ADO Board (Basic process: Issue, Epic, Task). The PO creates the initial Epics; the contractor populates Tasks under them. This gives Wasteology full visibility into what is in progress without relying on external project management tools.

• Contractor tags all their work items with the engagement tag (e.g., korza, devrabbit) so they are filterable.
• The PO reviews the board weekly and raises concerns in the written status thread, not verbally.
• The board is the source of truth for what has been accepted. "Done" on the board means the Wasteology reviewer has accepted it — not that the contractor has self-declared it finished.

F.5.4 PR-Based Async Collaboration

Code review is the primary technical communication channel. The contractor opens a PR; the internal reviewer (platform owner or designated technical reviewer) responds within 2 business days. The contractor responds to comments within 1 business day. PRs that sit unaddressed for 5+ business days without explanation trigger a blocker escalation.

PR descriptions must include:

• What changed and why.
• How to test it locally.
• Any new environment variables or secrets required (variable name only — never the value).
• Any schema changes, with the migration file attached.
• Any new third-party dependencies and their license.

F.5.5 RACI

Activity	Wasteology PO	Platform owner	Contractor delivery lead	Contractor team
Approve architecture proposal	A/R	C	R	I
Provision sandbox DB + guest access	I	R/A	C (provides IPs, emails)	I
Write feature code	I	I	A	R
Open PR + self-review	I	I	I	R
PR technical review	I	R	I	C
Accept/reject sprint demo	R/A	C	I	I
Rotate credentials	I	R/A	I	I
Approve scope change	R/A	C	I	I
Offboarding checklist sign-off	A	R	C	I

R = Responsible, A = Accountable, C = Consulted, I = Informed

F.5.6 Escalation Path

1. Contractor team member → Contractor delivery lead (internal to contractor).
2. Contractor delivery lead → Wasteology PO (primary escalation channel).
3. Wasteology PO → Platform owner (technical / infra issues).
4. Wasteology PO → COO (commercial, legal, or relationship issues).

Escalation must be in writing (email or ADO work item comment) so there is a record.

---

F.6 Acceptance Criteria, Handoff, and Offboarding

F.6.1 Acceptance Criteria

The PO defines acceptance criteria for each Epic at the start of the engagement. Default acceptance criteria (applied if not overridden):

• All CI checks pass on the final merged commit.
• All work items tagged to this engagement are in Resolved or Closed state in ADO.
• The platform owner has deployed the deliverable to a Wasteology-controlled environment and confirmed it runs without contractor involvement.
• The handoff runbook (§F.3 item 8) is complete, accurate, and has been validated by the platform owner performing a cold deploy using only the runbook.
• Operational docs and lat.md updates are merged (§F.3 item 9).
• Knowledge-transfer session has occurred and the recording is stored in the Wasteology SharePoint engagement folder.
• No open Severity 1 or Severity 2 defects.
• Security questionnaire re-attestation completed (confirms no new team members were added without firewall/access updates during the engagement).

PO decision point

The PO may accept partial delivery (Phase 4 closes, engagement ends) with explicit carve-outs documented as follow-on internal work items. Carve-outs must be agreed in writing; they do not automatically extend the contractor's access.

F.6.2 Offboarding Checklist

Offboarding is completed by the platform owner within 3 business days of Phase 4 closure. The PO countersigns.

Identity & Access:

• All contractor Entra B2B guest accounts removed from the ext-<engagement> ADO security group.
• Guest invitations revoked in Entra ID (portal: External Identities → All external users).
• Azure PG firewall rules for contractor egress IPs removed (korza-* pattern — delete all named rules for this engagement).
• Contractor _dev Postgres roles dropped: ops db drop-user <username> --conn WASTE_PG_<ENGAGEMENT> for each individual.
• Contractor service roles (<engagement>_admin, <engagement>_service, <engagement>_dev group roles) reviewed — drop if no longer needed, or repurpose for internal use if the system continues running.
• Any time-boxed PATs issued to contractor developers have expired or been manually revoked in ADO.

Secrets & Credentials:

• All shared secrets rotated: sandbox DB passwords, any Key Vault secrets the contractor knew existed (even if they didn't have direct KV access), any API keys issued for the engagement.
• Bitwarden engagement vault entries updated to reflect new credentials; contractor-facing entries archived (not deleted — retained for audit).
• If a managed identity was provisioned for contractor CI/CD, confirm no contractor-controlled federated credential is still attached. Remove federated credentials pointing to contractor GitHub repos or ADO orgs.

Repositories & Code:

• Confirm repo ownership: all repos under dev.azure.com/wasteology/Wasteology/. No code lives in a contractor-owned external repository without a Wasteology-owned mirror.
• Branch protection re-verified: contractor guest accounts are no longer in any reviewer bypass group.
• Final state of main branch is tagged: handoff/<engagement>-<YYYY-MM-DD> for easy rollback reference.

Sandbox:

• Decision documented: is the sandbox database kept (for internal continued development) or dropped? If dropped, run DROP DATABASE wasteology_<engagement>_sandbox; on the cluster. If kept, remove contractor roles from the daily refresh grant list.
• Daily refresh Prefect flow (<engagement>-sandbox-refresh-daily) disabled or deleted if the sandbox is dropped.

Documentation & Audit:

• Offboarding sign-off email sent to contractor delivery lead confirming access has been revoked.
• Engagement folder in SharePoint archived (read-only).
• Lessons-learned note added to the platform owner's engagement log (a brief paragraph: what worked, what didn't, what to change next time).

---

Appendix F-A — Security Questionnaire Template (Contractor Self-Attestation)

This questionnaire is completed by the contractor delivery lead before environment setup (Phase 2). Wasteology reviews responses; material gaps are resolved before access is granted.

1. MFA enforcement: Is MFA enforced for all team members who will access Wasteology ADO or Azure resources? (Yes / No / Partial — explain)
2. Device management: Are team members required to use managed/MDM-enrolled devices for client work? (Yes / No)
3. Secret management: What tool does your team use to manage secrets and credentials? (e.g., 1Password, Bitwarden, HashiCorp Vault) Do you have a policy prohibiting secrets in source code?
4. Code review: Is every code change reviewed by at least one other team member before being pushed to client systems? (Yes / No)
5. Background checks: Are team members who will access client data subject to background screening? (Yes / No / Not applicable — explain)
6. Incident response: Who is your security incident contact, and what is your target notification time for a suspected breach? (Name, email, time)
7. Data retention: How long do you retain client data on your own systems after engagement close, and what is your deletion process?
8. Subcontractors: Will any subcontractors or third parties (outside your direct employment) have access to Wasteology systems or data? (Yes / No — if Yes, list them and confirm they are covered by the same controls above.)
9. Vulnerability disclosure: Do you have a process for disclosing discovered vulnerabilities in client code to the client? (Yes / No — describe)
10. Attestation: I confirm the above answers are accurate. I understand that material misrepresentation is grounds for immediate access revocation and may constitute a breach of contract.

Signed: [Delivery lead name, title, date]

---

Section owner: Platform owner (kgray). Review cadence: at the start of each new external engagement, and annually. Last updated: 2026-07-17.