90-Day Priority Actions

Across all four platforms You, with named support

• ISO 27001 programme kickoff. QHSE-led, with IT Strategy & Architecture (IT Services) support. You track cross-product implications, particularly for Velidon, rather than driving the assessment itself. See Compliance Roadmap.
• SOC2 readiness assessment for Velidon. You lead this, with IT Services support. Gap analysis and remediation roadmap, not certification completion. See Compliance Roadmap.
• Design system foundation. Established once, applied across Velidon first, with an eye to future reuse.
• Standup cadence established across all teams (Velidon, ADAM OS, EDGE, POP), sequenced after initial team introductions rather than imposed on day one.
• Codebase and architecture discovery across all four products. Structured sessions with each team, producing a written summary per product: stack, key dependencies, known pain points, and open questions. Where documentation does not exist for a product, that gap is itself a finding worth logging.
• Hiring involvement. Technical Writer and QA/Support Engineer, both already identified as needed. An Applied AI Engineer, conditional on demonstrated need. Involvement in final-stage interviewing and structuring onboarding for whoever is hired within the window.
• Stakeholder mapping across IT Services, QHSE, People & Culture, and any customer-facing teams selling Velidon.
• Current metrics and reporting review for each product: what is actually being tracked today (usage, defects, support volume), and where there is no visibility at all, treated as a gap to close.
• Support and incident history review: recurring issues, open tickets, anything currently unresolved and urgent.
• Your own 30-60-90 plan, written and shared upward, so expectations are explicit rather than assumed.
• One early, visible, low-risk deliverable within the first 30 to 45 days, to build credibility with the teams before driving larger changes.
• AI fluency proficiency bar for your own role, and a ramp-up plan if needed, tied directly into the ADAM OS architecture discovery work rather than treated as generic training. This includes developing enough hands-on capability with AI coding tools to critically evaluate how the development teams are using them, not just using them yourself.

Velidon SaaS build-out and hardening

• Complete SaaS version requirements gathering.
• Resolve domain and product architecture: velidon.com as the marketing site, app.velidon.com for the SaaS version, and a distinct name for the contractor-controlled version, rather than treating it as a lesser tier of the same product.
• Produce the Velidon design system, then apply it as a UI upgrade to the existing contractor-controlled version, in that sequence.
• SOC2 gap list, Velidon-specific.
• Security posture documentation package for IOC review, built from controls that already exist today (multi-tenant isolation, role-scoped access, audit trail), packaged for a technical audience to review directly.
• Hardening backlog for the contractor-controlled version, tracked separately from the SaaS build, prioritised by actual customer and IOC exposure, since this version is already delivering inspections to Arridex's own customers today.
• GTM: positioning and pricing framework draft for the SaaS version, preparation rather than launch activity at this stage.

ADAM OS Standardisation and handoff

• Understand the AI agent development rules framework as part of architecture discovery, this is important standardisation work.
• Formal handoff of ADAM OS ownership to the Senior Full-Stack Developer, structured for continuity and to allow other developers to contribute in future without relying on undocumented tribal knowledge.
• Review the PHP stack now for scalability and security fundamentals, while the codebase is still small enough that this is cheap to address.
• Prepare a demo-ready slide deck for prospective ADAM OS customers, given the emerging external licensing interest.

EDGE ERP Rename and roadmap

• Rename from RS EDGE to a new EDGE-prefixed name, sequenced with domain finality so the rename and the domain change happen as one event rather than two separate rebrands.
• Module utilisation assessment and a 90-day roadmap, developed with the Senior Full-Stack Developer before their transition onto ADAM OS completes.

POP Light-touch oversight

• Process inventory and intake audit: review the current division-code process library, meet the two developers and the Process Improvement unit, and establish a clear prioritisation mechanism for future automation requests.

POP is a working platform run by its own team. This quarter's goal is understanding and establishing intake structure, not driving a roadmap of new work.