What an App reads from a Noun: depth

An API needs a Noun's types to check a call, and nothing more. An App reads more from the same file: the field that names a record, the field order, each reference, and the Verbs that move it.

One Noun, traced to its screensCopy Anchor Link

leaseclock.com tracks lease renewal dates for small property managers. Its Startup declares two Nouns, Property and Lease, and the Admin reads every fact below from those two files.

---
extends: [Thing]
properties:
  residentName: string
  residentEmail?: email
  listingUrl?: url
  startsOn: date
  endsOn: date
  monthlyRent: number
  status: active | renewed | terminated
  notes?: text
  terms?: json
  documents?: string[]
  property: Property
verbs:
  renew: {}
  terminate: {}
---
A Lease is one resident's agreement on one unit of a Property, from signing to renewal.

---
properties:
  name: string
  address?: string
  units: integer
---
A Property is one building a manager rents out, unit by unit.

Representation: the field that names a recordCopy Anchor Link

Every record shows somewhere as one short string: a page title, a cell that points at it, a choice in a picker. The Admin takes the first of name, title, label, email and slug that holds one line of text. Failing those, it takes the first one-line text field, then the id.

Property has name, so a lease's property cell reads 14 Elm Street. Lease has none of the five, so residentName names it: Maya Ortiz. Without one of those five names, the first one-line field wins, so the declared order picks the name.

Fields and relationshipsCopy Anchor Link

The API ignores the order of properties. The Admin keeps it: the list shows the first 7 short fields in declared order, properties before references. Lease declares 7 short properties before property, so the list leaves property out and the record page shows it.

A property typed with another Noun is a forward reference. The record page and the list show the referenced record by its name and link to it, and the forms offer a picker that searches. The forms never require a reference, even one declared without ?.

Lifecycle statesCopy Anchor Link

status: active | renewed | terminated lists the lifecycle in order. create starts every lease at active, and only a Verb moves it. The Admin shows status as text in the list and on the record page.

The create and edit forms offer status as a one-line text box. The hub's Noun-file rule says no create or update input takes it.

Verbs and EventsCopy Anchor Link

Each Verb beyond create, get, list, update and delete becomes a button labeled from its name: renew reads Renew. The button runs the Verb on its record, and the Verb's rules decide.

A completed call shows a notice and reloads the record (verb-result). A refused one shows the Verb's reason and leaves the screen as it was (refusal-message).

Each completed Verb also records an Event, such as Lease.renewed. No printed rule draws a screen part from an Event: the reload after a Verb shows what it changed. A Verb's declared inputs are the subject of Verb inputs: what a form needs.