Files
Local-LLC/ORGANIZATION.md
T
Christopher Clendening 96b7ff9766 feat: Add foundational documentation for security, workflow, and project management
- Create SECURITY.md to outline security policies and practices.
- Establish WORKFLOW.md detailing the project lifecycle from planning to retrospective.
- Introduce decision log structure in decisions/README.md for tracking architecture decisions.
- Document Project Manager role with responsibilities, limitations, and operational workflows.
- Implement templates for ADRs, bugs, meetings, projects, retrospectives, RFCs, roadmaps, and sprints.
- Set up memory logs for architecture and company-wide lessons learned.
- Define terminology for consistent understanding across the organization.
2026-07-30 13:34:07 -04:00

6.2 KiB

ORGANIZATION.md

This document defines every role in Local LLC, what each one owns, and how they relate to each other. It is the reference for "whose job is this" — if you're unsure who should handle something, it's answered here before it's escalated anywhere.

Org chart

                          Founder
                             │
                   Executive Office (Bionic)
                    (outside the company)
                             │
                      ── approval gate ──
                             │
                             ▼
                            CEO
                             │
                      ┌──────┴──────┐
                      ▼             ▼
                 Architect    Project Manager
                      │             │
        ┌─────────────┼─────────────┼─────────────┬────────────┬──────────────┐
        ▼             ▼             ▼              ▼            ▼              ▼
     Backend      Frontend        ML             QA        Security        DevOps
    Engineer      Engineer     Engineer        Engineer     Engineer      Engineer
                                                                              │
                                                                        Documentation
                                                                          Engineer

Architect and Project Manager are peers, not a hierarchy — Architect owns technical direction and review authority; Project Manager owns Plane and the mechanics of getting work executed. Engineering roles report to both in different dimensions: technical questions go to the Architect, task/priority/status questions go to the Project Manager.

Roles

Founder (human)

The only human. Final authority on strategic direction. Runs planning sessions with the Executive Office. Full detail: FOUNDER.md.

Executive Office (Bionic)

Not an employee — explicitly outside the company's chain of command. The Founder's strategy and brainstorming partner. Drafts proposals, never executes them. Full detail: FOUNDER.md.

CEO

The first role inside the company to see an approved plan. Owns:

  • Creating Epics in Plane from Founder-approved direction
  • Setting milestones
  • Prioritizing work across epics
  • Authorizing sprint starts

The CEO does not write code and does not re-litigate scope that already cleared the Founder's approval gate — its job is translating approved direction into company-level priorities, then handing execution mechanics to the Project Manager.

Project Manager

The company's PM office and the only role that "lives" in Plane day to day. Owns:

  • Breaking Epics into Stories and Stories into Tasks
  • Assigning tasks to the right engineering role
  • Starting and closing sprints
  • Watching blockers and reopening/reassigning stalled work
  • Tracking velocity and burndown, reporting it upward
  • Producing the execution package after Founder approval (see FOUNDER.md)

The Project Manager never writes code and never makes technical architecture calls — those escalate to the Architect. Full detail: employees/project-manager/.

Architect

Technical design authority and the escalation point for engineering disagreements. Owns:

  • Reviewing designs and PRs for architectural consistency
  • Writing and approving ADRs (see DECISIONS.md)
  • Resolving technical disagreements between engineering roles
  • Flagging when a task's technical scope has grown beyond what was approved (escalates to Project Manager / CEO, and to the Founder if it changes strategic direction)

Backend Engineer

Implements server-side/API/data-layer work. Claims tasks, updates progress, links commits, opens PRs, responds to review feedback.

Frontend Engineer

Implements user-facing interfaces. Same task/commit/PR discipline as Backend.

ML Engineer

Implements model training, evaluation, and ML-specific infrastructure. Same task discipline; additionally responsible for documenting datasets, evaluation methodology, and model limitations as part of any ML-related PR.

QA Engineer

Verifies work before it's considered done. Owns:

  • Testing completed tasks against acceptance criteria
  • Filing bugs with reproduction steps
  • Reopening stories/tasks that fail verification, moving them back to "In Progress"
  • Refusing to sign off on anything it hasn't actually run

QA has the authority to reject any task regardless of who implemented it, including work from the Architect. This authority is not overridable by anyone except the Founder.

Security Engineer

Reviews for security issues across the codebase: secrets handling, auth, dependency risk, supply chain. Full policy in SECURITY.md. Has standing authority to block a merge on a security finding; that block can only be lifted by the Security Engineer or escalated to the Founder.

DevOps Engineer

Owns CI/CD (ACT Runner), deployment pipelines, and environment/infrastructure concerns not covered by Security. Full policy in ACT_RUNNER.md.

Documentation Engineer

Owns keeping this repository and project-level docs accurate as the company evolves. A feature is not complete until the Documentation Engineer has confirmed relevant docs reflect it (see COMPANY.md values).

Employee identity

Every AI employee (CEO, Architect, Project Manager, and each engineering role) has its own:

  • Plane account
  • Gitea account, SSH key, and Git identity
  • Persistent memory (employees/<role>/MEMORY.md)
  • System prompt (employees/<role>/PROMPT.md)

This is what makes Plane's activity feed and Gitea's commit history a real, auditable account of who did what — see COMPANY.md for why this matters and GITEA.md for the naming convention.

Adding a new role

Follow the pattern established in employees/project-manager/: README.md, ROLE.md, RESPONSIBILITIES.md, LIMITATIONS.md, WORKFLOW.md, PROMPT.md, MEMORY.md, and SUCCESS_METRICS.md. A role isn't real until all eight exist — a folder with just a prompt is not an onboarded employee.