A single source of truth for personal brand
PersonSpec is an open standard for defining a person's professional voice and presence as structured, machine-readable JSON. Identity, why, pillars, voice, vocabulary, structure, and guardrails — all in one canonical file, aligned to the organisations a person represents.
PersonSpec is the personal counterpart to BrandSpec. Where BrandSpec defines an organisation in isolation, PersonSpec is relational by design — explicitly aligning a person's voice and pillars to one or more parent brands.
The problem it solves
Personal-brand tools treat the individual as if they exist in a vacuum. In reality, professionals represent themselves and the organisations they work with — founders, executives, NEDs, advisors, freelancers — often several at once.
PersonSpec puts that alignment in one place, in a format machines can read directly.
What it replaces
- One-off ghostwriter style guides
- Verbal briefings about voice and tone
- Inconsistent personal posts across platforms
- Implicit assumptions about how a leader represents their company
- Drift between personal and organisational positioning
How it works
ProcessA PersonSpec file is a single .json document. Define it once; consume it everywhere a leader's voice needs to land consistently.
-
Define the person
Create a
personspec.jsonfile using the open schema. Capture identity, why, pillars, voice, vocabulary, structure, and guardrails. Reference one or more parent BrandSpecs to articulate how the person aligns to the organisations they represent. -
Calibrate against a parent
Each parent reference carries an
alignmentobject — voice deltas, topic scope, and acknowledged tensions. PersonSpec makes the personal-to-organisational relationship explicit rather than assumed. -
Push to your tools
Feed the file into a content tool, ghostwriter brief, or AI assistant. The model receives a structured, unambiguous voice brief — and produces output that is calibrated, not generic.
-
Keep it live
When a position evolves, a pillar shifts, or a new parent relationship begins, update the
personspec.json. Every connected tool stays in sync. Voice drift becomes a configuration problem, not a communications problem.
For AI tools: PersonSpec gives language models a structured, unambiguous voice brief. Instead of being prompted with vague style descriptions, an AI receives a machine-readable object it can query directly — tone, vocabulary, signature phrases, positions taken, confidentiality boundaries — and apply with precision.
Schema structure
v0.1.0A PersonSpec document is a JSON object with a root person key and seven top-level sections. All sections are optional at the object level but recommended for complete personal-brand definition. Identity is the only required field.
person.identity
Name, role, headline, pronouns, public links — and the parents array referencing one or more BrandSpec files with per-parent alignment objects.
person.why
The discovery layer. Work satisfaction, the people served, the impact striven for, the wider-world contribution, archetype, Inner Development Goals scores, and the synthesised Why statement.
person.pillars
Content pillars the person speaks to. Each is mapped to a parent-brand pillar with a relationship descriptor — reinforces, extends, tension, or personal-only.
person.voice
Tone descriptors, sentence style, formality on a 1–5 scale, humour register, and narrative perspective. Tells any content tool how this person communicates.
person.vocabulary
Signature phrases the person uses consistently, words and phrases to avoid, and the domain-specific language their audience expects to see.
person.structure
Default hook style, default content length, and signoff conventions — the structural defaults that shape any new piece of content.
person.guardrails
Topics to avoid entirely, positions publicly committed to (used to keep future content consistent), and confidentiality boundaries that must not be crossed.
person.metadata
Administrative fields: person name, version string, last updated timestamp, tags, and a provenance block describing how the document was produced and on what basis.
Voice fields
| Field | Type | Description | Example |
|---|---|---|---|
| tone | string[] | Tone descriptors for the voice | ["curious", "warm", "direct"] |
| sentenceStyle | string | Default sentence-length character: short, long, or mixed | "mixed" |
| formality | integer | 1 = very casual, 5 = very formal | 3 |
| humour | string | Humour register: none, dry, self-deprecating, playful, sharp, warm | "self-deprecating" |
| perspective | string | Default narrative perspective | "first-person" |
Alignment fields
The alignment object is what makes PersonSpec relational. Each parent reference carries one of these objects, articulating the relationship between the person and that organisation.
| Field | Type | Description | Example |
|---|---|---|---|
| brandspec | string (URI) | URL of the parent BrandSpec JSON document | "https://example.com/brandspec.json" |
| role | string | The person's role within this parent organisation | "Founder & Director" |
| scope | string | Relative weight: primary, secondary, advisory, historical | "primary" |
| alignment.voiceDelta | string | How the person's voice differs from the parent brand voice | "warmer, more first-person" |
| alignment.topicScope | string | Which topics the person addresses on behalf of this parent | "governance and strategy only" |
| alignment.tensions | string[] | Acknowledged points of healthy tension between personal and parent positions | ["pro open-source; parent is closed-source"] |
Provenance fields
PersonSpec describes a person — and the same shape can be authored by the subject themselves or inferred about them by a third party. Provenance makes that distinction explicit, so consumers can treat the two cases differently. The provenance block lives on metadata.provenance.
| Field | Type | Description | Example |
|---|---|---|---|
| type | enum | How the document came to exist — self-reported, inferred, observed, or hybrid | "self-reported" |
| consent | enum | Who consented — subject, guardian, public-figure-doctrine, or none-claimed | "subject" |
| confidence | enum | Producer's honest assessment — high, medium, or low | "high" |
| inferredFrom | string[] | URLs of source material (recommended for inferred documents) | ["https://linkedin.com/in/jane-doe"] |
Why provenance is required for non-subject-authored documents: a self-reported PersonSpec authored by the subject is a different artefact from one inferred from public posts. Right now the schema collapses both into the same shape. Provenance makes the distinction visible, so consumers can apply appropriate weight, and so producers building inferential tools can declare what they're doing rather than obscuring it. Read the full guidance at personspec.org/privacy.
Example file
JSONA condensed but complete PersonSpec document showing the multi-parent case. All fields shown are part of the v0.1.0 schema.
{
"_export": {
"personName": "Jane Doe",
"personSpecVersion": "0.1.0",
"exportedAt": "2026-05-02T10:00:00.000Z"
},
"person": {
/* ── Identity ────────────────────────────── */
"identity": {
"name": "Jane Doe",
"role": "Founder & Director",
"headline": "Building purposeful brands at human scale.",
"parents": [
{
"brandspec": "https://example.com/brandspec.json",
"role": "Founder & Director",
"scope": "primary",
"alignment": {
"voiceDelta": "warmer, more first-person",
"topicScope": "all"
}
}
]
},
/* ── Why ─────────────────────────────────── */
"why": {
"archetype": "creator",
"innerDevelopment": {
"being": 4,
"thinking": 5,
"relating": 3,
"collaborating": 3,
"acting": 4
},
"statement": "I help small organisations make their brand work harder."
},
/* ── Pillars ─────────────────────────────── */
"pillars": [
{
"name": "Purposeful branding",
"parentPillar": "purpose",
"relationship": "reinforces"
},
{
"name": "Open standards",
"parentPillar": "practice",
"relationship": "extends"
}
],
/* ── Voice ───────────────────────────────── */
"voice": {
"tone": ["curious", "warm", "direct"],
"sentenceStyle": "mixed",
"formality": 3,
"humour": "self-deprecating",
"perspective": "first-person"
},
/* ── Vocabulary ──────────────────────────── */
"vocabulary": {
"signaturePhrases": ["make it matter"],
"avoid": ["unlock", "leverage", "synergy"],
"industryLanguage": ["design tokens", "open standard"]
},
/* ── Structure ───────────────────────────── */
"structure": {
"hookStyle": "story",
"defaultLength": "short",
"signoffStyle": "none"
},
/* ── Guardrails ──────────────────────────── */
"guardrails": {
"topicsAvoid": ["party politics", "religion"],
"positionsTaken": [
"Open standards beat proprietary formats for SMEs."
],
"confidentiality": "Never name unannounced clients or unreleased work."
},
/* ── Metadata ────────────────────────────── */
"metadata": {
"name": "Jane Doe",
"version": "1.0.0",
"lastUpdated": "2026-05-02T00:00:00.000Z",
"provenance": {
"type": "self-reported",
"consent": "subject",
"confidence": "high"
}
}
},
"$schema": "https://personspec.org/schema/v0.1/personspec.json",
"version": "0.1.0"
}
Using PersonSpec
OutputPersonSpec is designed to be consumed by any tool that needs a structured definition of a person's voice and presence. Below are reference patterns for the most common outputs.
AI system prompt injection
Pass the entire person object as structured context in an AI system prompt. The model receives a complete operating brief — voice, vocabulary, structure, guardrails — and produces output calibrated to a specific person, not a generic tone.
// Build a calibrated AI brief from PersonSpec
const spec = await fetch('/personspec.json').then(r => r.json());
const { identity, voice, vocabulary, guardrails } = spec.person;
const brief = `
Write as: ${identity.name} — ${identity.headline}
Tone: ${voice.tone.join(', ')}
Formality: ${voice.formality}/5
Perspective: ${voice.perspective}
Use these phrases: ${vocabulary.signaturePhrases.join(', ')}
Never use: ${vocabulary.avoid.join(', ')}
Avoid topics: ${guardrails.topicsAvoid.join(', ')}
`;
Multi-parent voice calibration
When a person represents multiple organisations, PersonSpec lets the consuming tool select the appropriate alignment per audience or platform.
// Calibrate the voice based on which parent is being represented
function getVoiceFor(spec, parentUrl) {
const parent = spec.person.identity.parents
.find(p => p.brandspec === parentUrl);
return {
baseVoice: spec.person.voice,
voiceDelta: parent?.alignment?.voiceDelta,
topicScope: parent?.alignment?.topicScope,
tensions: parent?.alignment?.tensions ?? []
};
}
// Use the calibrated voice when posting on behalf of that parent
const calibrated = getVoiceFor(spec, 'https://anotherco.example/brandspec.json');
Cross-platform consistency
Same PersonSpec, multiple destinations. LinkedIn drafts, newsletter editions, conference bios, podcast intros, ghostwritten articles — all produced from the same canonical voice definition, all aligned to the parent brand without manual rework.
// Generate a LinkedIn-ready post
const hook = spec.person.structure.hookStyle; // "story"
const length = spec.person.structure.defaultLength; // "short"
const pillars = spec.person.pillars
.filter(p => p.relationship !== 'tension')
.map(p => p.name);
// Pass to your post generator with a chosen pillar as topic
Reference implementation: whyso.me is a LinkedIn-focused voice calibration tool built on PersonSpec. It learns from a leader's own writing, calibrates the voice against a parent BrandSpec, and produces drafts aligned to both.
Standards & references
OpenPersonSpec is designed to be standards-aware. It builds on, references, and is interoperable with several established frameworks. It is not a replacement for any of them — it is a structured layer that makes them composable in a single, machine-readable file.
BrandSpec
The sibling open standard for organisational brand definitions. PersonSpec references BrandSpec via the identity.parents array, making personal-to-organisational alignment a first-class concept. The two specs share conventions (JSON, CC0, versioned schemas, the $schema reference pattern) but are independently versioned.
JSON Schema
The PersonSpec document format is defined using JSON Schema (Draft 2020-12). The $schema field in every PersonSpec file points to the published schema, enabling validation in any compatible tool. Editors such as VS Code will auto-complete and validate a PersonSpec file when the schema URI is present.
Inner Development Goals
The IDG framework defines five dimensions of inner capacity — Being, Thinking, Relating, Collaborating, Acting — that underpin the ability to drive outer change. PersonSpec includes IDG self-assessment scores in why.innerDevelopment, providing a recognised, auditable framework rather than freeform self-description.
Brand archetypes
The twelve-archetype model (Jung-derived, popularised by Mark & Pearson) provides a shared vocabulary for emotional register. PersonSpec uses archetype as a single field in why.archetype to anchor the voice's emotional tone, mirroring the same field in BrandSpec.
The Golden Circle
Simon Sinek's Why / How / What framework provides the structural backbone of the discovery layer. The PersonSpec why object surfaces the synthesised Why statement as a first-class field, alongside the upstream questions (work, people, impact, wider world) that produce it.
Schema.org Person
PersonSpec pages and exports can be annotated with Schema.org Person structured data. The identity layer aligns to enable straightforward export of Person JSON-LD for search engines and AI crawlers.
UK GDPR & Article 22
For inferential PersonSpec producers operating in the UK or EU, UK GDPR Article 22 defines profiling as a regulated activity with transparency requirements. The provenance block is designed to make compliant disclosure easy and non-compliant production visible.
Responsible use
PersonSpec describes shape, not authorisation. Producers and consumers are responsible for using the format ethically. The privacy and usage guidance page sets out the spec's expectations: declare provenance honestly, do not treat inferred data as authoritative, respect subject consent.
Relationship to BrandSpec: PersonSpec is a peer to BrandSpec, not a subset of it. A PersonSpec without parent references is valid; a PersonSpec with multiple parents is also valid. The alignment object is where the interesting structure lives — it makes explicit what almost every NED, advisor, and founder-CEO actually has but rarely writes down.