v1-user-hierarchybreakdown.mdA Sustentus organisation has no reporting structure, so nobody has a manager and a leader cannot see their people's customers, service leads or delivery work. The scope's answer is deliberately small: one pointer on each user record — their manager — is the organisation, and everything else falls out of it. Visibility is inherited upward through that chain; ownership never is.
The second half of the scope is ownership of the customer's service lifecycle. Paul was explicit that at every stage there must be exactly one named owner, and that this is unclear today either side of BRD approval. Sales becomes a real user role owning the lead until the customer approves; a CSM must be assigned before that approval is even possible; and at the approval, ownership transfers by itself. Vendor is the organisation, not a person, and is not a user role.
The rest is consequence: location collapses to Region and Country only, those two plus My Team become the standard filters everywhere, and licence classes are counted and reported but never enforced. Paul's review trimmed rather than grew this — six business rules retired as restatements, the two-hat model struck, and the worked example cut to four people.
feature-role-matrix/leads — service-lead ownership, the Sales role, and the handoff.feature-role-matrix/projects — the CSM's ownership of the customer after approval.feature-role-matrix/experts — internal Experts in the hierarchy, external ones by assignment.service-journey/lead-intake and .../requirements — where a lead is raised and where the BRD
is completed and approved; the ownership transfer sits on that boundary.service-journey/delivery — the SDM's reach and the Expert-vacancy case.business/roles — all six personas gain an explicit Owns / Can see / Can change split.Stub 1 is the only true foundation. Stubs 2, 3, 4 and 6 depend on it and on nothing else, so they can run in parallel once it lands. Stub 5 is the only join — it needs both the geography of stub 2 and the visibility model of stub 3. The linear order above tie-breaks foundation-first, then by what unblocks the most work (2 and 3 feed stub 5), then by impact, leaving the Should-priority licence report last.
Note on scope size. scope.md runs over the 2,000-word ceiling with §6 on its 20-rule cap and
§14 at 13 decisions against a cap of 10 — the documented signal that this is more than one scope.
The cut above is the honest decomposition of it as agreed; if the source is split later, stubs 1,
2, 3 and 6 form the organisation-model half and stub 4 the service-lifecycle-ownership half.
_done/inherited-visibility.mdToday a person sees either only their own work or, as an administrator, everything. A leader cannot see their people's customers, service leads or delivery work, so they chase by email. The reporting line from stub 1 exists to answer exactly this — but nothing reads it yet.
Visibility is inherited upward through the reporting hierarchy, and only visibility is.
team-region-country-filters.service-lead-ownership-and-handoff.Covers FR-4, FR-11 and BR-11, BR-12; proves AC-2, AC-13. Paul's one-line ruling governs this whole
feature: "Managers inherit visibility only. Never ownership." He also asked specifically that
Visibility, Ownership and Permissions be kept separate rather than mixed — §7 of scope.md carries
that split and Define should preserve it rather than collapsing the columns. The SDM's reach follows
their reporting hierarchy and the Region/Country filters; there is deliberately no separate SDM
regional assignment in V1 (D-7). BR-9, BR-10 and BR-13 from the Doc were retired at the fold as
restatements — their content lives in §7's role table, which is the source to build from.
_done/licence-class-reporting.mdOnce every user holds exactly one role, the business needs to know what its user base costs to licence — but it needs that as a number it can look at, not as a gate that starts locking people out of a platform they are mid-project on.
A licence report derived entirely from the role each user already holds.
Covers FR-12 and BR-27; proves AC-8. Priority is Should, and it is last in the batch for that reason. Paul cut the drafted four-class model down twice: "Licensing should be much simpler. Platform Licence & Admin can't have one without the other. Sales Licence. Delivery Licence" — and then, on the open decision about how the Platform licence composes, "This is a commercial decision, not a product one." BR-26, which spelled out the class composition, was retired at the fold for that reason. Build the report against the three classes above and leave the commercial structure where Paul put it: outside the product. The hard line that survives is BR-27 — this never gates anyone.
Recorded by the intake-easy-features session; these rulings bind Define.
_done/regions-and-countries.mdLocation is recorded at a territory and state level of detail the business does not use, so a regional total has to be assembled by hand and cannot be trusted to add up. Paul's rule is blunt: two geographic levels only, used consistently for users, customers, service leads, dashboards and reporting.
Region and Country become the only two location levels anywhere in the platform.
team-region-country-filters.Covers FR-2, FR-10 and BR-15, BR-16, BR-17; contributes to BR-19; proves AC-4, AC-9. Paul rewrote this section twice in review and the wording to honour is his: "Two levels only. Region contains Countries. One Country belongs to one Region. Geography filters data. Geography never grants access." Retiring territory and state is part of this feature, not a follow-up — the scope says retired everywhere, this round. A country with no region yet is a legitimate state, not an error: the Country filter must still find it.
Recorded by the intake-easy-features session; these rulings bind Define.
_done/service-lead-ownership-and-handoff.mdAt every stage of the customer's service lifecycle there should be exactly one named owner, and today that ownership is unclear either side of BRD approval. No one formally owns a service lead before the customer approves, and the handover to service delivery is a conversation that sometimes does not happen.
Sales becomes a real user role that owns the lead, and ownership transfers by itself at approval.
Covers FR-5, FR-6, FR-7, FR-8 and BR-20, BR-21, BR-22, BR-23, BR-24, BR-25; proves AC-5, AC-10, AC-11. Two of Paul's rulings drive this feature. First, on terminology: "Don't refer to pipeline ownership — wrong term. It's service lifecycle ownership. It's about the customer's complete service journey." Use that language throughout. Second, on the default owner, in his words: "Every Service Lead must have exactly one owner. Default owner = Sales. If raised by another workflow, ownership is assigned according to the configured Service Lead source." That is deliberately more general than "no lead without a Sales owner" — it future-proofs the model without changing V1 behaviour for inbound sales. One comment in the Doc read "The CSM remains accountable for discovery, qualification and completion of the BRD"; this was raised at the fold and ruled a slip for "Sales", consistent with D-1, D-9, D-10 and his own role list — build it as Sales.
_done/team-region-country-filters.mdOnce a leader can see their whole team's work, the next question is immediately "just EMEA" or "just my direct line". Without a consistent way to narrow, every surface grows its own ad-hoc controls and two views of the same population disagree.
Three filters — My Team, Region and Country — appearing consistently on every surface that shows a population of work.
apps/demo) is
not a delivery target for this feature — Design prototyped the filters there, and that prototype
is not what Build ships.regions-and-countries.inherited-visibility.Covers FR-9 and BR-19; proves AC-3. Paul made the surface list explicit — "These filters appear consistently across: Dashboards, Tiles & Lists, Reports & Analytics" — and separately, "Region and Country become standard filters across all dashboards." Consistency is the requirement: the same three controls, behaving identically, not three variations. The join in the batch: this stub needs both the geography of stub 2 and the visibility model of stub 3, so it must not start before both have landed. Geography filters data; it never grants access — a filter is not a permission.
_done/user-record-and-reporting-line.mdA Sustentus organisation has no reporting structure. Nobody has a manager, there is no notion of a team, and there is nowhere to record who a person reports to. Every other part of this scope — inherited visibility, ownership handoff, regional roll-up — needs that single fact to exist first.
Every user record carries exactly seven facts — name, email, role, manager, region, country and status — and the manager pointer is the organisation structure. There is no separate chart to build.
inherited-visibility.regions-and-countries; this feature only stores them.Covers FR-1, FR-3 and BR-2, BR-3, BR-4, BR-5, BR-6, BR-7, BR-8; proves AC-1, AC-6, AC-7, AC-12. Paul was explicit and repeated: one user, one role, one manager, one reporting line — "no two hats". The two-hat model that appeared in the drafted scope was struck outright, so do not carry any per-role manager concept forward. Vendor is the organisation (tenant), not a user role — the six roles are Admin, Sales, CSM, SDM, Expert and Customer, with Sales new in this scope. Region and country are stored on the record here but only get meaning in stub 2. Street address and postal code stay as contact information with no reporting meaning.
Recorded by the intake-easy-features session; these rulings bind Define.