Skip to main content

The member profile

Once you pick a person, the top of the page is their profile card: who this member is, in the project's own terms. It is the context you read the rails against, so it shows exactly what the project knows and nothing it does not.

What the card shows​

The card leads with the member's id and name, then lays out whatever attributes the project's member source declares:

  • Booleans render as chips — a flag the member either has or does not, shown as a small labeled tag.
  • Everything else renders as a label and its value — a plain pair, the attribute name beside what it holds for this person.

The card does not decide which attributes matter or reorder them by importance. It reads the columns the source exposes and shows them, so the profile is a faithful picture of the record, not an edited one.

Thin and rich members, one card​

Projects declare very different member records, and the same card renders all of them:

  • A thin profile — a wellness member with little more than an id, a display name, and a couple of flags — shows a short, sparse card.
  • A rich profile — a video member with many declared columns — shows a fuller one.

There is no separate "rich member" layout. The card grows and shrinks with the record because it is generated from the declared columns, the same way the rest of Member Preview is generated per project.

Absent columns are never invented​

If the source does not declare an attribute, the card does not show it, and it never fills the gap with a placeholder or a guessed value. A blank you might expect to see is the honest signal that the project does not carry that field for this member. This is the honesty contract at the level of a single record: you are reading real declared data or you are reading nothing.