ENGINEERING JOURNAL
One rule change reveals the platform architecture
A practical way to evaluate whether data, interfaces, APIs and AI follow the same business rule.
Architecture illustration
“Change the approval rule for purchase requests.” Include this small request when evaluating a platform. Seeing the change applied across a form, mobile view, API and AI tool reveals the work behind adaptability.
Follow a change all the way through
Suppose a purchasing process needs an additional reviewer for a product category. Adding a field is only part of the change. Decide which rule applies to existing requests, whether already approved requests can execute and whether API submissions follow the same conditions.
| Area | Evaluation question |
|---|---|
| Meaning | Are category and reviewer definitions and identities shared? |
| Rule ownership | Who validates the condition at submission and execution? |
| Interface | Does it display the states and actions the server permits? |
| API and Agent | Do they invoke the same business operation and authorization? |
| Change history | Can the team explain versions and treatment of existing work? |
Repeating a condition in every interface and prompt creates more places to miss an update. Give validation a clear owner, then let interfaces and tools use its result.
Share the foundation while preserving business meaning
Sales, billing and support may refer to the same customer organization while requiring different attributes and states. Connect identity and relationships while preserving each workflow's ownership. Putting every field into one enormous object can increase the impact of a change.
Microsoft's domain-analysis guidance describes a bounded context as the boundary within which a particular domain model applies. It is a useful reference for separating shared foundations from business-specific meaning. Use domain analysis to model microservices
Giz's living-model design direction connects data definitions, interface composition and executable actions. Evaluate its value through the places a rule must change and the results that can be demonstrated.
Declarations still need operating rules
A model update does not remove in-flight requests, old open screens or external-system failures. Define rule versions, concurrent changes and re-review conditions. Authentication, transactions and execution records still need explicit ownership.
What to request in a demonstration
Choose one rule the operating team understands. Compare the interface, API and Agent before and after the change using identical input. Verify that disallowed requests are rejected for the same reason. Inspect validation, deployment and recovery work alongside the amount of changed code to understand maintenance scope.
← Previous Insight
Read the exceptions before moving the spreadsheet
Next Insight →
Put operation and handover into the delivery scope
YOUR NEXT STEP
Bring us the workflow that needs to work.
Start with the files and systems you use today, and the work you want to change.