Everything so far has assumed a client engagement is the unit of work. Totem Persona flips that. The unit of work is a person carrying their own intent, goals, preferences, and risk tolerance across engagements. The intake, the composite, and the SBPI pass all attach to a Persona that outlives any one engagement.
A Person can hold many Personas. A high-value finance Persona has stricter security than a community-facing Persona. Each Persona is a portable identity object with a control-center for the person's live goals and a public-ledger view onto their commitments. Agents plug into the Persona the way they plug into the client bundle: the same OKF concept vocabulary, the same REA and BMC typings, the same rehydration endpoint. The Persona is where the composite becomes a system a person can use, not a report a team ships.
The base schema for Personas already ships with a locked 13-class backbone (Person, Persona, Community, Market, Context, Goal, Intent, Preference, RiskTolerance, Resource, Organization, Relationship, Artifact). A canonical registry keeps a person's shared entities (their Person node, their orgs, their central concepts) stable across every Persona they hold. That is what turns "many Personas" into "one portable identity." Without the registry, two intakes of the same person's material produce two graphs that will not join. With it, every Persona bridges to every other Persona by construction.
How to apply it. Design new features from the Persona outward, not the engagement inward. Ask which Persona a feature serves. Ask what it reads from the control-center and what it writes to the public ledger. Every capability we build against the composite should compose with the Persona; if it does not, we have built a report, not a system. The series ends here; the work begins.