← AI Pilot Resources
BLE · AI Pilot · Readiness Guide
Mode C · go deeper · the full thinking

What we'd need from you, and the thinking behind it

Honest framing first, Mark: we don't know BLE deeply yet. This is an early read of your brief — a rough first draft of how your three tools could work, and what we'd need to build them well. It's not a finished plan. What it does is gather the decisions and real examples that let us scope properly, and explain the thinking behind each. Read it through for the full reasoning — or if you'd rather just act, the faster ways in are linked just below.

Early draft · for discussion · pre-kickoff
Stage
Early scoping — before kickoff
Effort from you
One sitting, or a short call
North Star
Ground truth & measurable ROI
◆
Why we're doing it this way

Everything here points at one thing: we measure against real work. The tools only earn their keep if their output stands next to what you'd actually have sent and holds up. So wherever you see the ◆ mark, that's an artifact we use to set a baseline — the "before" we measure the "after" against. No vague claims about AI value. Real examples, real comparisons, real time saved.

In plain terms, what should all this buy back? On current assumptions, roughly of producer time in a typical month once all three tools are running — .PLACEHOLDER · PENDING MARK'S FIGURES

◆ Illustrative on purpose. These are the “before” figures we replace with your own — measured against real work, not asserted — at the discovery call. Each tool's figure sits with that tool below, with a line on how we'd measure it.

Tell me A question you answer
Show me A real file for me to look at
Baseline ◆ Sets a measurable "before"
Faster ways in The checklist → Be walked through it → This page is the full reasoning — read it, don't tick it.
01
Where we actually are

A first sketch, not a finished plan

Think of the whole engagement as a scoping process that sharpens in stages. This document is an early one.

The next stage is a discovery call — where we sit down and I capture how BLE really runs: the judgement, the exceptions, the places the real time goes, the things a written brief can never carry. What you see here is what I could pull from a first reading of your brief; the call is where it gets real. What you gather from this guide is exactly what makes that call sharp — real decisions and real examples to work from, instead of starting at a blank page.

So treat nothing here as locked. It's a starting position to react to, correct, and add to. The more you push back, the better the scope gets.

Two kinds of thing I'm asking for

Almost everything below is one of two types, and the difference matters more than it looks.

Things you can tell me — does a document exist, who signs what, where the final files live. Quick. You answer off the top of your head.

Things I need to see — actual files from past projects. How something is written decides how easily a tool can read it. "We have supplier risk assessments" and "here are three of them" can tell very different stories — three different layouts is a different job from three tidy identical ones. Looking is how I avoid guessing, and guessing is what makes estimates wrong.

The single most useful habit for the whole exercise: for anything I ask about, dig out three real examples from past projects. One example flatters. Three show me how much things vary — and the variation is the work.

02
The build, in plain sight

Your three tools — and what's really inside each one

Your brief described the three tools by what they produce. Here's the same three by how they actually work: each as a sequence of steps, like a conveyor belt. Every step below may become its own small specialist "agent," with the checkpoints between them as the hand-offs. Wiring those hand-offs so they're reliable is where the real build time goes.

The steps themselves are the easy part to list — a quick AI chat will happily produce them. What it leaves out is everything marked in red: the validation checks (do the inputs pass?), the evals (is the output actually good enough to move on?), and the human sign-offs. Those are where reliability lives.

A tool that drafts a risk register in seconds is easy. A tool you can trust to do it the same way every time, that knows when to stop and ask rather than guess, and that leaves a clean trail for the person who signs — that is the engineering, and it's most of the work. It's also exactly why I need real examples from you: you can't build or test a single one of those red checkpoints without real work to test it against.

TOOL 1

Risk Assessment Officer

most checkpoints · a human signs the result
Here the payoff isn't hours, it's defensibility: , and it's .PLACEHOLDER · PENDING MARK'S FIGURES
How we'd measure it
1
Take in the project — brief, floor plans, supplier RAs and SWMS, venue risk docs, schedule.
ValidationInputs are checked for completeness and readability. Anything missing or unreadable is flagged, and the line halts rather than guessing.
2
Identify the relevant hazards and activate them from the Master Hazard Library.
3
Draft the project-specific risks.
EvalEvery drafted risk must trace back to a source document or the library — no invented hazards.
4
Score each risk against your agreed method (likelihood × consequence) and classify it.
EvalEach rating is checked against the method. Anything outside it is rejected, not waved through.
5
Suggest controls, owners and evidence; assemble the missing-information checklist; draft the dynamic review sheet.
6
Populate the BLE risk register, with a full trail of how each line was reached.
Human sign-offA named person reviews and signs at the required level. Mandatory and blocking — nothing is "live" until then.
7
Issue.
TOOL 2

Supplier Brief Generator

fewer checkpoints · reviewed before sending
By hand a brief pack runs about ; the aim is a first draft in — turnaround from to .PLACEHOLDER · PENDING MARK'S FIGURES
How we'd measure it
1
Choose the supplier category and pull the latest approved project information.
ValidationDraws from approved data only. If key details are missing, it flags and pauses instead of filling the gaps itself.
2
Select the correct BLE template for that category.
3
Populate it — overview, scope, timings, deliverables, assumptions and exclusions, pricing format, approval dates — and attach the relevant documents.
4
Draft the covering email.
EvalOutput checked against the template — right fields, right tone for a supplier, nothing fabricated.
5
The producer reviews.
Human sign-offA person approves before anything leaves BLE.
6
Send.
TOOL 3

Figma Pitch & Proposal Builder

fewer checkpoints · reviewed before the client sees it
A pitch that takes today is aimed at for a first draft — turnaround from to .PLACEHOLDER · PENDING MARK'S FIGURES
How we'd measure it
1
Take the inputs — client brief, brand guidelines, approved concept direction, selected imagery, budget parameters, page count.
ValidationConfirm the inputs are approved and complete enough to start.
2
Propose the deck flow — the page-by-page structure.
3
Write the page-by-page copy.
4
Lay it into the BLE Figma layouts; place imagery and shot lists; keep headings and formatting consistent.
EvalLayout and copy checked against house standard and brand rules.
5
Export a draft PDF.
Human sign-offDesign and copy reviewed before the client ever sees it.
6
Finalise.

One honest caveat on the order. The two generative tools have fewer red checkpoints, which is why they're the early, visible wins — we build those first. The risk tool has the most, because a person signs the result and carries it. That's not a tool being "harder for the sake of it" — it's the weight of what it produces, made into engineering.

03
The one question everything hinges on

How you score risk — written down, or in your head?

Of everything here, this is the one that moves the most. Worth answering carefully and on purpose.

Decide first · affects everything downstream PIVOT

Is there a written method for rating risks?

By that I mean an actual document: a grid of likelihood against consequence, what each rating means, and which rating forces things up the chain. Either it exists as a file — or it lives in your judgement, applied case by case, which is completely normal for a business that runs on experience.

The risk tool can't reason without an explicit method to reason with (those eval checkpoints above need a rule to check against). So the answer simply tells us which path we're on: confirm one that exists, formalise a partial one, or sit together for one focused session and write it down. Good news worth knowing: SafeWork NSW — your own regulator — publishes risk-assessment frameworks. If we write yours, we're calibrating against a recognised standard, not inventing from a blank page. That makes it faster, and it makes the result defensible.

04
Tell me · decisions only you can make

The judgement calls

Plain questions, each with a line on why it matters. None are heavy. Most you can answer in a sentence — and "not settled yet" is a perfectly good answer this early.

D1

Ways of working — written down, or in people's heads?

Do you have step-by-step guides for how a project runs? If they're written, point me at them in the Drive.

Why it matters. The tools copy how BLE actually works. If nothing's written, that's a short writing job at the start — part of what the setup buys you, not extra homework.

Tell meShow me · if written
D2

The intake form — is there one standard starting point?

Is there a standard form you fill in when a new project kicks off, or should we build the single approved version together?

Why it matters. It's the one input all three tools read from. Get it right once and it saves rework across every tool at once.

Tell meShow me · 3 filled-in copies
D3

What counts as "approved" — where does final live versus draft?

Where does signed-off, final project data sit, as opposed to works-in-progress?

Why it matters. The tools only ever touch approved material. They need one clear rule for where that is — without it, every tool guesses, and they won't all guess the same.

Tell me
D4

Supplier brief templates — which categories have one?

Which supplier types already have a brief template — AV, styling, catering, entertainment, security, transport, venue — and which need building?

Why it matters. The brief writer only works from approved templates, so I just need to know where the gaps are. Missing ones are small jobs, not blockers.

Tell meShow me · one of each that exists
D5

◆ Risk sign-off — who signs, and at what level?

Who are the named people who sign off a risk register, and at what rating? For example: who signs a medium, and who has to sign a high?

Tell meBaseline ◆
05
Show me · the part that keeps us honest

Real files from real projects

This is where ground truth comes from. Pick one completed project as our test case — ideally one that has all three: full approved supplier briefs, a pitch deck that won, and a finished risk register. One project that exercises all three tools is the prize, because it lets us measure every tool against work you actually delivered.

Then pick one current, in-flight project as fair game for a live run. A past project proves a tool works. A live one proves it works under pressure.

This section is the why behind the files — what each one tells me, and how we measure with it. To tick them off as you gather, the checklist carries the same list, built to act on.

What to bring — and why each earns its place

From your chosen completed project. The ◆ items are the ones we measure against — they set the "before."

◆ Approved supplier briefsThe full set you actually sent. Ground truth for the brief writer.
◆ The winning pitch deck2–3 past pitches that won, if you can. They define your house voice.
◆ The completed risk registerThe finished article, as signed. What we grade the risk tool against.
Supplier RAs & SWMSA few real ones, as suppliers sent them. Tidy or messy — I need to see which.
Floor plansHowever they arrive — CAD, PDF, or a photographed sketch. The format matters.
Venue risk documentsWhatever the venue provides. Standardised, or different every time?
The filled-in intake formAs completed for this project — so I see what's really captured.
A few brand piecesLogos, colours, fonts, a template or two — wherever they live in the Drive.
06
Switch on · mostly confirmations

Access and permissions

Largely things I already have — I just want them made explicit for this purpose. Nothing onerous.

S1

Figma — confirm I'm into the design library

Confirm I have access to the design library and file keys, so the pitch builder can drop into your real components instead of rebuilt copies.

Confirm
S2

Drive — just a yes

I already have Drive access since I set it up. I'd like your explicit OK to use the brand and project files to build and refine the tools, not only to look at them.

Confirm
S3

Fonts & images — flag anything licence-restricted

Flag any paid fonts or licensed images where the licence limits where they can be used. The tools' output needs to be safe to send and reuse outside BLE.

Tell me
07
Worth saying plainly

Three things that look small now and bite later

Who signs off risk is a liability call, not a form field. The tool never signs anything. It drafts; a named person signs; that person carries it. Worth deciding on purpose, not by default — and it's quick to write down, but the deciding can take longer than it looks, so it's worth starting early.

"Approved" needs exactly one rule. If there's any wobble about what counts as final, every tool ends up guessing — and they won't all guess the same way. One clear rule removes the whole problem.

Informal ways of working are completely fine. If it mostly lives in people's heads, that just means a short writing-down step at the start. That's the work the setup phase is for — part of what you're getting.

What happens next

You gather; then we sit down and make it real.

Once you've worked through the questions and pulled the files together, the next step is the discovery call — where I capture how BLE actually runs, the nuance a brief can't carry, and where the real time goes. What you see in this document is a first sketch from reading your brief; the call is where it gets real, and where the scope firms up. From there I build and run the first tool — the supplier brief writer — on my own machine here, and you see working results side by side with the real thing. That's your first visible win. We start small and let each piece earn its place before we lean on it harder.

From Nick
← Back to AI Pilot Resources