PM infrastructure (Level 2 SCQ): conversion report

What the file claims

227 propositions, 227 roles, 211 relationships, 10 assumptions, 1 assessment.

By view (propositions): goal 16 · current_reality 79 · conflict 10 · future_reality 34 · transition 16 · prerequisite 72 (sum 227). Relationships by view: goal 17 · current_reality 65 · conflict 10 · future_reality 17 · transition 9 · prerequisite 93 (sum 211). The earlier conflict count of 11 included the assessment.

Method: counted with grep/awk on pm-infrastructure.ltp.yaml (PyYAML not installed). Entities are the block - id: items with a tree: line under entities:; designations and relationships are the flow-style - { id: ... items under their sections (relationships carry tree:); assumptions and the assessment are counted in their own sections. Counts of entities and designations agree (227).

The shape, in one view

Diagrams for every view are in crt.md. Summary of the six views:

• Goal: everyone, human and AI, knows what to do next and the processes around it, and trusts that information. Six CSFs: plans recorded in a common way; shared weekly/monthly planning; everyone knows where things live; tasks actionable; records current; views by project and per person. Necessary conditions hang off them (planning techniques, priority announced, update routines, quick overview, checkable by AI, open to collaborators, plan document, epic owners, project-tracker link).
• Current reality: 79 propositions in cause chains grouped by CSF:
  • CSF1: no agreed rule, conventions unsettled while AI changes how we work → no plan pattern → plans in varied shapes; no shared definition of a plan, no AI harness, Coggle.
  • CSF2: no plan owner or process → no consolidated team plan; priority changes ad hoc (no air traffic controller, unclear decisions, unworked dependencies, rebrand, onboarding).
  • CSF3: tasks split across systems, no system of record, tool preferences, time pressure → where to look, duplicates, copying.
  • CSF4: Beads written as notes, no priority or owner, unclear assignments, plans evolving, no project-tracker link → hard to act on.
  • CSF5: no sweep, legacy issues → stale and open finished tasks.
  • CSF6: two teams in two tools, no cross view, AI pace, non-technical input not reaching systems → no week view.
  • Four candidate core causes (in crt.md): no agreed rule or system of record; no planning owner or process; two teams in two tools; building while running.
• Conflict: two clouds. Tools: each person fluent in their own tool (each team keeps its own) vs one shared picture (one shared tool); resolved by trial of injections 1 (one system of record per kind of work plus an aggregated view) and 3 (link, do not copy). Build vs ship: deliver on time vs set time aside for system work; resolved by choosing regular system time (assessment c-as-bs-breaks).
• Future reality: 19 injections and 8 desired effects (one picture, no second queue, system work happens, less overhead, trust in AI, plans in common shape, readable priority, informed collaborators). Injections include system of record per kind, link not copy, aggregated view, fixed system slot, deferring deliverables, AI chores, AI cites source, project record shape, task convention, weekly summary, plan owners, priority as state, project catalogue, clean data first, data steward, deputy. Five negative branches (dirty view, slot eaten, crossover unclear, Beads opaque, Uriel overloaded) each have a mitigation.
• Prerequisite: ten objectives A–J, each with obstacles and intermediate objectives: systems of record; weekly per-person view; weekly plan in a fixed slot; minimal project records; task convention; weekly human summary; AI cites source; data steward; shared agent skills; team knows the system and new members are onboarded. Table below.
• Transition: the three hypothesis checks (sample Beads, trace pivots, ask where to log) plus the mock page; the tools trial (agree the line, run a 2–4 week trial, review); and the one build-vs-ship step (set a fixed weekly slot).

CRT sessions (team meeting 12 Oct 2026)

Round 1 (CSF1, CSF3 start), speakers Rufus, Uriel, Fae:

• Chain: conventions not settled while AI changes how we work → no agreed rule for where things go and how written → people don't know where/how to write plans → plans in varied shapes (Markdown, A10, Coggle) or not written.
• Also contributing: no shared definition of "project plan" (Uriel: Asana tasks; Rufus: a structured plan document for significant projects, added as goal NC g-e-plan-document); no AI harness to prompt plan structures; Coggle's affordances for quick issue trees.
• Separate chain: no procedure for where meeting notes go or how they become tasks → outcomes become tasks only when someone takes initiative (Uriel).
• Everyone using a different system makes it hard to sync on each other's planning.

Round 2:

• CSF2 (agreed by team): no consolidated weekly/monthly plan; project plans not pulled down. Causes: no owner or fixed slot; no agreed generation process; no monthly level; no agreed department task lists; no process for priorities and deadlines (Fae). Inputs: weekly planning depends on CSF1 (projects planned) and CSF5 (records current), otherwise "making stuff up" (Rufus), added as goal links.
• CSF2 NC priorities (Rufus: relatively minor, not central): unclear or non-final decisions (e.g. podcast name); dependencies unworked in plans; no tracker to ask "where am I blocked"; current rebrand; onboarding (Fae learning who decides what); no air traffic controller, with Uriel taking the role but not set up, because there is no planning process, especially for content production.
• CSF3: no agreed places for reference material vs tasks (which tasks in Asana vs Beads/GitHub); no common AI skills or tooling; underneath, genuine tool preferences (Uriel Asana, Rufus Beads, each finds the other clunky) and time pressure to ship (Uriel: learning gap vs podcasts due next week); needs a trial that is automated and works for everyone.

Round 3 (CSF4-6), speakers Rufus, Uriel, Fae, Asdra:

• CSF4: Beads/GitHub tasks often lack priority and owner (Asana Media House tasks are structured, with templates Uriel built); GitHub assignments unclear; mid-task sign-off needs surface late (Fae: real, not a problem for her); plans evolve so owners matter at epic/feature level, not micro-task (Rufus, added as goal NC); projects don't link to a main tracking item, so plan context and task info are disconnected (added as goal NC); no AI-usable context for Media House processes (Uriel; Rufus: minor).
• CSF5: no decision on system of record → duplicates (easy cleanup once decided); no regular sweep → stale tasks; legacy GitHub issues from before the content tracker was settled. Artifact of history or systemic? Uriel: both — we're building operational processes while keeping work running; the rebrand exposed the gaps; sources of truth (planning site, Tao) are starting to form.
• CSF6: no quick view of my work, this week's or last week's plan; two teams in parallel (GitHub: Rufus, Asdra, Fae; Asana: Uriel, Yo-Yo, Valerie) with no shared way to work; no view across Media House and operations; per-person views unused; Sylvie and Valerie's input often doesn't reach systems (bridging roles Fae/Asdra only starting, no human write-ups); AI pace makes people-oriented views (GitHub Kanban) outdated and awkward for AI. Open question: what Sylvie and Valerie actually need.

Evaporating cloud on tools (12 Oct 2026)

Speakers Rufus, Uriel, Fae, Asdra. The cloud:

• A (objective): the team works as one, and everyone, human and AI, knows what to do next.
• B (requirement): each person works in a tool they are fluent and fast in. D (prerequisite): each team keeps its own tool (Media House in Asana, operations and planning in Beads and GitHub).
• C (requirement): everyone coordinates on one shared, current picture of work. D' (prerequisite): everyone uses one shared tool as a single system of record.
• D conflicts with D'.

Assumptions on the arrows (encoded as c-asm-*):

• B → A: people only work well and fast in tools they know, and time pressure leaves no room to learn another.
• D → B: being fluent means using a tool's own interface directly.
• C → A: coordination across Media House and operations needs one shared picture.
• D' → C: one shared picture needs one tool, because views stitched across tools are not reliable.
• D vs D': running two tools means copying between them, which creates a second queue.

Noted but not encoded: people own their work by touching their own list; AI aggregation cannot be trusted today (dirty data).

Team decision: test injections 1 (one system of record per kind of work, plus an aggregated per-person and weekly view) and 3 (link, do not copy) in a 2-4 week trial. Rejected for now: AI as a bridge into the other team's tool (injection 2). Rufus: open questions will surface quickly in the trial. The injections, their desired effects and the trial are in the future reality and transition views. No assessments: the team chose to test the injections, not concluded they break the cloud.

This replaces the earlier extracted cloud (one tracker vs separate trackers), which this one subsumes.

Evaporating cloud on build vs ship (13 Oct 2026)

Speakers Rufus, Uriel, Fae, Asdra. The cloud:

• A (objective): the team delivers its work and gets better at delivering it.
• B (requirement): this week's committed work, such as podcasts and the rebrand, ships on time. D (prerequisite): the available time goes to delivery, and system work waits.
• C (requirement): planning and tracking systems keep work coordinated. D' (prerequisite): regular time is set aside to build and adopt the system (learn tools, clean data, write skills).
• D conflicts with D'.

Team view on the assumptions (encoded as c-asm-bs-*):

• B → A is false as stated: deferring a podcast is not the end of the world.
• D → B is false: the claim of no slack fails, because messy systems already cost hours in hunting for tasks, duplicates and re-explaining.
• D' → C is true: systems only get built with dedicated time.
• D vs D' is partly true: there is probably enough time for both now, and AI lowers the cost of systematic cleanup. The problem is that system work is unstructured.

Decision: choose D'. Set aside regular, structured time to build and adopt the system, and prioritise it over shipping if it comes to that (assessment c-as-bs-breaks).

Injections chosen: fixed slots tied to weekly planning; deferring deliverables when needed; AI does systematic chores (sweeps, duplicate checks) with a person confirming. Rejected: building the system through delivery (Rufus: "not the case"). The transition is one action: set a fixed weekly slot alongside the weekly plan.

Open: who owns the slot and when it is (likely ties to CSF2's weekly plan owner).

Other conflicts (13 Oct 2026)

• Plan up front vs let plans evolve: resolved without a cloud. Owners at epic or feature level, not micro-tasks (goal NC g-e-epic-owners).
• One air traffic controller vs direct tasking: resolved without a cloud. Requests from Sylvie for Life Itself or Seeds of Renaissance work are prioritised within the team like any other work; Uriel is the air traffic controller.
• Structure owner per system vs anyone or AI edits: undecided, low weight; left for the trial to surface.
• Work through AI vs see my own list (trust): not a conflict for Uriel as long as he can go back to the source of truth, such as actual delivery dates in Asana. Example: Claude stated a due date that did not exist in Asana. Probably similar for Beads, which is more opaque to most of the team and would need training. Recorded as UDE r-e-ai-invents-data, cause r-e-beads-opaque, and injection f-e-ai-cites-source.

Future reality check (13 Oct 2026)

Speakers Rufus, Uriel, Fae, Asdra. Gap injections and negative branches, after the team's decisions:

• Flow vs state (Rufus): weekly plans and meeting notes are flow, like money arriving in a bank account; what people mostly need is state, like the balance: the current priority of each initiative (and possibly project). Priority changes go through Rufus and Uriel reprioritising initiatives; the weekly plan may note them, but nobody should have to read old weekly plans to know current priority. The goal NC g-e-priority-announced is amended accordingly.
• Project catalogue (Rufus): keep an index in the planning repo but do not force project files there; they often live with their initiative (or initiative area) in its own Git repo or Drive folder. Open question: how to aggregate across them for weekly planning and the sweep. Clear inside Media House (Asana), not yet across the organisation.
• Reference material: Asana records tasks; reference documents live in Drive or in Git Markdown. Rufus would prefer one place, ideally Git Markdown (versioned, good for AI); not decided.
• Negative branches (all confirmed by the team as real, with mitigations): dirty view → clean data first (key immediate task) plus a data steward, for example Asdra, at least outside Asana; slot eaten → defer rule; crossover unclear → link convention; Beads opaque → training or aggregated view; Uriel overloaded → Asdra as deputy; not communicated → team briefed and onboarding path. Brittle three-tool sweep: team not worried.

Prerequisite tree (13 Oct 2026)

Speakers Rufus, Uriel, Fae, Asdra. Ten implementation objectives, each with obstacles and the intermediate objective that steps past each. The weekly slot is Thursday 12:00–14:00. Rufus: Beads should gain structure later (epics vs features vs tasks, dependencies).

Task routing test (14 Oct 2026)

Where the tree holds this: conflict (tools cloud), future reality (system-of-record and link-not-copy injections), prerequisite objective A, transition (trial steps). Verdict: principle and crossover rule are traceable; the detailed line is still open, so 'where do I log X?' cannot yet be fully answered.

Beads IDs filled in 13 Oct 2026; shared-skills work is the lip-tqk.29 epic. Objective J steps other than announce-in-slot and collaborators-covered have no Beads task yet.

Existing but out-of-date instructions: workflow (docs/workflow.md); update rather than start afresh. Guide follows the trial review, so it records what worked.

Relationships asserted

From the SCQ extraction (9 Oct)

The original 14 links still in the file keep their source-sentence evidence. A 15th, c-rel-trackers-conflict (separate vs one tracker), was replaced by the tools cloud and is no longer in the file.

From team meetings (12–13 Oct)

The other 197 relationships (211 less the 14 above), by view. Entity ids are shortened (no x-e- prefix).

Goal (17)

Current reality (54)

Conflict (10)

Future reality (17)

Transition (6)

Prerequisite (93)

Judgment calls for you

1. Is the tracker cloud the core conflict? ✅ Superseded 12 Oct 2026 by the evaporating cloud on tools. I read L72 as a dilemma: separate trackers vs one tracker, both serving "see work by project and per person". If so, the injection is probably separate trackers plus a per-person aggregation layer (which the planning skill's team_sweep.py partly is). Alternative: it is a tooling trade-off, not the root of the problem.
2. H1 as contributes_to. "Partly confirmed" is not the same as "partly explains". I kept the link because you confirmed it. Alternative: drop the link until the Beads sample is done.
3. H2 left out of current reality. You doubt priority shifts go untracked often; the real gap may be communication and cross-tasking (Sylvie tasking Fae directly). I kept the L71 chain as written and put your doubt in transition as the need behind "trace the last pivots". Do you want a competing cause, "priority changes are not communicated", in current reality?
4. Root causes are provisional. "Tasks split", "Beads as notes", "priority untracked" and "site tabs" are marked root_cause only because the SCQ does not explain them further. Nothing yet links the four chains. Candidate deeper cause, which I did not assert: there is no agreed rule for where each kind of task lives and how it is written. It would join chains 1, 2 and 3, and matches H3. ✅ Overtaken by the 12 Oct meeting: r-e-no-rule is now asserted and joins the chains; see The shape, in one view and the candidate core causes in crt.md.
5. Goal tree: settled. Replaced the extracted goal view with the v4 tree agreed in chat, with necessary_for links (source: Rufus, not the SCQ).
6. Hypothesis checks as transition actions (sample 20 Beads, trace pivots, ask where to log, mock a page). Should they become Beads under lip-tqk.24?
7. Is ownership (air traffic controller) the central cause behind CSF2 and its NC? Rufus suggested it may be. ✅ Partly answered. Candidate core cause 2 in crt.md; injection weekly-plan-owners (Rufus and Uriel, Asdra as apprentice) in the future reality check.
8. Time pressure may be a general underlying cause beyond CSF3 (Rufus); linked only to the task split so far.
9. r-e-no-common-tooling overlaps r-e-no-plan-harness (round 1); merge?
10. Weekly follow-up (r-e-no-followup) is a delivery issue (Rufus), left unlinked.
11. r-e-no-system-of-record refines r-e-no-rule: merge them?
12. Several chains now converge on: no agreed rule / system of record; no planning owner; two teams in two tools; building while running. Candidate core problems for the next step. ✅ Taken up as the four candidate core causes in crt.md and summarised under The shape, in one view.
13. Trial owner and dates. ✅ Owner: Uriel (team, 12 Oct 2026), including the Asana side of the weekly sweep; Beads lip-tqk.25. Start date not yet set.
14. Build-vs-ship slot: owner and timing not set. Relates to the weekly-plan owner gap (CSF2); likely the same person. ✅ Owner: Rufus, for now (13 Oct 2026); Beads lip-tqk.26. Timing not set.
15. Where should reference material live: one place (Git Markdown, Rufus's preference) or Drive and Git? Not decided. ✅ Answer. Markdown in Git repositories on GitHub (Rufus, 13 Oct 2026).
16. How does the weekly sweep aggregate projects that live in initiative repos and Drive folders? Open. ✅ Answer. The planning portfolio must list all initiatives and initiative areas with their reference locations so they can be scanned; projects sit in a projects/ folder at each repo root, with status logged per docs/data-model.md.
17. Is priority-as-state needed at project level too, or only for initiatives? ✅ Answer. Both, meaning different things: initiatives carry absolute priority, set by Rufus and Uriel; projects carry priority relative within their initiative, set by the initiative owner; weekly plans only reference these.

Deliberately omitted

Validator output

Not machine-validated (no validator available here). Attach the file in the Reason Commons app; its import reports anything it refuses.

Not in this file

• Prerequisite view now exists (ten objectives, table above). Every step past an obstacle carries a Beads ID.
• Assumptions and assessments are on the clouds only: 10 assumptions (five on the tools cloud, one on the future-reality link f-asm-sweep-extends, four on build vs ship) and one assessment (c-as-bs-breaks). The SCQ itself states no beliefs under its links and does not claim a critical root cause. The tools cloud has no assessment: the team chose to test the injections.
• Open questions (2605 L103–120) are partly answered in the 12–13 Oct meetings: copy vs link into Asana (link, do not copy, injection 3); one structure owner vs AI editing (undecided, low weight, left for the trial); where reference material lives and how projects are aggregated (see judgment calls 15–16). The rest are not extracted.