brief.md for multi-brand operators — one file per brand, shared operator rules
Multi-brand operators run separate brief.md files per brand under one operator identity. Operator-level voice rules and signing identity inherit; per-brand briefs override only what differs.
Operators running 2-10 brands need a sane way to manage brand context without N copies of the same operator-level rules.
One brief per brand
Each brand in a portfolio has its own brief.md. This is non-negotiable — a single multi-brand brief would confuse consumers about which brand they're looking at and would break voice-validation, scoping, and publishing. The brief is brand-scoped by design.
Operator-level inheritance
Each brand's frontmatter declares `parent_operator_id`. This points to the operator-level identity (e.g., `parent_operator_id: tom-pinder` for the StartVest LLC portfolio). Operator-level voice rules, banned phrases, and signing identity inherit unless explicitly overridden by the brand. The PRAPI canonical implementation resolves this inheritance at render time.
Per-brand identity, shared infrastructure
Each brand has its own `brand_id`, `name`, `website`, `description`, voice rules. Each brand has its own positioning, ICP, voice overrides. What's shared across brands in a portfolio: operator-level voice baseline, signing identity (one JWS key per operator typically), parent-org legal identity. Per-brand: everything else.
Multi-brand consumer experience
A consumer (AI agent, journalist tool, PR system) discovering the operator's brands typically follows: fetch operator manifest → enumerate brand identifiers → fetch each brand's brief.md. Each brief stands alone — the consumer can pitch one brand without needing to load the whole portfolio. The operator manifest at /.well-known/operator.json (companion spec, draft) lists brands and their canonical brief locations.
StartVest LLC operates 8 brands (PRAPI, FieldLedger, Hireposture, IdeaLift, ClarityLift, AdaCompliance, StartVest govcon, The Integrity Framework). Each has its own brief.md; all share `parent_operator_id: tom-pinder`. Each brand's brief is independently fetchable; the operator manifest at /.well-known/operator.json (planned) will enumerate them.
FAQ
Can I have one brief.md for my whole portfolio?
No, by design. Each brand has different voice, positioning, ICP, and outlet fit. Combining them in one file forces a consumer to disambiguate which brand the data refers to, which destroys the deterministic structure the spec is built on.
How does operator-level inheritance work?
Each brand's frontmatter declares `parent_operator_id`. When a consumer fetches a brand brief, the parser resolves operator-level rules and merges them. The brand brief's own rules override on conflict. PRAPI's canonical implementation does this resolution at parse time.
What about brands sharing assets (logo, headshots)?
Each brand declares its own assets. If the operator's headshot is the same across brands, each brand declares the same URL. This is intentional — sharing-by-reference at the asset level breaks portability. Asset URLs are themselves stable; sharing the URL is fine, sharing a "see operator" reference is not.
How many brands can an operator have?
No spec-imposed limit. The PRAPI tier system caps at 10 brands per portfolio for billing reasons; the spec itself supports any count. Operators with 50+ brands typically run their own publishing infrastructure rather than relying on PRAPI's default rendering.
Run brief.md in PRAPI.
PRAPI is the canonical brief.md implementation. Every brand in your portfolio gets its own brief.md, voice-validated drafts on every pitch, and Git-canonical authoring.
Sign in →