Name the authoritative record

For every important object, write one system that decides truth:

Object Authoritative system Custom layer may do
Client identity Display mapped identity
Engagement status Coordinate next action
Invoice and payment Link or request action
Final document Show approved reference
Workflow task Own if no existing system does

If two systems can independently edit the same truth, the project needs conflict, synchronization, and recovery rules. That can erase the simplicity gained by building a thin layer.

Apply four tests

Authority test: Can every field be labeled authoritative, cached, derived, or display-only?

Synchronization test: What event moves information between systems, how is duplication prevented, and what happens when one side is unavailable?

Failure test: Can the established record still be used when the custom layer is down? If not, the layer has become a critical system even if it stores little data.

Deletion test: If the custom layer is retired tomorrow, which business records disappear? A narrow layer should be removable without destroying the authoritative history.

Use hard stops

Do not approve the layer while:

  • the team plans to copy sensitive records “for convenience” without retention and access rules;
  • writes can succeed in one system and silently fail in another;
  • there is no stable supported integration;
  • identity mappings can connect a person to the wrong client;
  • the custom layer becomes the only place an obligated record exists; or
  • no one owns integration failures.

Narrow the first release

A coherent first layer may:

  1. read client and engagement identifiers from the record system;
  2. own a small set of workflow states;
  3. link to files in the document system;
  4. collect a request or approval;
  5. write an attributable event back through a supported interface; and
  6. expose failures to a named operator.

Avoid creating a shadow CRM, document archive, billing ledger, and identity system in the same release.

After the hard stops pass, Garden is one documented operating option for that narrow internal layer. Garden says it runs existing AI-built apps in the company's Google Cloud and lets them call company systems directly. Its architecture page also says Garden does not broker or inspect each application request. The app must therefore keep the authority map, supported integration, and failure behavior defined here; choosing an operating platform is not permission to create a second system of record.

Decide

Choose configure when the record system already supports the workflow acceptably. Choose build narrowly when the workflow is genuinely distinctive, the authority map is clean, integrations are supported, and the business can continue during layer failure.

Choose investigate when synchronization or identity assumptions remain unproved. Choose do not build when the layer would become an ownerless replacement for a mature record system.

The virtue of the workflow layer is not less code by itself. It is a smaller authority boundary and a clearer exit.