Design company soul

Design Company SOUL

Turn company context and real business conflicts into a compact, testable operating philosophy. Produce principles that help people choose, not slogans that merely sound good.

When foundational mission, vision, and values already exist, focus co-creation on using real cases to validate commercial and decision principles. Turn the principles that survive those tests into one decision system that both people and agents can understand and execute.

Operating contract

Deliver these outcomes:

1. A concise SOUL that explains why the company exists, where it is going, what it believes, who belongs, and how it chooses under pressure.
2. Evidence tags that separate confirmed facts, founder judgments, working assumptions, and missing data.
3. Conflict-tested principles with positive examples, counterexamples, and stop conditions.
4. A 30/60/90-day implementation plan connected to business pain points and growth.
5. One decision kernel whose meaning is easy for people to remember and precise enough for agents to execute in high-impact judgments and conflicts.

Keep confidential source material private. Generalize or redact internal cases before creating public artifacts.

Resource routing

Read only what the task needs:

• Use references/intake.md when the input is incomplete or scattered across interviews, decks, and culture documents.
• Use references/output-template.md when drafting the complete SOUL document.
• Use references/conflict-tests.md when testing principles against real decisions or cases.
• Use references/implementation.md when the user asks how culture should change business mechanisms.
• Use references/publication-safety.md before publishing, sharing externally, or creating an open-source example.
• Use references/fictional-example.md only when a neutral worked example helps.
• Run python scripts/validate_soul.py <draft.md> before calling a draft complete.

Workflow

Step 1: Frame the assignment

Capture four boundaries:

• Purpose: create from scratch, diagnose, iterate, or prepare v1.0.
• Decision scope: company-wide, business unit, product line, or leadership team.
• Time horizon: enduring beliefs versus stage-specific strategy.
• Audience and confidentiality: internal discussion, board review, recruiting, or public release.

Label source statements as:

• FACT — supported by a source or observed behavior.
• JUDGMENT — a founder or leadership choice.
• ASSUMPTION — plausible but unverified.
• GAP — information still required.

🔴 CHECKPOINT — scope: If the decision scope, owner, or confidentiality boundary is unclear, ask one concise question before synthesizing sensitive material.

Step 2: Build the evidence base

Collect only decision-relevant inputs:

1. Company stage, survival constraints, strategy, business model, and growth engine.
2. Core users, differentiated value, trust obligations, and non-negotiable risks.
3. Existing mission, values, founder stories, talent principles, and repeated behaviors.
4. Three to five real conflicts where leaders made or avoided a hard choice.
5. Talent decisions: who thrives, who fails, and which evidence supports that view.
6. Product and commercial choices that reveal actual priorities.

Do not wait for perfect information. Build an evidence ledger and keep unknowns visible.

Sparse-input delivery mode

When the user asks for a draft but provides only adjectives, aspirations, or generic culture words, do not choose between “invent a finished culture” and “return only an interview plan.” Deliver two layers:

1. PROVISIONAL STRAWMAN — NOT COMPANY CONSENSUS
   • Draft one mission, one vision, and three to four values as discussion targets.
   • Attach ASSUMPTION or GAP directly to every unsupported claim.
   • Use placeholders such as [core user], [distinct value], and [time horizon] instead of fabricated facts.
   • Include one observable behavior and one counter-behavior for each value.
2. Evidence and decision path
   • Ask no more than three questions that would most change the strawman.
   • Name the real decisions and conflict cases required before v1.0.
   • State exactly what must be validated, replaced, or deleted.

The user must leave with something concrete to criticize without being misled that leadership has approved it.

Step 3: Diagnose the real culture

Compare three layers:

Layer	Question	Evidence
Espoused	What does the company say?	decks, speeches, value statements
Enacted	What does the company repeatedly do?	hiring, promotion, product, budget, incident decisions
Required	What must become true to win next?	strategy, user needs, technology and market shifts

Name the gaps directly. Preserve existing language only when it still guides the required culture.

Step 4: Draft the five pillars

Draft in this order:

1. Mission and vision — why the company exists and the future it intends to create.
2. Worldview — the external truths and human assumptions behind strategy.
3. Talent philosophy — the people, evidence, growth expectations, and exit conditions required now.
4. Values — the few observable ways of working that the company will reward.
5. Decision principles — the priority rules used when valid values conflict.

Separate enduring principles from stage judgments. A survival-stage constraint may shape current choices without becoming a permanent belief.

Step 5: Derive operating principles

Add product, business, organization, and AI/human principles only when they are necessary to execute the five pillars.

Use this format for every principle:

### Principle: <short, memorable choice>
- Tension resolved: <A versus B>
- Why it matters: <business and user consequence>
- Do: <2-4 observable behaviors>
- Do not: <2-4 counter-behaviors>
- Evidence: <case, data, or GAP>
- Escalate/stop when: <red line or trigger>
- Owner and verification: <who checks what result>

Prefer five to seven decision principles. Merge principles that produce the same choice.

Compile one kernel for people and agents

Keep one semantic source of truth. Render it in two views without changing its meaning:

• Human view: a short memorable choice, the conflict it resolves, observable behavior, counter-behavior, and one real case.
• Agent view: explicit priority, applies_when, default_choice, required_evidence, exceptions, decision_authority, escalate_or_stop_when, and verification fields.

Order principles so conflicts do not become a second slogan contest: non-negotiable red lines first, then user or stakeholder value, evidence sufficiency, company-wide/business value, decision rights, and action mode. Change this order only through an explicit leadership decision.

For every high-impact agent recommendation, require a decision record containing:

1. facts, assumptions, and gaps;
2. options and competing interests;
3. principles invoked in priority order;
4. recommended choice and rejected alternatives;
5. decision authority and result accountability;
6. exception, escalation, or stop trigger;
7. result verification.

Do not maintain separate human and agent principles that can drift apart. Do not dump the full culture document into every agent; supply the shared red lines plus the principles relevant to that agent's decision scope.

Step 6: Run conflict tests

Test each important principle on at least three cases:

1. A past case with known consequences.
2. A current unresolved conflict.
3. A plausible future pressure test.

For each case, record:

• competing interests;
• known facts and missing evidence;
• the choice the principle recommends;
• who has decision authority and result accountability;
• what would falsify the principle or require an exception.

A principle fails if reasonable leaders can use it to justify opposite decisions without exposing their assumptions.

Run the same case facts through both a human decision session and the agent view. Rewrite the kernel if people and agents reach opposite choices without identifying a real evidence difference, an explicit exception, or a leadership judgment.

🔴 CHECKPOINT — leadership choice: Present unresolved value tradeoffs as explicit options. Do not silently decide founder-level beliefs, red lines, or people consequences.

Step 7: Design implementation with the business

Translate principles into mechanisms, not campaigns:

Business surface	Required translation
Hiring and exits	evidence rubric, interview probes, disqualifiers
Goals and evaluation	rewarded results and behaviors, anti-gaming checks
Product and investment	entry gates, user evidence, stop rules
Leadership and governance	decision rights, dissent, escalation, closure
Learning and AI	required new behaviors, proof of leverage, human accountability
Decision agents	shared kernel, required decision record, escalation rules, case-based evals
Stories and rituals	real cases, after-action reviews, recurring decisions

Connect every rollout action to one business pain point and one measurable outcome. Read references/implementation.md for the full 30/60/90 template.

Step 8: Version and close

Use version stages:

• v0.1 — complete structure with visible assumptions and questions.
• v0.x — revised through leadership choices and real conflict tests.
• v1.0 — approved principles plus owners, mechanisms, first pilots, and review cadence.

Run the validator. Return:

1. the SOUL draft;
2. the evidence-gap list;
3. the decision log;
4. the conflict-test results;
5. the 30/60/90 plan;
6. the next checkpoint and owner.

Failure recovery

Trigger	First response	If still blocked
Inputs are mostly slogans	Use the sparse-input two-layer mode: provisional strawman plus evidence path	If the user refuses to supply evidence, keep the strawman explicitly provisional and stop before v1.0
Leaders disagree on mission or red lines	Separate facts from judgments and present the competing choices	Stop at a decision memo with named owner and deadline
Existing values are popular but not observable	Preserve the label, rewrite behaviors and counter-behaviors	Mark the value as unverified and test it in two real cases
A principle is too broad	Add the tension, stop condition, owner, and falsifier	Delete or merge it if it still cannot select an action
Culture plan becomes training-only	Map each principle to a business mechanism and metric	Remove activities with no decision, behavior, or business consequence
People understand a principle but agents apply it inconsistently	Compare the human and agent views field by field, then replay the same case	Stop deployment until priority, evidence, exception, authority, and escalation rules select one defensible action
Sensitive cases are needed for learning	Redact people, amounts, clients, and identifying details	Keep the artifact internal; publish only a fictionalized pattern
Validator fails	Fix missing sections and unsupported claims	Return v0.x incomplete with the exact gaps; never claim completion

Anti-pattern blacklist

Do not:

• copy another company's values or use fashionable words without company evidence;
• confuse current strategy, KPI, or a tool mandate with an enduring value;
• equate “culture fit” with obedience, personality similarity, or leader preference;
• write principles that contain no real tradeoff, red line, owner, or observable behavior;
• create separate human and agent versions whose priority or exceptions differ;
• treat loading a long culture document into an agent as proof that the agent can apply it;
• hide bad news, internal contradictions, or evidence gaps to make the document look finished;
• turn implementation into posters, training, exams, or slogans disconnected from business mechanisms;
• use culture language to justify arbitrary layoffs, discrimination, surveillance, or retaliation;
• expose internal cases, personal information, or confidential metrics in public examples;
• claim consensus when leaders have not made the required choices.

Quality gate

Before final delivery, confirm:

• five pillars are present and mutually consistent;
• enduring beliefs and stage-specific judgments are separated;
• every major principle resolves a real tension and includes counter-behaviors;
• the same decision kernel has a memorable human view and an executable agent view without semantic drift;
• human and agent case tests expose the same facts, principle order, exceptions, authority, and stop rules;
• at least three real or safely fictionalized cases have tested the principles;
• FACT, JUDGMENT, ASSUMPTION, and GAP are not blended;
• implementation changes at least three business mechanisms;
• owners, metrics, stop rules, and review cadence are explicit;
• public artifacts pass the publication safety checklist;
• scripts/validate_soul.py passes or the remaining failures are disclosed.