Build Reusable Enterprise Test Company Environments for AI Platform QA

# Build Reusable Enterprise Test Company Environments for AI Platform QA We are looking for an experienced Microsoft 365 / Entra, GitHub, Google Workspace / Cloud Identity and automation specialist to build a realistic, reusable dummy-company environment for testing an enterprise AI intelligence platform before launch. The objective is not to create a simple demo. We want a permanent **QA / validation environment** that behaves as closely as practical to a real 300–1,000 employee organisation and can be: - reset - rebuilt - cloned - regenerated with different company structures and test scenarios without requiring us to purchase hundreds of paid SaaS licences. ## Project Objective We are building an enterprise AI intelligence platform that connects to company systems and attempts to automatically discover and understand: - employees and identities - departments and teams - AI systems - AI usage - ownership - technical ownership - applications and integrations - relationships between people, systems, data and processes - risk and governance issues - historical changes - incomplete or conflicting evidence We need a realistic test company so we can connect the platform as though it were a real customer and verify whether it discovers the correct information automatically. The key principle is: **The platform should discover as much as possible itself, rather than requiring users to manually enter large amounts of data.** We therefore need a strong test environment containing enough realistic complexity, ambiguity and edge cases to properly challenge the platform. --- # 1. Primary Test Company The first environment should represent a fictional company of approximately: **400–500 employees** For example: **Asteria Technologies** The specific fictional company name can be agreed before setup. It should feel like a genuine mid-sized technology/services company rather than a clean toy environment. ## Suggested Organisation Structure Approximately: - 400–500 employees - 10–12 departments - 30–50 teams/groups - several management layers - employees with managers - business owners - technical owners - governance/compliance owners - contractors - guest users - inactive users - employees who have changed departments - shared or ambiguous ownership scenarios Suggested departments could include: - Engineering - Product - Sales - Marketing - Finance - Operations - HR / People - Legal / Compliance - Customer Support - IT - Data / Analytics - Research --- # 2. Microsoft 365 / Entra Environment Create a dedicated Microsoft test environment containing realistic identities and company structure. This should include: - approximately 400–500 identities - realistic employee names - departments - job titles - managers/reporting lines - security groups - Microsoft 365 groups where appropriate - teams/groups - business owners - technical owners - contractors - guest users - active and inactive accounts - deliberately ambiguous identities - some employees with multiple roles We do **not** expect every employee to have a paid Microsoft 365 licence. The aim is to keep ongoing software costs as low as possible. Where practical, a smaller number of users should have richer activity such as: - Teams membership - mail/calendar activity - application relationships - group membership history - manager changes - ownership changes - directory events A Microsoft Developer / sandbox / Entra test environment should be used wherever appropriate. --- # 3. GitHub Test Organisation Create a separate GitHub organisation for the fictional company. It should include: - multiple teams - sample repositories - realistic repository names - repository owners - contributors - issues - pull requests - commits - branches - releases - team/repository relationships We would also like deliberate historical scenarios such as: - repository ownership changes - employees joining/leaving teams - abandoned repositories - repositories with unclear owners - internal AI projects - deprecated projects GitHub Free should be used wherever possible. --- # 4. Google Workspace / Cloud Identity Optional but preferred. Create a Google test environment using the lowest-cost/free option practical. This should contain: - users - organisational units - groups - departments - managers - ownership relationships If full Google Workspace licences are unnecessary, Cloud Identity or another suitable test option is preferred. --- # 5. AI Systems / Applications The test company should contain or realistically represent approximately: **30–40 AI systems** Examples could include: - ChatGPT - Claude - Microsoft Copilot - GitHub Copilot - Google Gemini - Perplexity - Notion AI - Salesforce AI - HubSpot AI - internal AI assistants - internal support agents - automated document-processing tools - AI research tools - departmental automation tools - custom LLM applications We do **not** expect 30–40 real paid SaaS subscriptions. Where a real account would be unnecessary or expensive, the system should be represented through realistic test data, source records, integrations or seeded data. --- # 6. Deliberate Test Scenarios This is very important. The environment should intentionally contain difficult situations designed to test whether our platform resolves them correctly. Examples: ### Ownership - AI system with no owner - system with one business owner and another technical owner - conflicting owners from different sources - employee incorrectly appearing as owner - owner who has left the company - one person holding multiple ownership roles ### Duplicate / Resolution Problems - same system appearing under two names - renamed system - duplicate employee identities - contractor and employee with similar names - duplicate application records - similar systems that should NOT be merged ### Shadow AI - unapproved AI tools - tools used by only a few employees - systems with no governance record - tools discovered through usage but not registered ### Governance / Risk - sensitive-data usage - system with no documented controls - high-risk system without approval - system with strong usage but weak governance - accepted risk awaiting sign-off - incomplete evidence ### Operational / Value - heavily used AI tool - expensive/low-value tool - duplicate tools serving the same purpose - abandoned system - system with strong adoption and measurable value - system with very low adoption ### People / Organisation - employee changes department - manager changes - contractor becomes employee - employee leaves company - system changes owner - business unit restructures - teams merge or split --- # 7. Historical Data We want the environment to contain enough historical activity to test whether our platform can reconstruct useful pre-onboarding history. Where possible, create realistic dated records such as: - historical GitHub commits - issues and pull requests - users joining/leaving teams - ownership changes - repository ownership changes - manager changes - application introduction dates - systems becoming inactive - systems being replaced - new AI systems appearing over time - historical groups/relationships The history does not need to be years of real usage, but it should provide enough variation to test historical reconstruction. --- # 8. Ground Truth Dataset A critical deliverable is a separate **ground-truth dataset**. This should describe what is actually true in the fictional company, independent of what our platform discovers. It should contain: - employee count - employee identities - departments - teams - reporting relationships - AI systems - true system owners - technical owners - governance owners - users of each system - department/system relationships - system/application relationships - deliberately duplicated records - ambiguous records - shadow AI systems - risk scenarios - historical changes - expected edge cases Excel, CSV, JSON or Google Sheets is acceptable. We will use this to compare: **Ground truth → what our platform discovered → what it missed → what it incorrectly inferred.** --- # 9. Reusable / Cloneable Environment This is one of the most important requirements. The test environment should **not** be a one-off manual build. Wherever practical, it should be generated from: - scripts - APIs - configuration files - seed data so that we can later create entirely different fictional organisations. We want to be able to generate companies such as: ### Asteria Technologies 450 employees Technology company with high AI adoption and moderate governance. ### Meridian Health Systems 620 employees Healthcare/services organisation with stricter controls, sensitive data and lower AI maturity. ### Redwood Financial Group 380 employees Financial-services organisation with heavy governance, approvals and risk controls. ### Helix Commerce 800 employees Fast-growing e-commerce company with large shadow-AI usage and many overlapping tools. ### Vertex Industrial 520 employees Traditional industrial organisation with lower AI adoption, fragmented systems and unclear ownership. These should not simply be renamed copies. Each configuration should be capable of changing: - company name - employee count - departments - AI maturity - systems used - ownership structure - governance maturity - risk profile - history - edge cases The goal is to repeatedly test our platform against genuinely different company profiles. --- # 10. Configuration / Seed Files We would ideally like the reusable setup to separate data into logical configuration files such as: - company - employees - departments - teams - managers - groups - AI systems - system owners - technical owners - relationships - repositories - historical events - risks - governance scenarios - edge cases The exact structure can be proposed by the freelancer. JSON, CSV, YAML or another sensible format is fine. --- # 11. Automation We strongly prefer automation rather than manually creating hundreds of accounts and records. Relevant experience could include: - Microsoft Graph API - PowerShell - Azure CLI - Python - Google Admin SDK - GitHub API - Terraform where appropriate - data-generation scripts The ideal result would include a documented process such as: **Create tenant → run population script → generate users/groups/data → create GitHub structure → validate → ready for testing.** A fully automated one-command rebuild is ideal but not mandatory if certain external-platform steps require manual setup. --- # 12. Reset / Rebuild Capability We need documentation explaining how to: - reset the environment - remove seeded data - repopulate the test company - change the company configuration - create a new company scenario - regenerate identities and relationships - change AI systems - change historical events We want to use this environment repeatedly throughout product development. --- # 13. Scale Testing The real connected test environment may contain approximately 400–500 employees. We would also like the generated data/scripts to support larger simulated datasets where practical. For example: - 1,000 employees - 2,000 employees - thousands of system relationships - tens of thousands of evidence/activity records These larger datasets can be synthetic and do not need full external SaaS accounts. The purpose is to test application performance and scale. --- # 14. Security / Ownership All test environments and accounts must ultimately be owned by us. Requirements: - we retain primary administrator accounts - MFA enabled - freelancer may receive temporary admin access only - no credentials stored in source code - no real customer/company information - all data must be fictional - all freelancer access should be removable after completion - all scripts/configuration handed over to us --- # 15. Deliverables At completion we expect: 1. A working fictional 400–500 employee test company 2. Microsoft 365 / Entra test environment 3. GitHub test organisation 4. Google / Cloud Identity environment if practical 5. Departments, teams and reporting structure 6. Approximately 30–40 AI systems represented 7. Ownership and technical ownership data 8. Deliberate duplicate, ambiguous and shadow-AI scenarios 9. Governance/risk scenarios 10. Historical activity where practical 11. Ground-truth dataset 12. Population scripts 13. Configuration/seed files 14. Documentation 15. Reset/rebuild instructions 16. Ability to generate different fictional companies with different characteristics 17. Administrator ownership handed back to us --- # Budget / Timing We see this as a focused setup and automation project rather than a long software-development engagement. We expect an experienced person to be able to complete the initial environment relatively quickly using scripting and APIs. Please provide a **fixed-price quote**. Our preference is to keep: - ongoing SaaS costs extremely low - paid licences to an absolute minimum - the majority of the test environment reproducible through automation --- # Ideal Candidate Strong experience with several of: - Microsoft Entra ID / Azure AD - Microsoft 365 administration - Microsoft Graph - PowerShell - Python - Google Workspace / Cloud Identity - Google Admin SDK - GitHub organisations and GitHub API - test-data generation - directory/identity architecture - enterprise SaaS testing - automated QA environments ## Please answer these questions when applying 1. How would you create a realistic 400–500 employee organisation without purchasing hundreds of SaaS licences? 2. Which parts would you automate? 3. Which Microsoft test/sandbox setup would you recommend? 4. How would you make the environment resettable/reproducible? 5. How would you generate multiple different fictional companies from the same framework? 6. What parts cannot realistically be cloned/automated? 7. Have you built similar directory, sandbox or enterprise test-data environments before? 8. What ongoing software/licence costs should we expect?