Brainstorm Session 11: Traff.io Features, Laravel vs Elixir Go-Live, Migration Phasing, Naming¶
Date: 2026-04-16 Objective: Four focused topics in one session
Techniques Used¶
- SWOT — Laravel vs Elixir go-live decision
- Mind Mapping — Traff.io feature incorporation
- Reverse Brainstorming — Migration phasing risks
- Creative exploration — Naming
Topic 1: Traff.io Feature Incorporation¶
What Traffio Does (Current Third-Party)¶
Traffio is the dominant niche player in Australian traffic management workforce software. ASG Central currently integrates with it for traffic management clients. The goal is to REPLACE it with native Finnest features.
Traffio Feature Map → Finnest Modules¶
| Traffio Feature | Finnest Module | Build Priority | Notes |
|---|---|---|---|
| Booking & Scheduling | finnest_roster | Tier 1 (already planned) | Drag-and-drop scheduling, conflict detection, job cloning — all core roster features |
| Fatigue Policy Enforcement | finnest_fatigue | Tier 4 (industry module) | Weekly hours monitoring, minimum rest periods, shift interval tracking |
| Travel-Time Calculations | finnest_roster | Enhancement | Calculate travel between sites, factor into scheduling. New feature for roster. |
| Qualification/License Tracking | finnest_compliance | Tier 4 (already planned) | TC/TMI certifications, white cards, state-specific requirements |
| Expiry Notifications | finnest_compliance | Tier 4 (already planned) | Automated credential expiry alerts — already in Tier 3 autonomous agent design |
| Compliance Checks During Scheduling | finnest_roster + finnest_compliance | Enhancement | Block assignment if worker lacks required qualifications. Cross-module validation. |
| Vehicle Booking & Maintenance | finnest_assets | Tier 2 (already planned) | Vehicle registration, scheduling, maintenance, garage location |
| Equipment Booking & Maintenance | finnest_assets | Tier 2 (already planned) | Equipment tracking, maintenance schedules, work orders |
| EBA Payroll Calculations | finnest_payroll | Tier 2 (already planned) | Enterprise Agreement rate calculation — part of award engine |
| Bulk/Automated Invoicing | finnest_payroll | Tier 2 (already planned) | Client billing from timesheets |
| Digital Work Dockets | finnest_timekeep | Enhancement | Replace paper timesheets with digital docket sign-off. Mobile feature. |
| In-App Messaging | finnest_reach | Tier 1 (already planned) | Two-way office ↔ field communication |
| Job Confirmations | finnest_reach | Tier 1 (already planned) | Workers confirm shifts via app. Shift confirmation batch. |
| Photo Uploads | finnest_web + mobile | Enhancement | Attach site photos to jobs/forms. Mobile camera feature. |
| Custom Form Builder | NEW (not planned) | Phase 3+ | Configurable forms for site inspections, checklists, audits |
| GPS Fleet Tracking | finnest_assets | Enhancement | Real-time vehicle location on map. Integration with GPS provider or native. |
| Block Lists | finnest_roster | Enhancement | Prevent specific workers from specific sites/clients |
| Government Authority Data Sharing | finnest_compliance | Enhancement | Equivalent to Traffio's Asignit integration — real-time worksite data to authorities |
| Dark Mode (Mobile) | Mobile app | Nice-to-have | Night shift workers need this. Low effort in Flutter. |
| Digital Document Storage | finnest_core | Already planned | Document storage in S3, per-employee, per-job |
What's NEW That Finnest Doesn't Currently Plan¶
| Feature | Description | Where It Goes | Priority |
|---|---|---|---|
| Travel-Time Calculation | Calculate travel between sites, factor into scheduling | finnest_roster | Medium — useful for all field industries, not just traffic |
| Custom Form Builder | Configurable forms for inspections, checklists, audits | New or finnest_safety | Medium — replaces Typeform/paper for site-specific forms |
| Block Lists | Prevent worker ↔ site/client assignments | finnest_roster | Low — simple feature, add when needed |
| GPS Fleet Tracking (real-time) | Live vehicle location on map | finnest_assets | Low — integrate with GPS provider (Verizon Connect API) |
| Government Authority Integration | Real-time worksite data sharing | finnest_compliance | Low — niche (Asignit equivalent), defer until traffic clients onboard |
| Digital Work Dockets | Mobile sign-off replacing paper timesheets | finnest_timekeep + mobile | Medium — valuable across all field industries |
Traffic Management Industry Profile (Updated)¶
compliance.industry_profiles:
slug: "traffic"
display_name: "Traffic Management"
required_credential_types: [
"traffic_controller", # TC certification (state-specific)
"white_card", # General Construction Induction
"first_aid"
]
recommended_credential_types: [
"traffic_management_implementer", # TMI certification
"traffic_management_designer", # TMD certification
"road_safety_audit"
]
enabled_modules: ["safety", "fatigue", "assets"]
onboarding_steps: [
"right_to_work_verify",
"tc_certification_verify",
"white_card_verify",
"site_induction",
"ppe_issuance",
"vehicle_assignment"
]
compliance_rules: {
"fatigue_management": true,
"ppe_high_vis_required": true,
"site_plan_required": true, # TMP/TGS documentation
"travel_time_calculation": true,
"vehicle_inspection_daily": true,
"block_list_enforcement": true
}
terminology: {
"shift": "booking",
"location": "worksite",
"plan": "TGS",
"safety_meeting": "pre-start briefing",
"equipment": "traffic devices"
}
dashboard_config: {
"widgets": [
"active_worksites_map",
"credential_expiry_heatmap",
"fatigue_compliance_gauge",
"vehicle_status",
"daily_booking_board"
]
}
Recommendation¶
90% of Traffio's features are ALREADY planned in Finnest modules. The 10% gap is: 1. Travel-time calculation → add to finnest_roster (Phase 2) 2. Custom form builder → add to finnest_safety or new utility module (Phase 3) 3. Digital work dockets → add to finnest_timekeep mobile (Phase 2) 4. Block lists → add to finnest_roster (Phase 2)
The traffic management industry profile + finnest_roster + finnest_assets + finnest_fatigue + finnest_compliance covers Traffio's entire feature set natively. No separate app needed.
Topic 2: Laravel vs Elixir Go-Live (Scout + Verify in 2 Months)¶
The Question¶
Scout and Verify need to go live for ASG in ~2 months. Two options:
Option A: Ship Laravel app (AgenticAI-app) as planned. 1,220 tests, production-ready. Migrate to Elixir later.
Option B: Build Scout + Verify on Elixir directly. Skip Laravel deployment entirely. Go live on Elixir.
SWOT: Option A — Ship Laravel Now, Migrate Later¶
Strengths¶
- Production-ready TODAY. 1,220 tests, 46+ sprints, hardened code.
- Zero risk to go-live timeline. 2 months is buffer, not deadline.
- Proves revenue. AgenticAI starts generating credits immediately.
- Client sees working product. Builds trust for larger platform.
Weaknesses¶
- Throwaway work. Everything shipped in Laravel will be rewritten in Elixir.
- Two systems to maintain. Laravel app + v2 + (eventually) Elixir. Three codebases.
- Migration complexity. Data created in Laravel must be migrated to Elixir. New ID mappings.
- Team split. Maintaining Laravel while building Elixir divides attention.
Opportunities¶
- Revenue from day one. Scout credits + Verify credits start flowing.
- Production validation. Real-world usage reveals issues before Elixir build.
- Client locked in. Once using Scout/Verify, harder to walk away from v3.
Threats¶
- Laravel becomes permanent. "It works, why rewrite?" Organisational inertia.
- Data migration from Laravel to Elixir adds ANOTHER migration. v2 → Laravel → Elixir instead of v2 → Elixir.
- Laravel maintenance consumes Elixir development time.
SWOT: Option B — Build Scout + Verify in Elixir, Skip Laravel¶
Strengths¶
- No throwaway work. Everything built goes into the final platform.
- One migration path. v2 → Elixir. No intermediate Laravel step.
- Forces the Elixir architecture to be production-ready early. Validates the entire stack.
- Agent infrastructure (MCP, orchestrator) built from day one.
- Sets up for immediate Phase 1 migration (Recruitment → Onboarding).
Weaknesses¶
- 2 months is TIGHT. The PoC has 327 tests but is NOT production-ready. Needs: production auth, deployment pipeline, security hardening, external DB integration (admin_central, admin_atslive), email/SMS, UI polish, error handling, monitoring.
- Risk to go-live timeline. If Elixir build hits unexpected issues, there's no fallback.
- No proven production deployment. First-ever Elixir deployment for this team. Kamal/Docker for Elixir is untested.
- External database integration. Scout reads from admin_central and admin_atslive (MySQL). Elixir needs MySQL adapter (MyXQL) alongside PostgreSQL (Postgrex). PoC didn't test this.
Opportunities¶
- Everything after go-live is additive. Onboarding, CMS, Roster, T&A all build on the same platform.
- Agent features available from day one. Chat interface for Scout queries, Verify status checks.
- Proves Elixir in production. Eliminates the "will it work?" question permanently.
Threats¶
- 2-month deadline missed. Client loses confidence. "Switched to unproven tech and missed deadline."
- Production issues in first weeks. Elixir-specific issues (BEAM tuning, Oban configuration, release management) that the team hasn't encountered before.
- External DB MySQL + PostgreSQL dual-connection in Ecto. Untested pattern. May have edge cases.
What Would It Take for Option B to Work in 2 Months?¶
Week-by-Week Breakdown¶
Week 1-2: Foundation
✓ Umbrella project structure (finnest_core, finnest_recruit, finnest_onboard, finnest_web, finnest_agents)
✓ Auth (email/password, MFA) — phx.gen.auth already in PoC
✓ Multi-tenancy (org_id scoping)
✓ External MySQL connections (admin_central, admin_atslive via MyXQL)
✓ PostgreSQL core tables (organisations, users, feature_flags, audit_log)
✓ Deployment pipeline (Docker + Kamal or Fly.io for initial deploy)
✓ CI (GitHub Actions, mix test, mix format, mix credo)
Week 3-4: Scout Port
✓ Job orders, categories, candidate pools (Ecto schemas + contexts)
✓ Scoring engine (pure function pipeline — PoC already has this)
✓ Assessment system (questionnaires, token-auth public forms)
✓ Pool refresh from admin_central + admin_atslive
✓ Outreach (SES email, SMS provider)
✓ LiveView UI: dashboard, job orders, pipeline, candidate profiles
✓ 8 Oban workers ported
Week 5-6: Verify Port
✓ Document verification pipeline (4 AI agents as GenServers)
✓ Bedrock/Anthropic provider (hexagonal — PoC has Claude client)
✓ S3 document storage
✓ Manual review UI
✓ Budget management (per-org AI spend limits)
✓ Identity checklist
✓ 5 Oban workers ported
Week 7: Agent + Integration
✓ Agent orchestrator + MCP servers for Scout + Verify
✓ Agent chat UI (LiveView — PoC has AskLive)
✓ Admin Central sync (write verified data back)
✓ Command bar (Cmd+K)
✓ Notification system (basic)
Week 8: Hardening + Deploy
✓ Security review (auth, input validation, SQL injection prevention)
✓ Error handling + monitoring (Sentry or similar)
✓ Load testing (basic)
✓ Production deployment (AWS or Fly.io)
✓ UAT with internal team
✓ Go-live
Test target: 400+ tests (Scout + Verify + architecture)
Honest Assessment¶
It's possible but aggressive. The PoC already has Scout + Verify contexts (52 schemas, 327 tests). It's NOT a green-field build — it's production-hardening an existing PoC. The main risks are:
- External MySQL connection (admin_central, admin_atslive) — needs validation in week 1
- Deployment to production — first Elixir production deploy, unknown unknowns
- UI completeness — PoC LiveView pages exist but need polish for production
- No fallback if timeline slips — Laravel app is the safety net
The Hybrid Option (Option C)¶
Ship Laravel for Verify (AI agents are production-hardened). Build Scout on Elixir.
Reasoning: - Verify has 4 Claude AI agents with provider failover, budget management, manual review — battle-tested in Laravel - Scout is deterministic scoring (no AI) — simpler, lower risk to port - This lets Elixir prove itself on the simpler domain while Laravel handles the complex one - Migration: Verify migrates to Elixir in Phase 2 when infrastructure is proven
Problem with Option C: Now you have BOTH Laravel AND Elixir in production. Worse than either A or B alone.
Recommendation¶
Option B (Elixir direct) IF the external MySQL connection validates in Week 1.
Rationale: 1. The PoC is 70% of the way there. This is production-hardening, not building from scratch. 2. Every week spent on Laravel is throwaway work. 3. The migration phasing (Recruitment → Onboarding → CMS → Timesheet) flows naturally from an Elixir-first launch with Scout + Verify. 4. 2 months is tight but the PoC dramatically reduces the gap.
Safety net: If Week 1-2 reveals a showstopper (MySQL connection fails, deployment blockers), PIVOT to Option A (ship Laravel). Have the Laravel deployment pipeline ready as fallback.
Decision gate: End of Week 2. If foundation + external DB + deployment pipeline are working, commit to Option B. If not, fall back to Option A.
Topic 3: Migration Phasing (Revised Order)¶
User's Preferred Order¶
Phase 1: Recruitment (flows from Scout go-live)
Phase 2: Onboarding (flows from Verify go-live)
Phase 3: CMS and Rostering
Phase 4: Timesheet and Reporting
Phase X: Mobile Apps (Pact apps)
Why This Order Is Better¶
The original brainstorm (Session 4) proposed: People → Recruit → Roster → Timekeep → Payroll.
The user's order is better because:
-
Natural flow from Scout + Verify go-live. If Scout (recruitment) and Verify (document verification/onboarding) go live first, migration starts with the domains that are already active in Finnest. Users migrate FROM the domain they're already using on the new platform, not from a domain that doesn't exist yet.
-
Single handoff direction. Data flows: Finnest (recruitment) → ASG Central (everything else). One integration point. If we started with People (CMS), data would flow: Finnest (employees) ↔ ASG Central (timesheets, roster, leave) — bidirectional, much harder.
-
Each phase extends the boundary. Phase 1: Finnest handles recruitment, hands off to v2 for onboarding. Phase 2: Finnest handles recruitment + onboarding, hands off to v2 for CMS. Phase 3: Finnest handles recruitment + onboarding + CMS/rostering, hands off for timesheets only. Phase 4: Finnest handles everything.
Phase 1: [Finnest: Recruit] ──handoff──→ [v2: Onboard, CMS, Roster, T&A, Payroll]
Phase 2: [Finnest: Recruit, Onboard] ──handoff──→ [v2: CMS, Roster, T&A, Payroll]
Phase 3: [Finnest: Recruit, Onboard, CMS, Roster] ──handoff──→ [v2: T&A, Payroll]
Phase 4: [Finnest: Recruit, Onboard, CMS, Roster, T&A, Reporting] ──handoff──→ [v2: Payroll only]
Phase X: [Finnest: Everything + Mobile + Pact] ──→ [v2: Decommissioned]
Revised Migration Plan¶
Phase 1: Recruitment (Weeks 1-4 post go-live)¶
What migrates: - Job board postings (manual → SEEK/Indeed integration) - Candidate data from admin_atslive → finnest recruit.candidate_pools - Historical recruitment data (optional, can stay in v2)
Handoff to v2: - Successful candidates passed to v2 onboarding system - Integration: Finnest creates candidate record → triggers v2 onboarding via API/webhook
Effort: Low — Scout is already on Finnest. Migration is "start using Finnest for recruitment instead of v2."
Phase 2: Onboarding (Weeks 5-8 post go-live)¶
What migrates: - Onboarding workflows from v2 → Finnest onboarding_profiles - Document verification (already on Finnest via Verify) - Compliance checklists - Induction records
Handoff to v2: - Onboarded employees passed to v2 CMS for ongoing management - Integration: Finnest completes onboarding → creates employee in v2 via API
Effort: Medium — need to build the onboarding workflow UI and migrate v2 onboarding data.
Phase 3: CMS and Rostering (Weeks 9-16 post go-live)¶
What migrates: - Employee records from v2 candidates table → finnest people.employees - Client/site data → finnest clients.clients - Leave records → finnest people.leave_requests - Roster data from v2 joborders → finnest roster.shifts - Roster rules and codes
Handoff to v2: - Timesheets still entered in v2 (clock-in via v2 mobile app) - Payroll still processed in v2
Effort: High — this is the largest migration. 5,000+ employee records, client relationships, active rosters.
Phase 4: Timesheet and Reporting (Weeks 17-24 post go-live)¶
What migrates: - Timesheet data from v2 timesheets → finnest timekeep.timecards - Clock data from actatek → finnest timekeep.clock_events - Reporting queries/templates
Handoff to v2: - Payroll interface only — Finnest sends hours to KeyPay or v2 payroll - v2 becomes read-only archive
Effort: High — tiered migration (hot 6mo / warm 2yr / cold archive). Timezone conversion critical.
Phase X: Mobile Apps + Pact (Weeks 25-32 post go-live)¶
What migrates: - Flutter app points to Finnest API (instead of v2 API) - Pact features rebuilt: - Team Management → finnest_people (team views, supervisor tools) - Task Management → finnest_quotes (task lifecycle, assignment) - Vehicle Management → finnest_assets (vehicle registration, checklists, scheduling) - Pact mobile API → Finnest REST API
v2 status: Read-only archive → decommission after 3-month quiet period.
Effort: Medium — Flutter app refactor (~8-10 weeks as estimated in Session 7). Pact rebuild is new features in existing modules.
Pact Module Mapping to Finnest¶
| Pact Component | Finnest Module | Key Features |
|---|---|---|
| Team Management | finnest_people + finnest_roster | Team layouts, member management, supervisor views |
| Task Management | finnest_quotes | Task creation, lifecycle (new→progress→feedback→complete), job breakdown |
| Vehicle Management | finnest_assets | Vehicle registration, daily/weekly checklists, driver assignment, scheduling |
| Pact Audit System | finnest_safety + finnest_compliance | Audit questions/answers, compliance checklists, photo evidence |
| Pact Mobile APIs | finnest_web (REST API) | /api/v1/teams/, /api/v1/tasks/, /api/v1/vehicles/* |
Topic 4: Naming¶
Commercial Name: Hexis¶
The user is leaning toward Hexis as the commercial/product name. This is strong: - Short, distinctive, professional - Derived from @Hexis / AtHexis (already in client proposals) - Domain likely available or already owned - Works as: "Hexis Platform", "Hexis HR", "Hexis Workforce" - AI agents could be: "Hexis Scout", "Hexis Verify", "Hexis Reach", "Hexis Pulse"
Internal Codename: Malazan Book of the Fallen Reference¶
The user wants a MBotF reference for the internal project codename (used in code, DB tables, internal discussion). "Finnest" is already a MBotF reference (a soul-vessel containing the power and memories of a Jaghut Tyrant).
Top Candidates¶
| # | Name | What It Is | Why It Works | Typing/CLI Feel |
|---|---|---|---|---|
| 1 | Convergence | Central concept — where powers, factions, and destinies collide | The platform IS a convergence of industries, AI, and workforce domains. Every fan knows it. Self-explanatory even to non-fans. | convergence deploy, mix convergence.setup — slightly long (12 chars) |
| 2 | Azath | Sentient structures that contain immense power. Self-maintaining, indestructible, eternal. | Fault-tolerant by nature. Contains, organises, endures. Perfect metaphor for resilient infrastructure managing powerful entities. | azath deploy, mix azath.setup — 5 chars, clean |
| 3 | Kurald | Prefix meaning "realm/world" (Kurald Galain, Kurald Emurlahn) | Implies a self-contained domain/platform. Distinctive. | kurald deploy, mix kurald.setup — 6 chars, good |
| 4 | Aren | Major port city, administrative hub of the Malazan empire | Short, punchy, suggests arena of operations. Administrative hub = workforce platform. | aren deploy, mix aren.setup — 4 chars, excellent |
| 5 | Finnest | Soul-vessel of a Jaghut Tyrant. Concentrated power and memories. | Already in use. Suggests concentrated repository of intelligence and capability. | finnest deploy, mix finnest.setup — 7 chars, good |
| 6 | Bridgeburners | Legendary military company. Resilience, impossible odds, getting it done. | Most iconic MBotF reference. Shortens to "BB" or "Bridge." | bridge deploy — 6 chars if shortened |
| 7 | Bonehunters | Army forged through the impossible. Endurance, scale. | Forged-through-hardship resonance. | Long (11 chars) — bone deploy? |
| 8 | Letheras | Capital obsessed with commerce, debt, economic systems | Direct thematic link to workforce/economic management. | letheras deploy — 7 chars, good |
| 9 | Dragnipur | Anomander Rake's sword containing an entire realm within it | Contains multitudes. Entire system inside a single artifact. | dragnipur — 8 chars, distinctive |
My Recommendation¶
Keep "Finnest" as the internal codename. Here's why:
- Already in use. All 11 brainstorming documents, the folder, the schemas, the OTP app names use
finnest_*. Renaming is friction. - Thematically perfect. A Finnest is a concentrated vessel of immense power and knowledge — exactly what this platform is: concentrated workforce intelligence.
- 7 characters. Good length for code (
finnest_core,finnest_recruit). Not too long, not too short. - Not obvious to non-fans. It's an Easter egg, not a reference that needs explaining.
- Doesn't conflict with commercial name. "Hexis" externally, "Finnest" internally — clean separation.
However, if you want something different:
"Azath" is the strongest alternative — 5 characters, self-maintaining/fault-tolerant thematic, distinctive. The Azath Houses in MBotF are literally sentient structures that contain and organise immense power within elegant architecture. That IS the platform.
azath_core, azath_recruit, azath_roster — reads well.
Naming Architecture¶
| Context | Name | Usage |
|---|---|---|
| Commercial/Product | Hexis | Marketing, client-facing, proposals, invoices, UI branding |
| Internal/Code | Finnest (or Azath) | Repo name, OTP apps, DB schemas, internal docs, team discussion |
| AI Agent Suite | Hexis Scout / Verify / Reach / Pulse | Product pages, client-facing agent names |
| Domain | hexis.au or hexis.com.au | Commercial website |
| GitHub Org/Repo | finnest or azath | Private repos |
Summary of All Four Topics¶
1. Traff.io¶
90% of Traffio features are already planned in Finnest modules. Add 4 features: travel-time calculation, custom form builder, digital work dockets, block lists. Traffic management industry profile covers the rest.
2. Laravel vs Elixir Go-Live¶
Recommended: Option B (Elixir direct) with a Week 2 decision gate. If external MySQL validates and deployment pipeline works by end of Week 2, commit to Elixir. If blockers emerge, fall back to Laravel (Option A). The PoC is 70% there — this is hardening, not building from scratch.
3. Migration Phasing¶
User's order (Recruitment → Onboarding → CMS/Rostering → Timesheet/Reporting → Mobile/Pact) is better than original because it flows naturally from Scout + Verify go-live and maintains a single handoff direction from Finnest → v2.
4. Naming¶
- Commercial: Hexis
- Internal codename: Finnest (keep — it's already everywhere and thematically perfect)
- Alternative: Azath (if renaming is desired — strongest MBotF alternative)
Statistics¶
- Topics covered: 4
- Ideas generated: 40+
- Key decisions: 4
- Techniques applied: SWOT, Mind Mapping, Reverse Brainstorming, Creative Exploration
Generated by BMAD Method v6 - Creative Intelligence