You open a permit to answer one question: which actions are still open? The header loads. You click Related Actions. Spinner. You click Correspondence. Another spinner. You still do not know which project owns the permit without a separate search.
Flat detail pages hide parent context. Lazy-loaded tabs make you earn the entity graph one HTTP round trip at a time. On capital programs, the cost is not the click. It is the lost thread while you wait.
Plathera record details calls GET /api/:tableName/record-details/:uuid once. The response is structured JSON with three parts:
| Part | What you get |
|---|---|
| main | The row you opened: permit, RFI, action, purchase order, or any table in the live program model |
| parents | Outgoing foreign keys resolved to parent rows, each with a link back to its own record-details URL |
| children | Related tables with row counts and enriched rows, including resolved lookup labels where FKs point outward |
One fetch. Full entity graph. No per-child endpoint waterfall.
The server invokes a Postgres RPC that walks foreign key relationships from catalog metadata. Parent rows are fetched in a single UNION. Child tables are enumerated from the schema graph, not from hand-maintained join lists in application code.
When your team adds a new FK in Postgres, the detail page discovers it. Builders extending Plathera do not maintain a separate join map for every table. The live program model stays the source of truth for both storage and navigation.
| Step | What happens |
|---|---|
| Navigation | User opens /record-details?table=&uuid= from search, a grid, breadcrumbs, or the EPC Assistant |
| Single fetch | One API call returns main, parents, and children |
| Render | Form fields, parent breadcrumbs, related list grids per child, in-page jump navigation with counts |
Related lists use a consistent grid pattern with counts and jump links for large entities. Not every child table gets a custom layout; the core story is the one-shot data contract, not bespoke UI per relationship.
The EPC Assistant cites the same record-details URL pattern when it references a permit, action, or purchase order. Ask:
Link me to the record details page for action item 1234.Or:
Open record details for this permit and summarize related actions and correspondence.The assistant, API consumers, and the browser UI share one entity contract. Integrations do not need a separate "lite" record endpoint missing parents or children.
What parent project is this purchase order linked to?Parent breadcrumbs answer without a separate project search. Related correspondence and actions are already in the first response.
EPC records do not live in isolation. The detail view should load the full graph in one round trip, not make you earn context tab by tab.
Worth a conversation if your record views still load the header fast and make you wait for every related list.
No. Record details returns the main row, parent FKs, and all related child tables in one API call. Per-child lazy endpoints were removed in favor of a single schema-driven fetch.
The record details RPC discovers foreign key relationships from catalog metadata. New FKs in the live program model appear in parent breadcrumbs and related lists without hand-maintained join code per table.
Yes. The assistant cites the same record-details URL pattern used by search, grids, and breadcrumbs, so you can open the full entity graph from a chat response.