Inspection Report
This is what you receive. Every finding carries a severity, the evidence behind it, the impact if left alone, and a recommended fix. Nothing here describes a real client system.
Orchard Field Services
Summary
The platform is in daily use by 40 field staff and has been stable for its current load. The domain modelling is better than typical for a rapidly-built system, and the core scheduling logic is sound and worth keeping.
Clearance is blocked by two issues, both in access control. A tenant-scoping gap allows one customer’s dispatcher to read another customer’s job records by changing an identifier in a request. Separately, service credentials are committed in the repository history and remain valid.
Neither is difficult to fix. Both are the kind of issue that stays invisible until someone external finds it. Everything else is ordinary maturation work that can proceed after launch.
2 critical findings
Area results
Findings
2 critical · 2 high · 3 medium shown · 19 total in full reportJob records are not scoped to the requesting tenant
Evidence. The job detail endpoint resolves records by identifier alone. Authentication is verified; tenant ownership is not. A dispatcher authenticated to one company can retrieve another company’s job records, including customer addresses and contact numbers, by altering the identifier in the request.
Impact. Cross-tenant data exposure affecting personal information. Likely to be found by ordinary user curiosity, not just deliberate attack.
Recommendation. Enforce tenant scoping in the data access layer rather than per-endpoint, so new endpoints inherit it by default. Add regression tests that assert cross-tenant access fails.
Live service credentials committed to repository history
Evidence. Three credentials — a mail provider key, a payment gateway secret and a database connection string — appear in commit history. They were removed from the working tree but remain retrievable from history, and all three still authenticate successfully.
Impact. Anyone who has ever had repository access, including via a fork or clone, holds working production credentials.
Recommendation. Rotate all three immediately — rotation matters more than history rewriting. Move to environment-injected secrets and add automated secret scanning to CI.
Backups exist but have never been restored
Evidence. Nightly database snapshots run and are retained for 7 days. No restore has been performed. The snapshot job writes to the same cloud account and region as the primary database, and file uploads are not included in any backup.
Impact. An untested backup is an assumption. Uploaded documents are currently unrecoverable at any point.
Recommendation. Perform a full restore into a scratch environment and record how long it takes. Extend backups to object storage. Move copies out of the primary account.
No automated tests on scheduling or billing paths
Evidence. The repository contains 11 test files, all covering UI rendering. The scheduling engine, overlap detection and invoice calculation have no automated coverage. Deployment runs no test gate.
Impact. The logic that decides who gets sent where, and what customers are charged, can change without anything noticing.
Recommendation. Start with the money and dispatch paths. Roughly 30 well-chosen tests would cover the cases that actually cost you, and give AI-assisted changes something to fail against.
No monitoring or alerting installed
Evidence. Application logs are written to container stdout and not retained beyond restart. There is no uptime check, no error tracking and no alerting. Outages are currently discovered by staff phoning the office.
Recommendation. Retained structured logs, an error tracker and one uptime check on the dispatch endpoint. A day of work that changes how you learn about problems.
Referential integrity enforced only in application code
Evidence. Foreign key constraints are absent on six tables. Orphaned job-assignment rows already exist, referencing staff records that were deleted.
Recommendation. Clean the orphans, then add constraints. Let the database enforce what the database is good at enforcing.
Deploys are manual and cannot be rolled back
Evidence. Deployment is a manual command run from a developer laptop. No build artefact is retained, so reverting means checking out an older commit and rebuilding. Migrations run automatically on start with no down path.
Recommendation. Move the deploy into CI, retain artefacts, and separate migrations from release so a bad deploy is reversible in minutes.
What’s working
A report that only lists problems isn’t an assessment. These are the parts we’d keep and build on.
Domain model
Jobs, sites, staff and schedules are cleanly separated and named consistently. Unusually good for the build method.
Scheduling logic
Overlap and travel-time handling is correct in the cases we exercised. Keep it — and get tests around it.
Infrastructure
Managed database with automated patching, sensible network boundaries, and TLS terminated correctly.
Path to clearance
Want one of these for your system?
Same structure, your software, real findings.