01 · The design question
Every file needs a clear next step.
I built EDOP to explore a practical design-operations question: how can a shared intake process check files, avoid repeated work and leave a useful record of what happened?
I treated this as an operational experience. A file may be ready to process, need a naming correction, arrive again, or reach an AI step that cannot complete. Each condition needs its own response.
Can someone looking at the record understand what completed, what needs attention and what to do next?
I owned the workflow logic, configured the Make scenario and checked its behaviour with controlled file submissions and error tests.
02 · Workflow architecture
Check first. Enrich second. Record the outcome.
Google Drive is the entry point. A file-version check runs before registration and validation. Eligible files are classified by rules, then passed to AI enrichment.
A simplified map of the implemented Make scenario. Select the visual to explore it at full size.
Built in Make
The complete EDOP scenario, showing the connected modules and routes in the implemented workflow.
03 · Key decisions
Reliability starts with the rules around AI.
Make eligibility deterministic.
Filename and MIME-type checks decide whether a file can continue. Rule-based classification is stored before the AI call, keeping file eligibility separate from generated enrichment.
Check for repeat events early.
The Data Store checks the file-version identity before downstream processing. Placing this check early keeps repeat events away from registration and enrichment.
Give rejections an actionable reason.
I refined a combined rejection message into separate naming and file-type reasons. The next action becomes clearer: correct the filename or submit a supported file.
Use alerts for exceptions.
The rejected-file route moves the file to quarantine, updates its record and routes a Slack alert. Successful files are recorded in the processing report; Slack is reserved for rejections.
04 · Status & recovery
One status cannot explain the whole file.
I separated validation, classification, AI status and processing status. This preserves the work already completed when enrichment needs attention.
| Record field | Question it answers | Example values |
|---|---|---|
| Validation | Did the file pass the intake rules? | VALID / INVALID |
| Classification | What did the rules identify? | UI_DESIGN |
| AI status | What happened to enrichment? | NOT_STARTED / COMPLETED / PENDING_RETRY |
| Processing status | What stage did the file reach? | REJECTED / CLASSIFIED / AI_ENRICHED |
Separating these fields makes eligibility, completed work and the next recovery action easier to distinguish. The recorded examples are grouped below under Tested paths.
05 · Tested paths
Follow a file through the workflow.
I checked the successful path alongside rejection, replay and enrichment exceptions. Select a scenario to see the recorded behaviour.
A valid file reaches enrichment.
Test inputA design file that meets the naming and file-type rules.
- Intake
- New file version
- Validation
- Classification
- AI + JSON
- Report
Observed result
The file was classified as UI_DESIGN by rules, enriched by AI and recorded in the processing report. Product and platform remained Unknown in this record.
- Validation
- VALID
- AI status
- COMPLETED
- Processing status
- AI_ENRICHED
Rejections explain what needs to change.
Test inputTwo inputs: a design file without the required version marker, and a file with an unsupported type.
- Intake
- Validation
- Quarantine
- Rejection alert route
- Report
Observed result
Both inputs were recorded as rejected without starting AI. The naming and file-type checks produced separate reasons. Rejected files follow the quarantine and rejection-alert route.
- Validation
- INVALID
- AI status
- NOT_STARTED
- Processing status
- REJECTED
Missing version marker
Recorded reason
“Invalid filename: version marker _v is required”
Unsupported file type
Recorded reason
“Unsupported file type”
The same file version is stopped early.
Test inputA previously processed file version submitted again.
- Intake
- Existing record found
- Filter blocks replay
Observed result
The Data Store found the existing record. The “Only New File Versions” filter stopped the replay before registration, and the report retained one entry.
- Existence check
- TRUE
- Registration on replay
- BLOCKED
- Report entries for file
- 1
Classification survives a model error.
Test inputA valid design file, with an invalid model name supplied to trigger a controlled error.
- Validation
- Classification
- AI error
- Store recovery state
- Report
Observed result
The controlled model error retained rule-based UI_DESIGN classification and logged the exception. The file stayed valid, with AI enrichment marked for manual recovery.
- Validation
- VALID
- AI status
- PENDING_RETRY
- Processing status
- CLASSIFIED
Recorded error
Model request returned a 404 error.
Recovery: Manual review and retry.
A parse error keeps its own recovery record.
Test inputA valid design file, with invalid text injected directly into the JSON parser.
- Validation
- Classification
- Parse error
- Store recovery state
- Report
Observed result
The parse-error route preserved the classification and recorded the exception for manual recovery. I restored the original mapping after the test.
- Validation
- VALID
- AI status
- PENDING_RETRY
- Processing status
- CLASSIFIED
Recorded error
“Source is not valid JSON.”
Recovery: Manual review and retry.
Results from the EDOP Processing Report and test matrix, organised by scenario.
06 · What I took forward
Operational clarity is a design outcome.
This build expanded my design practice beyond screens into the rules, states and handoffs that support a product experience.
Use explicit rules for eligibility and preserve AI-generated enrichment as a separate layer.
A specific rejection reason or recorded recovery state makes the next action easier to understand.
Replaying a file and injecting controlled errors exposed details that a successful run alone could not show.
Continue exploring
From workflow logic to product decisions.
See how I apply the same focus on clear states, accountable actions and recovery to multi-currency operations.