Conflict of Interest Statement

Storey Consulting builds three products on the same Opportunity Platform stack. The first is a developer-side compliance tool that automates Section 106 Employment and Skills Plans (the Tickbox product). The second is a council-side monitoring dashboard that tracks the obligations recorded in those plans against real delivery. The third is a recruitment-side placement service that matches local residents with the jobs those obligations are meant to create. The same company holds all three contracts, and the same engineering team writes all three codebases. We are stating this on the record so every party we work with knows it.

Data is not silently shared between the three sides. A council subscriber to the monitoring dashboard sees the obligations on schemes in their borough but never sees the developer's private commercial terms or the resident-side candidate records. A developer using Tickbox sees their own pack and never sees other developers' packs or the council's broader pipeline view. A resident applying for a job sees the role and the employer but never the underlying scheme's compliance status. Each cross-side data flow that does exist (a council notification when a developer pack is approved, a placement confirmation feeding back into the council's dashboard) is named in the schema, audited, and only triggers on the consent recorded at the originating side.

The controls in place to keep this conflict named and managed are listed below. None of them are aspirational; every item links to a specific code path or process that can be inspected:

• Audit log. Every cross-side data write (deed approval, obligation update, placement confirmation, export) appends an immutable record with the actor, the role, the source side, the destination side, and the payload hash. Councils on the Pro tier and above receive read access to the audit log scoped to their borough.
• Role-separated permissions. The application enforces five role buckets (developer, council_officer, delivery_staff, candidate, super_admin) at the route boundary. A developer account cannot read council audit views; a council account cannot read developer pack drafts; a candidate account cannot read either. Super_admin access is held only by named Storey Consulting staff and is itself logged.
• Transparent pricing. The price for each product is published. Tickbox developer packs are listed on tick-box.com; the council Monitoring tiers are listed on opportunityplatform.co.uk/products/council-monitoring; the placement fee is listed on the recruitment side. We do not quote different councils different prices for the same tier.
• No shared data without explicit consent.Every cross-side flow requires the originating side to opt in, either at the contract layer (the developer's ESP pack includes the data-sharing terms with their council) or at the row layer (a resident's job application is shared with the employer only when they apply). The consent record is stored alongside the data and surfaced in the audit log.
• Third-party audit available on request. A council, developer, or resident-side organisation may request an independent audit of the controls described above at any time. We bear the cost of the auditor's reasonable fee for the first request per organisation per year. Contactgovernance@opportunityplatform.co.uk to start the request; the auditor reports directly to the requesting organisation, not to us.

Questions about this statement, or the way data flows between the three sides on a specific scheme, can be raised at governance@opportunityplatform.co.uk. The statement itself is reviewed quarterly; the next review is scheduled for August 2026.