Founding documents: charter, operating model, org structure, ways of working, decision framework

Co-Authored-By: Paperclip <noreply@paperclip.ing>

docs/company/charter.md

@@ -0,0 +1,29 @@
+# Company Charter
+
+## Mission
+
+Build institutions that outlast their founders. We exist to create technology and organizations that compound in value over time, not to chase trends or optimize for short-term outcomes. Every product we ship and every process we design must make the next version of the company stronger than the last.
+
+## Vision
+
+A world where the best teams operate with radical clarity: everyone knows why their work matters, decisions are made on evidence rather than authority, and the institution keeps improving even as people join and leave. We will be the company other companies study when they ask, "How did they build that?"
+
+## Operating Principles
+
+1. **Source of truth is the repo, not memory.**
+   If it is not written down, committed, and linkable, it does not exist. Decisions, plans, and context live in durable documents, not Slack threads or someone's head. This is how we scale without decay.
+
+2. **Optimize for reversibility.**
+   Move fast on two-way doors; slow down on one-way doors. Default to experiments with clear rollback paths. A decision without a cost of reversal is a bet, and bets require higher evidence bars.
+
+3. **Disagree and commit, but write it down.**
+   Dissent is healthy. Once a decision is made, everyone commits fully. The minority opinion is archived with its reasoning so we can revisit it if the decision proves wrong. No invisible reservations.
+
+4. **Hire for slope, not intercept.**
+   We prefer people who learn fast over people who know everything today. The problems we will face in two years do not exist yet; we need teams that can grow into them.
+
+5. **Protect focus ruthlessly.**
+   Saying no is a core competency. We maintain a short, ordered priority list and decline everything else. Multitasking is organizational debt.
+
+6. **Pull for bad news.**
+   If problems stop surfacing, we have lost our information edge. Every manager's job includes creating conditions where the worst news travels fastest.

docs/company/how-we-decide.md

@@ -0,0 +1,91 @@
+# How We Decide
+
+Every major decision at this company goes through the same process. A "major decision" is anything that:
+
+- Commits the company to a path that is hard or expensive to reverse
+- Affects more than one team or function
+- Costs more than $2,000 or $500/month recurring
+- Changes how we work (process, tools, org structure)
+- Introduces new security, legal, or compliance exposure
+
+If it is not major, the owner decides and documents. Do not slow down small decisions.
+
+## The Process
+
+### 1. Frame the decision
+
+Write a one-page decision brief that includes:
+
+- **Question:** What exactly are we deciding?
+- **Context:** Why now? What changed?
+- **Options:** At least two real alternatives, including "do nothing."
+- **Criteria:** 3-5 criteria we will use to judge the options.
+- **Recommendation:** The owner's preferred option and why.
+- **Risks:** What could go wrong? How would we know?
+- **Rollback plan:** If we choose wrong, how do we undo it?
+
+### 2. Gather advice
+
+The owner shares the brief with all stakeholders and gives them 24-48 hours to comment in writing. Stakeholders are expected to:
+
+- Raise concerns they can support with evidence
+- Suggest alternatives or mitigations
+- Declare if they have a conflict of interest
+
+The owner does not need to incorporate every piece of advice. The goal is to surface blind spots.
+
+### 3. Decide
+
+The decision owner makes the call. The owner is:
+
+- The relevant department lead for functional decisions
+- The CEO for cross-functional or high-stakes decisions
+- The board for capital, major partnerships, or existential bets
+
+The owner writes the decision in a durable document (issue comment, PR description, or committed file) and archives the brief alongside it.
+
+### 4. Communicate
+
+The owner announces the decision to all affected parties within 24 hours. The announcement includes:
+
+- What was decided
+- Why (with a link to the decision record)
+- What changes for whom
+- When the decision takes effect
+- How to raise new information that might change the outcome
+
+### 5. Review
+
+Major decisions are revisited on a schedule:
+
+- **30-day check:** Did the expected outcome materialize? Any early warning signs?
+- **90-day review:** Was the decision correct? What did we learn?
+- **Annual audit:** Which decisions should we reverse or update?
+
+The owner of the original decision is responsible for scheduling these reviews.
+
+## Decision Criteria
+
+We evaluate options against these criteria, weighted by the specific decision:
+
+1. **Reversibility:** Can we undo this cheaply? Higher weight for one-way doors.
+2. **Evidence quality:** How strong is the supporting data? Higher weight for novel or risky bets.
+3. **Optionality:** Does this close off future paths or keep them open?
+4. **Execution cost:** Time, money, and opportunity cost.
+5. **Alignment:** How well does this fit our charter and operating principles?
+
+## Who Signs Off
+
+| Decision tier | Decision owner | Required sign-off |
+|---|---|---|
+| Functional (affects one team) | Department lead | None; document and notify |
+| Cross-functional (affects multiple teams) | CEO | Department leads consulted |
+| High-stakes (irreversible, expensive, existential) | CEO | Board approval required |
+| Security / legal / compliance | SecurityEngineer or Ops | CEO must be informed |
+
+## Anti-Patterns
+
+- **Consensus theater.** If everyone must agree, no one decides. We optimize for speed and clarity, not universal comfort.
+- **Analysis paralysis.** Two good options with similar expected value? Pick one and ship. The cost of deliberation often exceeds the cost of being slightly wrong.
+- **Decisions without owners.** Every decision has a single named owner. No committees.
+- **Invisible reversals.** If we change our mind, we write a new decision record. No ghosting past decisions.

docs/company/operating-model.md

@@ -0,0 +1,47 @@
+# Operating Model
+
+## Decision Rights
+
+We run a **advice-and-decide** model, not consensus.
+
+- **The owner decides.** Every initiative has a single named owner. That owner gathers input, makes the call, and owns the outcome. No design-by-committee.
+- **The owner writes the decision record.** Every significant decision gets a one-paragraph rationale committed to the relevant issue or document.
+- **Escalation is a feature, not a failure.** If an owner is stuck, blocked, or faces a one-way door they are uncomfortable opening alone, they escalate to their manager with a clear recommendation, not a question.
+
+### Authority Matrix
+
+| Decision type | Owner | Escalation path |
+|---|---|---|
+| Product feature priority | Product lead | CEO |
+| Technical architecture | CTO | CEO |
+| Design system changes | UXDesigner | CTO |
+| Marketing message / channel | CMO | CEO |
+| Hiring / firing | Department lead | CEO |
+| Budget > $500/mo or one-time > $2,000 | CEO | Board |
+| Security policy, auth, secrets | SecurityEngineer | CTO → CEO |
+| Skill / agent governance | CEO | Board |
+
+## Work Ownership
+
+- **One task = one owner = one branch.** No shared ownership. If a task is too big for one person, split it.
+- **Tasks are issues in Paperclip.** Backlog → assigned → in progress → review → done.
+- **Context is durable.** Every task includes: objective, acceptance criteria, current blocker (if any), and next action. When an owner changes, the context transfers in writing.
+
+## Review and Shipping
+
+- **Nothing ships without review.** Code needs PR review. Design needs design review. Copy needs copy review. The owner names the reviewer, and the reviewer is accountable for the quality of their review.
+- **Review is a gate, not a discussion.** Reviewers approve, request specific changes, or escalate. Open-ended "what do you think?" loops are not reviews.
+- **Ship on green.** If CI passes and review is approved, the owner merges. No additional sign-off layers.
+
+## Disagreement and Escalation
+
+1. **First, disagree in writing.** Both parties write down their position and the evidence behind it. Oral disagreements are too cheap.
+2. **If unresolved in 24 hours, escalate.** The owner escalates to the nearest common manager with both positions documented.
+3. **The manager decides within 48 hours.** The manager picks a path, writes the rationale, and both parties commit.
+4. **No re-litigation for 30 days.** Once decided, the issue is closed. Revisit only with new evidence.
+
+## Communication
+
+- **Async-first.** Write it down before you say it out loud. Meetings are for decisions that cannot be made async, not for status updates.
+- **Default public.** Work in public channels and shared documents unless there is a specific confidentiality reason.
+- **No surprises.** If something is going wrong, the affected people hear it from us before they hear it from data.

docs/company/org.md

@@ -0,0 +1,70 @@
+# Organizational Structure
+
+This is a blueprint. All roles listed below are **unfilled** until explicitly hired.
+
+## Executive
+
+### Chief Executive Officer (CEO)
+- **Accountable for:** Company strategy, P&L, capital allocation, key hires, cross-functional coordination, board communication.
+- **Mandate:** Set priorities and make product decisions. Resolve cross-team conflicts. Approve or reject proposals from direct reports. Hire new agents when the team needs capacity. Unblock direct reports when they escalate.
+- **Status:** Filled.
+
+## Product & Engineering
+
+### Chief Technology Officer (CTO)
+- **Accountable for:** Technical roadmap, system architecture, engineering execution, technical hiring, engineering quality and velocity.
+- **Mandate:** Own the technical strategy and its execution. Define architecture standards. Manage engineering backlog and delivery. Build and lead the engineering team. Ensure operational reliability and security posture.
+- **Reports to:** CEO
+- **Status:** Unfilled.
+
+### Software Engineer(s)
+- **Accountable for:** Writing, testing, and shipping code that meets acceptance criteria.
+- **Mandate:** Implement features, fix bugs, write tests, and improve code quality. Follow architecture decisions and raise concerns early. Own tasks end-to-end from assignment to merge.
+- **Reports to:** CTO
+- **Status:** Unfilled.
+
+### Security Engineer
+- **Accountable for:** Security posture, threat modeling, incident response, auth/secrets governance.
+- **Mandate:** Review security-sensitive changes. Define and enforce security policies. Handle vulnerability disclosures and incident response. Audit permissions and access controls.
+- **Reports to:** CTO
+- **Status:** Unfilled.
+
+### QA / Validation
+- **Accountable for:** Quality bar of shipped work, test coverage, user-facing verification.
+- **Mandate:** Write and maintain test plans. Validate user-facing changes. Catch regressions before they reach users. Own the definition-of-done checklist for releases.
+- **Reports to:** CTO
+- **Status:** Unfilled.
+
+## Design & UX
+
+### UX Designer
+- **Accountable for:** User experience, visual design, design system, user research.
+- **Mandate:** Design interfaces and flows. Maintain and evolve the design system. Conduct user research and usability testing. Review all UX-facing changes before ship.
+- **Reports to:** CTO (matrixed to product decisions via CEO)
+- **Status:** Unfilled.
+
+## Growth & Marketing
+
+### Chief Marketing Officer (CMO)
+- **Accountable for:** Brand, content, growth strategy, developer relations, market positioning.
+- **Mandate:** Define and execute marketing strategy. Own content and social channels. Drive growth experiments. Build developer relations and community. Measure and report on growth metrics.
+- **Reports to:** CEO
+- **Status:** Unfilled.
+
+## Operations
+
+### Operations Lead
+- **Accountable for:** Legal, finance, vendor management, compliance, people operations.
+- **Mandate:** Run payroll and contracts. Manage vendor relationships and budgets. Ensure compliance. Handle people ops and onboarding/offboarding.
+- **Reports to:** CEO
+- **Status:** Unfilled.
+
+## Hiring Sequence (Recommended)
+
+1. **CTO** -- needed before any product work begins.
+2. **Software Engineer** -- first IC hire to execute on technical backlog.
+3. **UX Designer** -- needed once user-facing work begins.
+4. **QA** -- needed once regular shipping cadence is established.
+5. **CMO** -- needed once we have a product story to tell.
+6. **Security Engineer** -- needed once we handle user data or exposed infrastructure.
+7. **Operations Lead** -- needed once we have contracts, payroll, or compliance obligations.

docs/company/ways-of-working.md

@@ -0,0 +1,56 @@
+# Ways of Working
+
+## Version Control Discipline
+
+- **One task = one branch = one owner.**
+  Every issue gets its own branch. Branch names: `owner-identifier/short-description` (e.g., `ceo/ELF-3-hiring-plan`).
+- **No direct commits to `main`.** All changes go through a pull request.
+- **Rebase before merge.** Keep history linear and readable. Squash fixup commits.
+- **Commit messages explain why, not what.** The diff shows what changed; the message explains the reasoning.
+
+## Task Lifecycle
+
+```
+backlog → todo → in_progress → in_review → done
+   ↑___________|    ↑___________|
+```
+
+- **backlog:** Valid idea, not scheduled. Anyone can add items.
+- **todo:** Scheduled and ready. Has clear acceptance criteria.
+- **in_progress:** Checked out by an owner. Active work is happening.
+- **in_review:** Owner has handed off for review or approval.
+- **done:** Accepted and merged. No further action required.
+- **blocked:** Cannot proceed. Must name the blocker and who must act.
+
+## Standups
+
+We do not do live standups. We do **async written standups** in the issue thread or project channel.
+
+### Standup Template
+
+```
+**Yesterday:** What did I complete?
+**Today:** What am I working on?
+**Blocked:** What is in my way and who needs to act?
+```
+
+- Posted by 10:00 AM local time, every working day.
+- If you are blocked, you must name the owner of the unblock action.
+
+## Definition of Done
+
+A task is not done until **all** of the following are true:
+
+1. **Code is written and reviewed.** At least one approval from a qualified reviewer.
+2. **Tests pass.** CI is green. New code has relevant test coverage.
+3. **Documentation is updated.** If the change affects APIs, interfaces, or runbooks, the docs are updated in the same PR.
+4. **No secrets in plain text.** Credentials, tokens, and keys are never committed.
+5. **User-facing changes are validated.** QA or the owner has verified the change in a staging environment.
+6. **Rollback path is known.** For infra or deploy changes, the owner can articulate how to revert.
+7. **Handoff is clean.** If follow-up work exists, it is captured in a new issue with acceptance criteria and an owner.
+
+## Working Hours and Availability
+
+- **Async-first.** We do not require synchronous availability. Write things down.
+- **Response-time expectations:** 4 hours during business hours for blocking questions; 24 hours for non-blocking context.
+- **Deep work blocks.** Meetings and interruptions are the exception. Protect 2-4 hour blocks for focused work.