holdex · zolotokrylin · Sep 2, 2026 · Sep 1, 2026 · Sep 1, 2026 · Sep 1, 2026
diff --git a/README.md b/README.md
@@ -1,17 +1,8 @@
 # Developer Guidelines
 
-Welcome to our Developer Guidelines! Your journey to shape the future of AI and Fintech
-starts here.
-
-## For Developers
-
-_Developers_ are everyone creating value: business developers, designers,
-engineers, marketers, and beyond. We build businesses, products, partnerships,
-customer relationships, processes, and delivery methods, crafting the future we
-envision.
-
-Everything is indexed from the [documentation index](./docs/README.md): start
-there to reach the contributing guide, the developer rules, and the rest.
+Welcome! Your journey to shape the future of AI and Fintech starts here. Start
+with the [Guidelines index](./docs/README.md) to reach the contributing guide,
+the developer rules, and the rest.
 
 Subscribe to repository notifications to stay updated with frequent fixes and
 improvements.

diff --git a/docs/ADVOCACY.md b/docs/ADVOCACY.md
diff --git a/docs/APPLICATION_SUCCESS.md b/docs/APPLICATION_SUCCESS.md
diff --git a/docs/COMPENSATION.md b/docs/COMPENSATION.md
@@ -1,30 +1,86 @@
 # Compensation Guide
 
-**Goal:** Reward impact, not titles or location. Pay based on merit—what you
-deliver independently.
+**Goal:** Reward impact, not titles or location. Pay follows what you deliver.
 
-> Open roles: [holdex.io/c/jobs](https://holdex.io/c/jobs) | Mission: [holdex.io/about](https://holdex.io/about)
+> Open roles: [holdex.io/c/jobs](https://holdex.io/c/jobs) | Mission:
+> [holdex.io/about](https://holdex.io/about)
 
 ## Core Rules
 
-1. **Clear incentives** — Same job, same level = same pay. More results = more
-   rewards.
-1. **Simple framework** — Consistent rules for growth.
+Same job, same level pays the same, and more results earn more reward. The
+framework stays simple and consistent so growth doesn't get renegotiated case by
+case.
 
-## Levels & Core Skills
+## Two Tracks
 
-| Level            | Key Traits & Expectations                                                                           | Team Culture                                                                                                           | Goals                                    | Problems & Solutions                                            |
-| ---------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | --------------------------------------------------------------- |
-| **Entry**        | Student mindset: Bug-free. Execute tasks. Research. Learn fast. Communicate clearly. Take feedback. | Follow [principles](https://holdex.io/c/learn/principles) & [GitHub rules](https://holdex.io/c/learn/github-strategy). | Understand goals.                        | Solve, estimate, research, present. Help juniors.               |
-| **Intermediate** | Confident executor: Solve complex problems. Lead small parts. Help Entry. Strong opinions.          | Follow principles. Remind team.                                                                                        | Break into problems. Research solutions. | Identify real problems. Break down. Prioritize. Review juniors. |
-| **Lead**         | Project owner: Run full projects. Delegate. Coach team. Align with business. Inspire.               | Coach others. Lead in projects.                                                                                        | Set timelines. Ensure delivery.          | Delegate. Distribute to best fit.                               |
-| **Partner**      | Big-picture leader: Own multiple projects. Shape strategy. Say no when needed. Grow culture.        | Improve rules/values.                                                                                                  | Define business goals & priorities.      | (All above + strategic input)                                   |
+Every role falls into one of two buckets: delivery or acquisition.
+
+Delivery covers building and rendering the service: engineering, design, and the
+operational work that keeps an account running. It's paid on hard skill and
+cost-effectiveness. Developers are paid per code delivered, billed hourly per
+month, and the levels below set what that skill looks like at each stage.
+
+Acquisition covers client acquisition and retention: sales and business
+development. It's commission-based on closed deals, and if you bring in a lead
+that gets onboarded and you're positioned to join as Partner for that account, a
+fixed rate is added on top of commission, per Pay by Level below.
+
+The two tracks are judged on different things by design. Delivery is judged on
+skill and problems solved, the same principle [DEV-440](./rules/DEV-440.md)
+states for reviewing pull requests: value delivered, not effort spent.
+Acquisition is judged on closed business, not on hours logged or activity
+performed. Research, CRM upkeep, and reporting are methods, not deliverables:
+they support acquisition work but aren't paid for on their own.
+
+## Delivery Levels
+
+Four levels, each with its own traits, culture, and goals.
+
+**Entry** operates with a student mindset: bug-free execution, fast learning,
+clear communication, and taking feedback well. Entry follows the
+[Developer Guidelines](../README.md), understands the goals handed to them, and
+solves the Problems already scoped for it: researches, estimates, and presents a
+solution, while helping other Entry-level teammates.
+
+**Intermediate** is a confident executor: solves complex problems, leads small
+parts of a project, helps Entry-level teammates, and holds strong opinions.
+Where Entry solves the Problems it's given, Intermediate additionally breaks a
+whole Goal into its full set of Problems (per [DEV-150](./rules/DEV-150.md)),
+identifies real problems rather than symptoms, prioritizes them, and reviews
+Entry-level teammates' work.
+
+**Lead** owns projects end to end: runs full projects, delegates, coaches the
+team, aligns work with the business, and inspires. Lead sets timelines, ensures
+delivery, and distributes work to whoever fits it best.
+
+**Partner** thinks in the big picture: owns multiple projects, shapes strategy,
+says no when needed, and grows the culture. Partner defines business goals and
+priorities and improves the rules and values everyone else works within.
+
+## Pay by Level
+
+Entry is the trial phase run by [holdex/trial](https://github.com/holdex/trial):
+unpaid, and it ends when the trial goal clears and the contributor graduates to
+Intermediate.
+
+Intermediate and Lead are paid an hourly rate agreed per engagement and recorded
+in your own Special Terms, which HR prepares from the template in
+[holdex/contractor-terms](https://github.com/holdex/contractor-terms) and stores
+privately. Ask your lead for your number. The rate is fixed for the engagement,
+not the total: more hours delivered still means more pay, per Core Rules above.
+
+Partner is paid a fixed rate plus a percentage of the deals they close. The
+exact numbers are set by leadership per deal: ask your lead for the current
+terms.
+
+Every level above Entry requires ongoing compliance with the Developer
+Guidelines. Falling out of compliance is a demotion back to Entry, not a
+warning: the rate that comes with a level is conditional on holding the bar, not
+a status earned once.
 
 ## Growth Path
 
-| Level            | Focus                       |
-| ---------------- | --------------------------- |
-| **Entry**        | Learn → Execute → Ask       |
-| **Intermediate** | Solve → Teach → Lead small  |
-| **Lead**         | Own → Delegate → Coach      |
-| **Partner**      | Strategize → Scale → Say No |
+Entry grows by learning, executing, and asking questions. Intermediate grows by
+solving, teaching, and leading small pieces of work. Lead grows by owning
+projects, delegating, and coaching. Partner grows by setting strategy, scaling
+the business, and knowing when to say no.
diff --git a/docs/README.md b/docs/README.md
@@ -1,9 +1,8 @@
-# Documentation
+# Guidelines
 
-The index for the `docs/` tree, grouped by who reads it. The repo-root
-[README](../README.md) is the entry point and links here; this file links every
-document below it, so nothing is orphaned (see
-[DEV-337](./rules/DEV-337.md)).
+_Developers_ are everyone creating value at Holdex: business developers,
+designers, engineers, marketers, and beyond. This is the index for everything
+that guides that work, grouped by who reads it.
 
 ## Contributors
 
@@ -16,23 +15,8 @@ How work is proposed, built, reviewed, and shipped.
 
 Working here: policies and programs.
 
-- [Advocacy](./ADVOCACY.md)
-- [Application Success](./APPLICATION_SUCCESS.md)
 - [Code of Conduct](./CODE_OF_CONDUCT.md)
 - [Compensation](./COMPENSATION.md)
 - [Expenses](./EXPENSES.md)
 - [Leave Policy](./LEAVE_POLICY.md)
 - [Referral Program](./REFERRAL.md)
-- [Trial](./TRIAL.md)
-
-## Product (end users)
-
-Shipped, user-facing product documentation lives under `docs/product/`, added as
-features ship. It is the only subtree meant to render as an end-user docs site.
-See [DEV-180](./rules/DEV-180.md) and [DEV-390](./rules/DEV-390.md).
-
-## Specs (developers)
-
-Intended, not-yet-shipped behavior lives under `docs/specs/`, a planning
-artifact for developers rather than end-user documentation. See
-[DEV-180](./rules/DEV-180.md).
diff --git a/docs/TRIAL.md b/docs/TRIAL.md
diff --git a/docs/rules/DEV-180.md b/docs/rules/DEV-180.md
@@ -29,6 +29,9 @@ obvious goes nowhere, because a field visible on the screen documents itself.
 1. `docs/specs/<feature>.md` holds only unimplemented behavior for a Goal. The
    product docs hold only what ships today: `docs/product/<feature>.md` by
    default, or the path the repo's docs README declares where it differs.
+   `docs/product/` is the only subtree meant to render as an end-user docs site;
+   `docs/specs/` is a planning artifact for developers, not end-user
+   documentation.
 1. Each PR that delivers behavior moves the delivered sections out of the spec.
    Graduate what a user cannot infer from the UI, drop the rest. A spec may
    graduate into more than one file.