Automation that finds its own work
The Automation Factory reads Jira, Tempo and Confluence for the work people repeat by hand, and proposes each fix as a scored candidate with its evidence attached. A named person approves it. The Factory builds it in the right tool for the job, registers it, and leaves it switched off until its owner turns it on.
- A person approves every candidate
- Nothing goes live until its owner says so
-
Most automation starts with a hunch and ends in a corner
The same job, by hand, every week
Status packs, renewal chases, triage notes. The repetition is right there in the tickets and the timesheets, and nobody has time to look for it.
Built by whoever had a spare afternoon
The tool gets picked by habit, the risk gets judged by the person building it, and nobody else signs off.
Nobody knows what exists
A workflow here, a script there, an agent somebody made in a trial. No register, no owner, no spec to read.
Broken without saying so
An automation fails quietly for weeks, and the work it was meant to save comes back without anyone noticing why.
From repeated work to a registered, running asset
One loop, six steps, run every week. The Factory does the reading, the scoring and the building. People make every decision that matters.
- 1
Scan
Every Monday night the analyser reads Jira, Tempo and Confluence for work that repeats, and names each pattern with the tickets that prove it.
- 2
Score
Each candidate is scored on six risk axes into Green, Amber or Red, and given a lane: the kind of tool it should be built as.
- 3
Approve
The run is published as a page. A named person proceeds from Slack or the dashboard, and one gate enforces the tier rules either way.
- 4
Build
An approved candidate becomes a register ticket and a spec, then a build in its lane. Code changes arrive as a pull request, never straight to production.
- 5
Activate
Every build lands switched off. Its owner presses Activate, and the Factory carries it out. It never switches anything on by itself.
- 6
Watch
Factory Lane reads every build live. A failure stays open until a later clean run clears it, and the next scan sees what was built.
Evidence, risk, the right tool, and a watch on all of it
Every candidate shows its working
- Each candidate cites the tickets it found, so you can open them and check the pattern is real before anything is built.
- It says what already exists, so the Factory proposes extending an asset before building a second one.
- Time saved is stated on its basis. Hours estimated from ticket counts and hours measured from timesheets are shown side by side and never added into one number.
The same status summary written by hand for each client, every Friday, by four people.
A status report skill for one client. Extend it rather than build a second.
Claude skill, with a Confluence page as a secondary output.
Six axes decide the risk, not the builder
- Blast radius, system class, reversibility, external visibility, lane confidence and credential exposure, each scored 0 to 2 with a written reason.
- The total sets the tier: Green is a one-click approval, Amber is approved with the reasons on screen, Red needs a written reason on the ticket.
- Hard overrides sit above the score. A write to a finance or cloud-infrastructure system has no build path at all, and goes to a human runbook.
Amber. Approved explicitly, with each axis's reason shown before the approval is recorded.
The right tool for each job, chosen by a rule
- One decision tree picks the lane from what the automation must produce: a Claude skill or project, a Rovo or Copilot agent, a Trigger.dev task, a web tool, content, a configuration change, and more.
- Production runs on Trigger.dev. Quick workflow tools are kept for demos and prototypes, so a production job never depends on one.
- Driving a browser is the last resort, chosen only where no API exists, and it scores higher risk when it is.
The primary output is a reusable instruction set that people run from chat, so the skill lane. The summary is published as a Confluence page, so Content rides beside it.
Every build watched, live, until it is fixed
- Reads every build live across Trigger.dev, GitHub Actions and the workflow tools, and joins each one to its register ticket.
- A failure stays open until a later clean run clears it. Repeats are counted, and the run to read first opens with its log.
- A source the lane cannot reach shows as could not read, never as all clear.
Build Spec Studio
Turn one sentence into a build spec, a Confluence-ready page and a build prompt, with the Factory rails already laid over it.
One register
Every asset is a ticket with an owner, a version and a spec page, so what exists can always be found and nothing is built twice.
The Factory Council
Seven expert seats debate the harder next steps and return the real disagreements as decisions for a person to make.
Credentials stay in the vault
No secret is ever written into an asset, a spec or the code. Each one is brokered from the vault and recorded in a register.
Claude, on a budget
Every model call is logged against the feature that made it, with the day's budget checked before it runs.
A handoff every day
Every working day on the Factory is meant to end with a written handoff. The next session reads it back, and a missing day is flagged first.
One gate, whichever button you press
- Proceed from Slack or from the dashboard: both tick the same rows on the run page and fire the same gate, so there is never a second, softer way in.
- The gate re-derives every tier from the six axes itself, rather than trusting the label it was handed.
- A Red candidate waits for its written reason. A write to a Red system is refused outright, whoever asks.
- A row is processed once. Pressing Proceed twice cannot raise two tickets.
Eight rules every build runs inside
Automation earns trust by being boring about risk. These rules are written into the doctrine the Factory reads, laid over every spec, and checked before a build can merge.
A person approves every candidate
Nothing the scan finds becomes work until a named person proceeds on it. The Factory recommends; people decide.
No write to a Red system
Finance and cloud-infrastructure systems are Red. A step that would write to one has no build path and goes to a human runbook.
Amber writes, one at a time
A change to a business system such as Jira or HubSpot goes through one controlled path, with each change approved.
Built is not switched on
Every asset lands not in service. The Factory carries out its owner's Activate and never originates one.
No secret in the asset
A credential is brokered from the vault and recorded in the register. It is never written into code, a spec or a page.
Every Claude call is guarded
Each model call is logged, attributed to its feature and checked against the day's budget before it runs.
Silence is not success
A failure stays open until a clean run clears it. A source that cannot be read says COULD NOT READ, never all clear.
Time saved, on its basis
Estimated and measured hours are shown apart and never added. A candidate nobody sized is missing, not zero.
See the Factory run on a real business
Talk to Design Industries. We will walk you through a weekly run on our own studio, from the scan to a build waiting for its Activate, and talk through what the Factory would look for in yours.
AutomationFactory
- hello@di.net.au
- 1300 73 63 63
- Level 1, 678 Victoria St, Richmond VIC 3121
- di.net.au
