Refresh is a design decision, not a feature
Every source publishes on its own terms. Some expose an interface that can be queried on demand, some produce a file overnight, and some require a person to export a report. A living architecture records what each source can actually do and designs the workflow around that reality.
This is why a blanket promise of hourly updates is not credible. What is credible is showing the age of every figure in the interface and defining, per source, what an acceptable age is.
Reconciliation should surface disagreement
When two sources disagree, the wrong response is to pick one. A living architecture holds both values, records where each came from and routes the difference to someone who can resolve it.
Over time the pattern of breaks is itself information. If one source is consistently late or consistently wrong in the same field, that is an integration problem worth fixing rather than a reconciliation task worth automating.
Permissions travel with the data
Access rules cannot be applied only at the screen. If a retrieval step can read a document, then an answer generated from that document can leak its contents to someone who should not see it. Permissions have to be enforced at retrieval, not at presentation.
That constraint shapes the data model. Entities, books of business and case ownership are not just reporting dimensions; they are the boundaries the system enforces.
Source dates belong on the screen
A number without a date is an assertion. A number with a source and a date is evidence. Displaying both, including an explicit stale state when a source has not updated, is one of the cheapest ways to make a system trustworthy.
Feedback and change control
Reviewer corrections are valuable, but they should not silently alter the system. A correction becomes a proposed change: recorded, evaluated against the acceptance measures, approved by a named owner and released as a version that can be reversed.
This is the distinction that matters most. Data freshness means the system is looking at current information. Model retraining means the system's behaviour changes. The first should be routine and continuous. The second is a controlled release with its own testing and approval, and it should never happen as a side effect of daily use.
Retirement is part of the lifecycle
Workflows outlive their usefulness. A source is replaced, a regulation changes, a team reorganizes. A living architecture includes a way to retire a component: withdraw it from the workflow, retain its records according to the agreed retention rules and remove the access that no longer has a purpose.
A system that can only grow is not living. It is accumulating.