Entity screen specification

• ES-PAGE-01 The breadcrumb is Home, the area, the list, then the subject. The areas are in Menu structure.
• ES-PAGE-02 The photo stands large beside the title. The title is the person's name.
• ES-PAGE-03 Under the title, in small subdued type, is the subject's identifier. Nothing else. The version stands on each card, beside its title, because each card is a different record with its own version.
• ES-PAGE-04 A trade is the one exception. The line under its title also carries the trade's state, its internal version and its external version, because the two-version rule of Trade Versioning is what a person reads a trade for. The cards still carry their own versions.
• ES-PAGE-05 The header carries no Edit button. Edit belongs to the card it changes, because each card is its own record. This is the one rule of the Record screen standard's Header, Edit stands on the thing it changes, applied to an entity (decided 2026-10-25).

Tabs are held in the address (?tab=roles), so a link reopens the page on a tab. They run in this order, and a tab appears only when the reader may read it.

A tab that would answer with a refusal is not drawn. A refusal that arrives anyway is stated on the tab in words, with the reason, and the page does not show a banner for it: the read that can be refused is made quietly, and the tab speaks for it.

Each aspect that a person can change is one card.

• ES-PAGE-06 The card's title is on the left. The version of the record it shows is small and subdued beside it. The Edit button is on the right.
• ES-PAGE-07 The fields are read as text, not as inputs. A label stands above each value in sentence case, with no colon. A value with nothing in it is a muted dash.
• ES-PAGE-08 A field that is fixed once the record exists, such as the username, says why in a line of small text under it: "Set when the account was made, and never changed here."
• ES-PAGE-09 A field that another person owns says who. The sign-in address says "An administrator owns it."
• ES-PAGE-10 A card the reader may not change shows the access mark, Read only, as the UX Language sets it.

• ES-EDIT-01 Edit is one button with an icon and the word Edit, on the card it changes. It is drawn only for a person who may change that card.
• ES-EDIT-02 Edit opens a dialog with the current values. The dialog is titled Edit followed by the card's title, the entity's shape of the Record screen standard's Amend rule. It asks for the change reason and the commentary. The card itself asks for neither, and shows no reason field beside its values.
• ES-EDIT-03 Save is enabled once the form is complete, and a save with no field change is allowed: it writes a version that carries only its reason, which the history model keeps (decided 2026-10-25; the rule is the Record screen standard's Amend). The reasons offered follow the change: when a field changed, "No change in substance" is not offered, and when nothing changed only that reason is.
• ES-EDIT-04 The write claims the version that was read. A record that has changed since is refused with a conflict, and the dialog says so and offers to reload.
• ES-EDIT-05 Closing the dialog with changes asks "You have unsaved changes. Close anyway?"
• ES-EDIT-06 An optional field has a Clear control beside it, which writes the empty value. A Clear is not a Save of a blank by accident.

• ES-EDIT-07 A change that is not a form, such as the reporting line, has a small icon button on the line it changes. It is drawn only when the reader may use it.
• ES-EDIT-08 The photo is its own control. Clicking the photo opens the chooser to replace it. There is no separate "Replace photo" button.
• ES-EDIT-09 A control that proposes and does not write, such as a change that another person must approve, says Propose and not Save. See Proposals and four-eyes.

The control is not drawn. A disabled button asks a question that a missing one does not. The server still decides every write; the screen hides only what the server would refuse.

A combo box that filters a paged list obeys the same rule.

• ES-PAGING-08 It offers only the values that exist in the data, and the server says which. An area no role grants something in is not offered.
• ES-PAGING-09 A screen that shows one value at a time, such as one area of the permissions, has no "all" choice. One value is always chosen. When the reader has not chosen, the first value the server lists is chosen, and the server says which.
• ES-PAGING-10 A list that narrows rows, such as the roles list, may start with "All areas", because choosing none shows every row. The first choice there means no filter, and it is not a page of everything.
• ES-PAGING-11 A filter that matches nothing says so and offers to clear it.

A change a person makes on one page must survive a move to another. The screen keeps the changes as a set of differences from what the server holds, keyed by the thing changed, and lays them over each page. A change that puts a value back as the server holds it removes the difference. Save sends only the differences, and the server applies them to what it holds. The screen never needs the whole set to save.

• ES-HIST-01 The chart is a histogram of the entries: a bar for each hour, or for each day once the history spans more than two days. Each bar is split by the kind of entry, and each kind has one colour that the legend repeats.
• ES-HIST-02 Every bar has the same fixed width. A bar never stretches to fill the row, and a long history scrolls sideways.
• ES-HIST-03 An hour or a day with no entries is empty space. The chart draws every bucket from the first entry to the last, so a gap in time reads as a gap.
• ES-HIST-04 A bar shows its time and its count on hover, and each segment its kind and its count. The first and the last time stand under the bars. The legend names the kinds that appear, each with its count.
• ES-HIST-05 A click on a bar scrolls to the entry nearest that hour or day, and marks it for a moment. A click on an empty bar goes to the closest entry in time.
• ES-HIST-06 The chart reads the entries the list holds. It makes no read of its own.

• ES-HIST-07 Each entry is a header on one line: the kind, the record and its version, the reason code, the author, what they did, and the time. The time and the current-version emblem stand in the left gutter.
• ES-HIST-08 The note, such as "Attached staff photo during provisioning", is never on the header line. It stands on its own line below the header.
• ES-HIST-09 The detail is collapsed. A field that changed is drawn as the difference, the old and the new, and a first version as the whole record. A reader opens the detail on demand. The first screen of a long history is a list of headers a person can scan.
• ES-HIST-10 An entry that changed no field says "No changes". It has no detail to open.
• ES-HIST-11 The newest version of a record carries a small emblem next to its time, with the words "Current version" as its tooltip. There is no sentence for it, and no Revert button on it, because there is nothing to revert to.
• ES-HIST-12 An entry that cannot be reverted, such as a sign-in, simply offers no control. The rail does not explain what is missing: no "this entry records something that happened, so there is nothing to revert", and no "putting a field back is not offered here". A sentence that says what is not there adds nothing.

• ES-HIST-13 Every history draws one toggle, "Hide system activity". When it is on, the toggle reads "Show system activity". It is drawn even when no service account wrote an entry.
• ES-HIST-14 The toggle starts off. A history shows every entry until the reader hides some.
• ES-HIST-15 The toggle hides an entry only when its author is a service account. The tenant administrator and the super administrator are people, so their entries stay.
• ES-HIST-16 The toggle also hides the entries in the chart, the legend and the day dividers. The chart counts what the rail shows.
• ES-HIST-17 Only a reader who may read accounts can tell a service from a person. For any other reader the toggle is disabled, and its tooltip says why. The screen does not guess, because a wrong guess hides people.
• ES-HIST-18 The shared Timeline draws the toggle. A screen gives it isService, which usePeopleDirectory supplies.

A bulk import writes a record for each row, so the history of one party can hold forty links created in one second. The rail draws entries that are one act as one row that opens to its members.

• ES-HIST-19 Entries are one act when they were created, or closed, by the same author, for the same kind of record, with the same reason code and the same comment, and each follows the one before it by no more than 5 seconds. There must be at least 3.
• ES-HIST-20 A change is never part of a batch. It carries a difference that a reader wants to read.
• ES-HIST-21 The batch row says what was done once: the kind, the count, the kind of record, the reason, the author and the comment. Beneath it, "{n} entries" opens a list of the members, one line each, with the time and the name of the record.
• ES-HIST-22 The batch stands at the time of its newest entry. Entries of other acts keep their place around it. A batch has no Revert button.
• ES-HIST-23 The chart and the counts still read the entries. A batch is only how the rail draws them.
• ES-HIST-24 A party history leaves out its versions that changed none of the fields it carries, such as the versions a child record's import bumped. The first version stays.

A party works in countries and currencies, and may trade with counterparties. A person works in parties. Each of these is a link, and the timeline draws a link as a record of its own.

• ES-HIST-25 A link is named by what it points at: "Country GB", "Currency EUR", "Counterparty Globex Corporation". A counterparty or a party is said by its name, and its id stands only when the name cannot be read.
• ES-HIST-26 The opening of a link is a "Created" entry. A change to a link, where it has a column of its own, is a "Changed" entry with the difference.
• ES-HIST-27 The closing of a link is a "Closed" entry. It carries the time the link ended and the account that ended it, drawn as the author of any other entry is. A link closed before the store recorded the closer has no author, and the entry does not say that it has none.
• ES-HIST-28 A link that was closed and opened again is one record in two runs. The second run counts from one again.
• ES-HIST-29 The timeline names a gap for a kind of link only when that kind could not be read. A kind that read and holds no link states nothing.

• ES-HIST-30 The author's photo stands at the left of the entry, beside the header and the changes, at medium size (2 rem) so that a face can be seen. Where the author has no photo, their initials stand in the same circle. A service is its initials.
• ES-HIST-31 The author's name is a link to their page where the reader may open people. A service is text.
• ES-HIST-32 The photo and the link come from the same directory as every other mention of a person.

A person's history merges the versions of the account and the contact record, the roles given, and the sign-ins. They share the rail, and each entry names its kind and its record.

• ES-HIST-33 Each kind of entry has its own tone: a change, a grant, an act, a decision.
• ES-HIST-34 An act that is not a version, such as a sign-in, is drawn quietly and says that it cannot be reverted.
• ES-HIST-35 A version of a record that may be reverted offers Revert to the person who may write it. The newest version says "Current version" and offers nothing.
• ES-HIST-36 Entries are paired with the version before them to find what changed. The pairing is the screen's reading of the stream, not the server's claim.

Some parts of a story cannot be answered, and the stream says so. A grant that was taken away is closed and no read returns it. The sign-in log keeps a window. Each such part is a gap on the answer, stated on the screen in words. A gap is never rounded away, and it is never shown as an empty list.

• ES-HIST-37 A gap the screen knows is said in its own words, in every language, once.
• ES-HIST-38 A part that was removed is closed, and no read lists a closed row. A party's history says so for its identifiers, its contacts and its business units, in its own words, until a read by parent lists them.
• ES-HIST-39 Any other gap says that part of the history could not be read. It then names the record and gives the stream's own reason, so a reader can tell what is missing and why. The reason is in English and may name tables, reads and refusals. Such a gap is a fault to fix, not a state to keep.

A history is read for one row. The screen names the row by its own id when its kind of record has one, because the key a model declares for the row may be shared by other rows: every party holds a contact of each type. A link has no id of its own, so its history is read by the parent it belongs to, and each version names its link as parent/child in its ID field. The screen pairs versions by that field. The rule for the request is in Entity addressing.

A history narrowed to one field, such as the reporting line, keeps every version in the stream so each is read against the one before, and shows only the versions where the field moved.

ES-HIST-40 History is the versions of one record, and the tab is named History. A log of events that happened is Audit, and has a Refresh and no revert. The sign-in record is Audit. In a person's timeline it appears as acts.

A history that spans many subjects, such as who changed their reporting line, is two steps and not a merged rail.

1. A list of the subjects for whom the thing changed recently, newest change first, each with the old value and the new one.
2. The subject chosen from that list, drawn as its own narrowed timeline.

There is no card of the person beside it. The list is the way in.

• ES-TRADE-01 The identity card says why a field is fixed. The party and the counterparty never change, so a change to either is a cancel and rebook, which is a lifecycle event and not an Edit.
• ES-TRADE-02 Edit asks for the kind of change first, and the kind bounds the fields the dialog offers. This is the rule of Trade Versioning: the reason constrains the change. The dialog then says what the save will do, which version moves and whether a confirmation is issued.
• ES-TRADE-03 A trade that is the leg of a structure or a package says so, and says whose confirmation a change reaches.
• ES-TRADE-04 Recording a lifecycle event is a workflow, in the Workflows menu of the page. It has steps and writes several records, and a novation books a second trade.

Booking is the Add of the trade list. It opens a page and not a sequence, because a sequence is allowed only when it makes the task quicker, and a trader booking a deal knows the whole deal.

• ES-TRADE-05 The page has four tabs: Trade, Instrument, Identifiers and Review. Book is a button in the header and stays disabled until the review has nothing to refuse.
• ES-TRADE-06 The trade type is a combo box, grouped by product. A trade type with no instrument table is listed and cannot be chosen, and says so. The type is the one choice that decides what the Instrument tab holds.
• ES-TRADE-07 The Instrument tab has a tab of its own for each part of the instrument: its terms, then each child table. A part with rows is edited as a table with Add a row and Remove. A part that the economic digest does not read says so where the person edits it.
• ES-TRADE-08 A trade booked in a virtual book must be a draft, a test or a hypothetical. The Review tab refuses anything else and says why.

A structure is a tree: the deal the customer sees at the root, with strategies, packages and trades inside. A package is a structure of kind Package, so there is one screen and its words follow the kind. See Trade Structures and Deal Composition.

• ES-TRADE-09 The tree is its own panel beside the page, as in the structure editor. A row stands for the root, for each inner structure with its kind, and for each trade with its product, role and notional. A click on a structure opens its page, and a click on a trade selects it.
• ES-TRADE-10 The page says how the kind confirms and prices: a strategy, a typed structure and a dynamic structure are one deal, and a package confirms trade by trade.
• ES-TRADE-11 The list shows each root with its inner structures indented under it.
• ES-TRADE-12 Grouping trades is a workflow, because the kind to choose has consequences the person must read first.

The price of a structure is a tab of the structure page. There is no separate workbench that edits a structure in place.

• ES-TRADE-13 The members of a structure change through the Edit pattern, one change at a time. A dialog asks for the reason and the commentary. The change waits until the person presses Refresh, and the history of the structure records who made it and why. A change to the members does not move the version of a trade.
• ES-TRADE-14 A leg is booked on Book a trade, with the structure and the role in the address. The booking and the membership are two writes. The result offers the next open role of the template.
• ES-TRADE-15 A strategy states what its template asks of its legs, and the Members tab shows each check as it passes or fails.
• ES-TRADE-16 Market data is a snapshot, and the tab says when it was read. A newer snapshot turns Refresh gold, and nothing ticks by itself. A screen that must stream says so on its own query, as the notification bell does.
• ES-TRADE-17 A price is indicative. The tab says so, and it names the shifts that were applied.

• ES-REFRESH-01 The browser holds one stream of change news for the session. It opens when the first screen watches something and closes with the last, so a screen that watches nothing holds no connection.
• ES-REFRESH-02 A screen names the entities it shows, as the services name their events: the component and the events collection, such as iam and accounts. The refdata registry states these, so no screen guesses a plural.
• ES-REFRESH-03 The news is a time and not a list. A thousand changes in one import make a screen stale once.
• ES-REFRESH-04 The news may name the records that changed, when there are few (up to 20 in one message). A list uses them to place the change (see Refresh). A record page names its record in its watch ({ component, entity, record: { username } }) and goes stale only when the news names its record or names none. It does not pulse for another person's change. A page that cannot state its record's key leaves the record out and goes stale for any change to the entity.
• ES-REFRESH-05 A screen is stale when a change reached the browser after the load that produced its data began. The comparison uses the browser's clock at both ends, because the server's clock differs. A change that arrives while a load is in flight counts.

• ES-REFRESH-06 Every list, relationship view and record page has a Refresh button in the header's actions, the same control and the same place (RefreshButton).
• ES-REFRESH-07 When the screen is stale the button turns gold, pulses four times, and stays gold until the screen loads again. Its tooltip says the data changed and gives the time. A reader who asks for less motion gets the gold and no pulse.
• ES-REFRESH-08 The gold (--color-stale) means "changed on the server" and nothing else.

• ES-REFRESH-09 A list also says where the change fell, in three cases. The list keeps the records that the changes since its load named.

  1. A few records, all on the page: those rows pulse (row-news).
  2. Too many to name, or a list that cannot tell its rows apart: a strip along the top of the table says that something changed which the page cannot show.
  3. A record on another page: the same strip, because no row on this page can carry the mark. When a change names rows on the page and also a record off it, the rows pulse and the strip shows.

  A list tells its rows apart by recordKey, the key of the record a row shows, as the events name it. Refresh stays gold in all three cases.

• ES-REFRESH-10 A click reads again whatever the screen shows. On a record page that is every card and the history.
• ES-REFRESH-11 The page does not reload by itself. A list does not, a record page does not, and the history does not.
• ES-REFRESH-12 The query client holds this for every screen. It never reads again because the window gained focus or the network came back (refetchOnWindowFocus and refetchOnReconnect are off). A screen that must poll says so on its own query, as the notification bell and the dashboards do.
• ES-REFRESH-13 A tab of a record page that the person has opened stays drawn and is hidden while another is open. Leaving a tab never unmounts its reads, so coming back to it reads nothing. A tab the person has not opened reads nothing.
• ES-REFRESH-14 Refresh reads again only the queries the page shows: the record, its parts, its links and its history. It does not read every record of the app.
• ES-REFRESH-15 A save does not reload the page either. The save's own change event makes Refresh gold, like any other change, and the person presses Refresh to see the saved values. A page that was reloaded by the save would hide that the data moved, and would make the gold mean two things.

• ES-REFRESH-16 Under the Refresh button the screen says when it loaded, as an ISO 8601 timestamp in the reader's zone, such as 2026-10-11T02:13:10+01:00. It is small, monospaced and faint (half opacity), and it has no label. The tooltip says "Loaded" and repeats the timestamp. The text is the same in every language.
• ES-REFRESH-17 The timestamp is part of RefreshButton, which takes the screen's load state and the news about it, so a screen cannot show the button without it (LoadedAt).
• ES-REFRESH-18 The time is the browser's clock at the moment the data arrived. It is the clock the stale logic compares, so the two never disagree. It is not the server's as_of, which is a field a caller sends to read the data as it was at an instant. A read response carries no read time.
• ES-REFRESH-19 A screen made of several reads states the oldest of the reads on screen, because the screen is only as fresh as its oldest part. The stale logic uses the newest, which is a different question. Only the reads the screen is showing count: a page of a list that was read earlier stays in the cache and does not age the screen.
• ES-REFRESH-20 The time stays while a reload runs or fails, because the old data is still on screen. Before the first load nothing is drawn.

• ES-REFRESH-21 After a reload, a row that was not on the page before, or whose content is not what it was, gets a gold left edge and pulses three times. The mark goes after four seconds. The list keeps its scroll position.
• ES-REFRESH-22 The comparison is with the same page read before. It uses no clock, and moving to another page, searching or sorting marks nothing.
• ES-REFRESH-23 A history entry that arrives with a read is marked the same way.

• ES-REFRESH-24 A dialog is never reloaded under the person. While it is open it listens for a change to its entity and reads the record again behind the form.
• ES-REFRESH-25 When the record is newer than the one the edit started from, a warning above the form says who saved it and which fields moved, with the old and the new value. The person chooses Keep my edit or Take the new values.
• ES-REFRESH-26 A save claims the version the edit started from. A save made against an old version is refused with a clear message, and the edit stays in the form.
• ES-REFRESH-27 Keep my edit makes the newest version the base, so the save replaces it knowingly.
• ES-REFRESH-28 A dialog over a record says under its title when the record it started from was loaded (Dialog's loadedAt). The time moves when the person takes the newer version or keeps their edit on top of it, because the base has changed. A dialog over no record leaves it out.

• ES-REFRESH-29 The events of another tenant are not told to a session. An event names its tenant and, on a party-owned table, its party, in the envelope. A session hears its own tenant and the system tenant, and a member hears the parties they work in. The broker does not enforce this, so a client that listens to NATS directly still hears every tenant.
• ES-REFRESH-30 A role granted or taken away is published inside the service only, so a person page cannot hear it.
• ES-REFRESH-31 A reporting line has no event of its own. The staff list and the hierarchy hear it when the person changes too.
• ES-REFRESH-32 A change to a record that a screen shows by reference, such as a country name on a book, is not heard.
• ES-REFRESH-33 The classification lists, the staff list and the hierarchy mark no rows yet.
• ES-REFRESH-34 The account profile write has no version claim in its protocol. The BFF checks the claim just before it writes, which leaves a very small gap.
• ES-REFRESH-35 The notification bell still reads its count on a timer.