01 / 08EVENT
A new document arrives
Field study notes
- Source document received
- Original retained
- Ready to review
Received
A research document starts the work. The original stays available throughout.
OPERATIONAL SYSTEMS ASSESSMENT
Understand the system before deciding what to build.
Bring us an operational problem.
We map how it works today, identify where it breaks down and determine what system could improve it.
The first qualification conversation is free. The assessment itself is a paid engagement.
ENGAGEMENT SPECIFICATION
OSA · REV 01- SCOPE
- One operational problem, one operation, as it runs today.
- DURATION
- Typically 2–3 weeks, fixed at qualification.
- METHOD
- Interviews, system access review, data sampling, process walk-through on site or remote.
- YOUR TIME
- Around 6–8 hours from the people who run the operation.
- OUTPUT
- 14 deliverables, one recommended pilot, one executive readout.
- COMMERCIAL
- Fixed fee, agreed before start. An indicative range is shared on the first call. No obligation to proceed to a pilot.
- HONESTY
- If no system should be built, the readout says so.
ASSESS → PILOT → ENGINEER → OPERATESTAGE 1 OF 4
WHO THIS IS FOR
You recognise the operation in at least one of these.
The assessment is for operations that already run, and already cost more than they should. It is not for ideas without an operation behind them.
- 01
Recurring manual work
The same steps, by the same people, every day or week.
- 02
Information moving manually between systems
Copy, paste, re-key, export, attach, forward.
- 03
Spreadsheet-dependent operations
A spreadsheet that one person understands is holding the process together.
- 04
Limited monitoring
You find out something went wrong when a customer tells you.
- 05
Disconnected physical and digital information
What happens on site and what the system says are two different stories.
- 06
Unclear automation opportunity
You suspect AI or automation could help, but not where, or whether it is worth it.
WHAT WE EXAMINE
Ten lenses on one operation.
Every lens produces evidence, not opinion: who does what, which system holds which record, where a decision is made and by whom, where work waits. The bottleneck is usually visible only when all ten are laid side by side.
01 · PEOPLE
Roles, workload, who actually does the step.
02 · SOFTWARE
Applications in use, and the ones worked around.
03 · DATA
Where each record lives, its quality, who owns it.
04 · DEVICES
Sensors, equipment, cameras and what they could report.
05 · DECISIONS
Which are rules, which are judgement, who makes them.
06 · HANDOFFS
Where work changes hands, and how long it waits there.
07 · EXCEPTIONS
What goes wrong, how often, and where it goes.
08 · APPROVALS
Which steps need sign-off, by whom, and why.
09 · PERMISSIONS
Who may see, change and act on what.
10 · METRICS
What is measured today, and what should be.
DELIVERABLES
Fourteen documents. One recommendation.
Everything is written so it is useful whether or not you continue with us. The system map and requirements are yours to hand to any engineering team.
| Nº | DELIVERABLE | ANSWERS | GROUP |
|---|---|---|---|
| 01 | Current-State System Map | How the operation actually runs today, across people and systems. | UNDERSTAND |
| 02 | Bottleneck Analysis | Where work waits, repeats or piles up, with evidence. | UNDERSTAND |
| 03 | Failure-Point Analysis | Where and how often things go wrong, and what it costs. | UNDERSTAND |
| 04 | Responsibility Classification | Which decisions are rules, which are judgement, which need a person. | UNDERSTAND |
| 05 | Data Requirements | Which records a system would need, where they are, how clean they are. | REQUIREMENTS |
| 06 | Integration Requirements | Which applications must connect, and how. | REQUIREMENTS |
| 07 | Permission Requirements | What any component may read, propose and do. | REQUIREMENTS |
| 08 | Edge Requirements | Whether physical sensing or on-site processing is needed, and where. | REQUIREMENTS |
| 09 | Opportunity Matrix | Every candidate improvement scored on value, feasibility and risk. | DECIDE |
| 10 | Recommended Pilot | The one system to build first, and why that one. | DECIDE |
| 11 | Success Metrics | The number the pilot must move, its baseline and how it is measured. | DECIDE |
| 12 | Indicative Architecture | The system drawn in the Stacx24 system language, with human nodes marked. | DECIDE |
| 13 | Risk Notes | What could make the pilot fail, and what we would do about it. | DECIDE |
| 14 | Executive Readout | One session, one document, a clear recommendation. Including "do not build". | DECIDE |
WHAT HAPPENS NEXT
The assessment is the first stage, not a sales step.
Each stage has a decision at the end of it, made by you. Most engagements move to a single pilot. Some stop at the readout, because the right answer was a process change, not a system.
01 · ASSESSMENT
2–3 weeksMap the operation, find the bottleneck, deliver the readout.YOU DECIDE: PROCEED?02 · PRIORITISED OPPORTUNITY
One bottleneck chosenScored by operational value, feasibility and risk. One is selected.YOU DECIDE: WHICH ONE?03 · PILOT
6–12 weeksOne focused system, a named owner, a baseline and a measured outcome.YOU DECIDE: SCALE?04 · PRODUCTION SYSTEM
Engineered to runHardened, integrated, with permissions, logging and escalation built in.HANDOVER & RUNBOOK05 · OPERATE & IMPROVE
OngoingObserved and measured against its number. Improved on evidence.MONTHLY OUTCOME REPORT
CORE SYSTEM MODEL
The system is the product. Technology is a component.
- Not every step needs AI.
- Some need rules.
- Some need software.
- Some need edge processing.
- Some need people.
We engineer the right combination.
Research assistance
IN THE OPERATION
A document arrivesFrom the research team
02 / 08CONTEXT
Bring the background together
Document + background
- Source details attached
- Related records found
- Approved labels loaded
Context attached
Existing records, source details and the approved label list give the document context.
03 / 08PROCESSING
Check the details first
Document checks
- Duplicate check complete
- Required details present
- Text ready for review
Checks complete
Software checks for duplicates and missing information before any AI suggestion.
04 / 08INTELLIGENCE
Suggest a label, within scope
Suggested label
- Field study
- Supporting passage highlighted
- Awaiting researcher review
Suggestion only
AI proposes a label from the approved list. It cannot publish the label itself.
05 / 08DECISION
A researcher makes the decision
Label review
- Source passage checked
- Suggested label reviewed
- Field study approved
Reviewed by researcher
The researcher reads the supporting passage and approves or corrects the suggestion.
06 / 08ACTION
Update the research record
Research record
- Label: Field study
- Source linked
- Review retained
Saved to record
Only the approved label enters the record, alongside its source.
07 / 08OBSERVATION
Record what actually happened
Activity record
- Suggestion recorded
- Reviewer decision recorded
- Save confirmed
Outcome recorded
The system records the suggestion, the review and the saved result so the team can inspect them.
08 / 08IMPROVEMENT
Review the labelling rules
Next-cycle guidance
- Review corrections
- Agree guidance changes
- Use approved guidance next time
Feedback to the next event
The team reviews corrections and agrees changes to the guidance before the next document.
Each outcome informs the next cycle.
- 01 · EVENTA new document arrives
A research document starts the work. The original stays available throughout.
- 02 · CONTEXTBring the background together
Existing records, source details and the approved label list give the document context.
- 03 · PROCESSINGCheck the details first
Software checks for duplicates and missing information before any AI suggestion.
- 04 · INTELLIGENCESuggest a label, within scope
AI proposes a label from the approved list. It cannot publish the label itself.
- 05 · DECISIONA researcher makes the decision
The researcher reads the supporting passage and approves or corrects the suggestion.
- 06 · ACTIONUpdate the research record
Only the approved label enters the record, alongside its source.
- 07 · OBSERVATIONRecord what actually happened
The system records the suggestion, the review and the saved result so the team can inspect them.
- 08 · IMPROVEMENTReview the labelling rules
The team reviews corrections and agrees changes to the guidance before the next document.
Everyday operations
IN THE OPERATION
A request arrivesFrom the operating team
01 / 08EVENT
A request starts the work
New work request
- Request received
- Source application linked
- Handoff opened
Received
An incoming request starts a handoff between the tools your team already uses.
02 / 08CONTEXT
Attach the details once
Request background
- Existing record attached
- Current state checked
- Owner identified
Context attached
The system brings together the request, existing records and its responsible owner.
03 / 08PROCESSING
Let the rules route the work
Connected applications
- Request inbox → work queue
- Required details checked
- Work queue → owner workspace
Handoff prepared
Defined rules check the request and pass its details between connected applications.
04 / 08INTELLIGENCE
Rules are enough here
Routing rule
- A required detail is missing
- Exception route selected
- Named owner notified
No AI needed
This example needs no AI decision. Defined rules identify an exception and send it to its owner.
05 / 08DECISION
The owner resolves the exception
Exception review
- Exception opened
- Missing detail supplied
- Owner confirms next step
Reviewed by owner
A named person supplies the missing detail and confirms that the work can continue.
06 / 08ACTION
Complete the handoff
Completed handoff
- Confirmed details transferred
- Next application updated
- Owner notified
Handoff complete
The confirmed information reaches the next application and the work continues.
07 / 08OBSERVATION
Keep the outcome visible
Activity record
- Exception recorded
- Resolution recorded
- Handoff confirmed
Outcome recorded
The system records completion and exceptions so the team can see what happened.
08 / 08IMPROVEMENT
Review the handoff rules
Next-cycle guidance
- Review recurring exceptions
- Agree routing changes
- Apply approved rules next time
Feedback to the next event
The team reviews repeated exceptions and approves rule changes for future requests.
Each outcome informs the next cycle.
- 01 · EVENTA request starts the work
An incoming request starts a handoff between the tools your team already uses.
- 02 · CONTEXTAttach the details once
The system brings together the request, existing records and its responsible owner.
- 03 · PROCESSINGLet the rules route the work
Defined rules check the request and pass its details between connected applications.
- 04 · INTELLIGENCERules are enough here
This example needs no AI decision. Defined rules identify an exception and send it to its owner.
- 05 · DECISIONThe owner resolves the exception
A named person supplies the missing detail and confirms that the work can continue.
- 06 · ACTIONComplete the handoff
The confirmed information reaches the next application and the work continues.
- 07 · OBSERVATIONKeep the outcome visible
The system records completion and exceptions so the team can see what happened.
- 08 · IMPROVEMENTReview the handoff rules
The team reviews repeated exceptions and approves rule changes for future requests.
Connected fields
IN THE OPERATION
A field reading arrivesFrom a connected sensor
01 / 08EVENT
A sensor reads the field
Incoming field reading
- Sensor reading received
- Field identified
- Reading time attached
Received
A new field reading starts the cycle, connecting conditions on the ground to the system.
02 / 08CONTEXT
Put the reading in context
Field background
- Field history attached
- Recent readings loaded
- Current conditions attached
Context attached
Field history and recent conditions help the team interpret the new reading.
03 / 08PROCESSING
Check the signal near the field
Edge processing
- Local checks run
- Incomplete readings flagged
- Relevant readings forwarded
Local checks complete
Local edge checks validate readings before relevant information reaches the monitoring application.
04 / 08INTELLIGENCE
Prepare a suggested response
Response proposal
- Field context considered
- Suggested response prepared
- Sent for agronomist review
Suggestion only
The system uses the checked information to propose a response within its defined scope.
05 / 08DECISION
The agronomist reviews
Agronomist review
- Conditions reviewed
- Proposal checked
- Response approved
Reviewed by agronomist
The agronomist checks the proposal and approves or adjusts it before it reaches the operator.
06 / 08ACTION
Send the approved proposal
Operator work item
- Approved proposal attached
- Instructions available
- Delivered to operator
Ready for the operator
The approved proposal reaches the operator with the instructions they need.
07 / 08OBSERVATION
Keep watching the conditions
Field activity record
- New readings recorded
- Operator reports attached
- Outcome ready for review
Observation continues
New readings and operator reports help the team understand what happened next.
08 / 08IMPROVEMENT
Review the next field cycle
Next-cycle guidance
- Review field observations
- Agree guidance changes
- Use approved guidance next time
Feedback to the next event
The agronomist reviews the observations and agrees guidance for the next cycle.
Each outcome informs the next cycle.
- 01 · EVENTA sensor reads the field
A new field reading starts the cycle, connecting conditions on the ground to the system.
- 02 · CONTEXTPut the reading in context
Field history and recent conditions help the team interpret the new reading.
- 03 · PROCESSINGCheck the signal near the field
Local edge checks validate readings before relevant information reaches the monitoring application.
- 04 · INTELLIGENCEPrepare a suggested response
The system uses the checked information to propose a response within its defined scope.
- 05 · DECISIONThe agronomist reviews
The agronomist checks the proposal and approves or adjusts it before it reaches the operator.
- 06 · ACTIONSend the approved proposal
The approved proposal reaches the operator with the instructions they need.
- 07 · OBSERVATIONKeep watching the conditions
New readings and operator reports help the team understand what happened next.
- 08 · IMPROVEMENTReview the next field cycle
The agronomist reviews the observations and agrees guidance for the next cycle.
Read the complete system model
- EVENT
Something happens in the operation.
- CONTEXT
Records, history and state are attached.
- PROCESSING
Rules, software and integrations do the deterministic work.
- INTELLIGENCE
One bounded AI component, where judgement can be modelled.
- DECISION
A named person decides where it matters.
- ACTION
Something changes in the world.
- OBSERVATION
Telemetry and monitoring record what happened.
- IMPROVEMENT
The loop feeds back into the next event.
REQUEST
Start with the operation.
Describe the operation in your own words. An engineer, not a sales team, reads it and replies within two working days with whether an assessment fits, and if so, a scope and fixed fee.
- 01You submit the form. We confirm receipt the same day.
- 02A 45-minute qualification call. Free. We ask about the operation, not your budget.
- 03If an assessment fits, you receive a written scope, duration and fixed fee.
- 04If it does not fit, we say so and, where we can, point you somewhere useful.
Prefer email? contact@stacx24.com. Same engineer, same reply time.
REQUEST RECEIVED
We've received the context.
We'll review the operation and reply within two working days with whether an assessment fits.