Note: The first organizing move is that “dependency mapping” names two different activities that get conflated and that an IT PM will be asked for interchangeably. Delivery dependency mapping operates on work — tasks, approvals, teams — lives in a register, and expires at go-live. Service dependency mapping operates on things — applications, servers, network paths — lives in a CMDB, is discovered automatically, and never finishes. Don’t merge them: project rows pollute a system of record that change and incident management depend on. Join them at exactly one point, impact analysis.
Note: The second is that the category lists both sources give cannot tell you which dependencies to attack. PMBOK’s dependency determination can, because it sorts by what you can do: mandatory/discretionary × internal/external. Fast tracking is only available against discretionary links; attempting it against a mandatory one produces rework rather than compression. So the most valuable column in a register is the one the vendor templates omit — is this hard or soft, and who says so?
Note: The sharpest finding is that both sources recommend visualizations that are structurally incapable of showing the hardest dependencies. Gantt charts and network diagrams are directed acyclic graphs; real IT projects are full of cycles (the API team needs requirements, the requirements need the API contract). The Design Structure Matrix (Steward, 1981) exists for this and explicitly “represents feedback linkages that Gantt and PERT techniques cannot model” — partitioning localises coupled blocks on the diagonal rather than eliminating them, and tearing names which feedback link you’re assuming away. An N×N grid in a spreadsheet is enough; the point is that linear “what does this need?” discovery never closes the loop and so cannot find coupling at all.
Note: Three practical additions neither source makes. A dependency needs an owner on both ends — vendor templates have one owner field, which silently means the consumer, who cannot deliver the thing; SAFe’s program board gets this right by requiring a named owner at each end of every string. Record needed-by dates, not promised dates — the gap is your float, and a register of promises shows green until it doesn’t. Log blocked-days, which is the only number that turns the register into evidence and lets you Pareto it; if most blocked-days are organisational (approvals, budgets), the fix is a DACI with a named Approver, not harder scheduling.
Note: The page ends on Conway’s Law, because it reframes what the metric means. Most cross-team dependencies aren’t planning accidents — they’re the team topology showing through the architecture. Dependency mapping is symptom management for a structural problem, which is a good reason to do it and a bad reason to expect the count to fall. A rising count may be an accurate reading of an architecture that has outgrown its teams, and a steering group will otherwise read it as poor project control. This is also the tie to Brooks’s Law’s divisibility mechanism: a dependency map is an inventory of the constraints that don’t parallelise, so a dense one is the evidence that headcount won’t buy schedule.
Note: A “claims not to repeat” section was needed for this ingest. “Dependency hell” does not mean cascading failure — it is the package-version-conflict problem (cf. JAR hell, version skew), and EasyVista has repurposed a term of art; say it to engineers and they’ll think you mean a build problem. Gartner’s “$5,600 per minute” traces to a retired 2014 blog post, is presented undated as current, and Gartner itself noted it varies enormously. PMI’s 11.4% waste is real (Pulse 2020, revised to 9.4% in 2021) but the clause appended to it — “dependency blind spots are a primary contributor” — is not PMI’s finding; the unsupported causal claim is what does the persuading.
Note: Atlassian’s page contains a flat self-contradiction worth recording rather than quietly fixing. Having established the order water source → sprinklers → shrubs, the very next sentence says “the water source is dependent on installing sprinklers, and installing sprinklers is dependent on planting the shrubs” — exactly reversed. Direction is the entire content of a dependency statement. Two of its four relationship-type examples also illustrate a different relationship than the one they name. The definitions themselves are standard and correct, so the page is cited for those and the examples are flagged.
Note: The organizing move is that a Pareto chart’s mechanics are trivial and the two decisions that determine the answer are both made before you draw anything — what the categories are, and what you count in them. The page is mostly about those two. Run the same defect data by component, by defect type, by injection phase and by detection trigger and you get four different “vital few,” all correct, each implying a different fix; the component chart sends engineers somewhere, the injection-phase chart tells you whether sending engineers is the right response at all.
Note: Counting defects is the most common error and weighting is the fix. Raw count treats a cosmetic misalignment and a data-corruption bug as one unit each. A category tall by count and short by cost is noise to batch away; short by count and tall by cost is what will hurt you, and the count chart buries it. Corollary kept from the source: a Pareto chart allocates discretionary effort, so security, safety and regulatory defects come off the chart and onto a risk track first — a single auth bypass will never win a frequency contest.
Note: Juran’s 1974/1975 mea culpa is the find of this ingest and reframes the whole tool. Pareto studied wealth and never generalised; the generalisation was Juran’s own (“To my knowledge, the first exposition was by myself”), and the cumulative curve “should have been properly identified with Lorenz.” So the standard Pareto chart is a Juran principle drawn on a Lorenz curve. The Kaizen source commits exactly the attribution error the essay exists to stop, which is why it is kept as a specimen of it.
Note: The correction that actually changes practice is the other one in Juran’s list — “vital few and trivial many” was later changed to the “useful many.” Not a euphemism: “trivial” licenses closing the tail unfixed, “useful” says the tail is your next reliability tier once the top three are done. Almost every retelling keeps “vital few” and drops the correction. Also worth having: what Juran first observed in the mid-1920s was a sorted defect list, so defect analysis isn’t an application of the Pareto chart, it’s where the chart came from.
Note: The empirical software literature says concentration is real but adds two qualifications the quality-tool literature never mentions, because it is written about manufacturing. Fenton & Ohlsson (2000) found no support for the widely repeated link between module size and fault density, and none for complexity metrics predicting fault-proneness — so the tempting shortcut of ranking modules by size instead of observed defects is unsupported. And their counter-intuitive result should stop anyone: modules most fault-prone pre-release are among the least fault-prone post-release, and vice versa. A pre-release defect Pareto is a report on your test coverage, not on your software; only a production chart is the latter. The page says build both and never use the first to predict the second.
Note: Orthogonal Defect Classification (Chillarege et al., IBM, 1992) is the answer to teams inventing defect categories in a workshop, and two of its ideas transfer even if the taxonomy doesn’t. The defect-type distribution should shift across phases, so a system still throwing Function/Class/Object defects in UAT is not late in its lifecycle whatever the plan says — the most useful thing on the page for anyone running a stage gate. And ODC’s trigger is separate from type: type measures the product, trigger measures the verification process, and only a trigger chart tells you which test activities are earning their keep.
Note: Two failure modes worth keeping. A flat chart is a result, not a failed chart — it means the defects genuinely are diffuse and the process is the problem; re-cutting categories until a spike appears is manufacturing the answer. And the distribution moves because you acted: fix the top category and number two becomes number one without having got worse, so track the absolute height of bars over time, never the ranking, which is designed to always show you a problem.
Note: Cross-linked three ways rather than left as an orphan. Closing the Loop on Metrics is the natural continuation — a nightly-recomputed defect Pareto is a control-band metric and “top bar exceeded its band” is a trigger. The chart identifies the vital few but does not decide what to do about them, which makes “refactor payments, defer the backlog” a DACI rather than a RACI row, with the chart sitting in the decision document’s Relevant data section. And Brooks’s Law’s ~500% defect tail is the case where a Pareto rises across the board rather than concentrating, and no category on the chart names the cause.
Note: The honest-evidence section is long again. Fenton & Ohlsson and the ODC paper are both IEEE-paywalled and read only through the abstract and secondary restatements — the page deliberately does not state the commonly quoted 20%/60% figures, since they were not verified. The Ballmer 80/20 and 1%/50% ratios are executive statements about internal Microsoft data with no published audit. No standard was read for the chart itself. And nothing cited establishes that using Pareto charts improves outcomes — only that software defects are concentrated, which is a precondition for the tool being useful, not a demonstration that it works.
Note: The organizing move is that RACI and DACI are not competing frameworks but different units of analysis. RACI’s unit is a work package and it is a living matrix; DACI’s unit is one question and it is a record that stops changing once decided. The maintenance disciplines are opposite — a RACI unchanged for three months is suspect, a DACI unchanged since decision is working correctly — which is the cleanest evidence they are not substitutes. The practical consequence is that most IT projects should run both, which is also what the source articles conclude, though without the argument for why.
Note: The sharpest single finding is that RACI has no cell for “who chooses between options.” Its four letters describe relationships to work; none describes a relationship to a choice. The instinct is to reach for Accountable, but A means answerable for a deliverable being done correctly, which is a different act from selecting among options before anything exists. That conflation is how the person who signs off the integration test report ends up deciding the integration architecture by default. The whole decision-roles literature — RAPID, DACI, DARE — exists to fill that one gap.
Note: Atlassian’s DACI page carries an uncited statistic that could not be traced, and chasing it produced the most useful correction in this ingest. The page’s entire evidence section is one sentence: “A survey conducted by McKinsey & Company found that projects utilizing the DACI framework have a 25% higher success rate.” No link, no date, no study name, and every downstream page repeating it is downstream of Atlassian. McKinsey’s actual publications on this family never mention DACI — the 2022 post recommends DARE (deciders, advisors, recommenders, execution stakeholders) and closes “don’t use RACI.” The likeliest reading is a DARE/DACI conflation plus an invented number; the pages say so and label the inference as this wiki’s, not a documented correction.
Correction during drafting: a search summary asserted McKinsey “recommends the DACI framework,” which would have put a false claim on three pages. Fetching the actual article showed the framework is DARE, a different thing. The episode is the same failure mode the Agents vs. Workflows page documents — a summarizer collapsing one framework into a better-known neighbour — met twice now, and it is why these pages quote primary text rather than summaries of it.
Note: The DACI origin story is folklore. Every secondary guide says Intuit, 1980s, uncited; Atlassian — the actual populariser and maintainer of the canonical description — does not mention Intuit anywhere. Reported on the page as circulating claim, not history. RACI’s origin is genuinely unsettled too: the RAM concept is traceable to Wadsworth (1972) and a 1977 acronym dictionary listing “RAM — Responsibility Assignment Matrix [NASA]”, but nobody has identified who fixed the four-letter scheme.
Note: The column-and-row analysis is the part of RACI that makes it worth maintaining, and neither source article mentions it at all. Reading down a column finds bottlenecks (too many A’s) and single points of failure (no blank cells); reading across a row finds work that will not happen (no R), work nobody answers for (no A), deadlock (two A’s) and invented committees (a wall of C’s). Without that pass a RACI is decoration, which is most of why it has the reputation it has.
Note: The pages are pitched at an IT project manager, so they carry the governance-framework angle the general PM literature omits: COBIT 2019 ships RACI charts for all 231 practices across its 40 objectives, and ISACA’s own framing is that Responsible and Accountable are given while Consulted and Informed are yours to tailor — a reference position, not a control to comply with. ITIL popularised RACI as the “authority matrix,” but ITIL 4 has no official RACI matrix, which surprises teams migrating from v3. The practical consequence is that the same person routinely sits in three responsibility models at once, and the project/service clash surfaces at handover.
Note: Both project-management.com articles are kept in references/ as specimens rather than authorities, the second time this wiki has done that. They earn it: the operational checklists and the named practitioner quotes are real contributions, and the DACI article contains a perfect worked example of the corruption the comparison page exists to prevent — having defined DACI as a decision framework, it prints a chart of D/A/C/I letters across recurring tasks, which is RACI with the letters relabelled. The diagnostic is now on the page: if your DACI has rows, it is a RACI.
Note: All three pages close with an honest evidence disclaimer, because there is less here than the confident tone in circulation suggests. No controlled study of either framework was found. RACI’s benefits circulate as practitioner testimony in monetised trade press; DACI’s single quantified claim is the untraceable one above. PMBOK, COBIT, ITIL 4 and ISO 21502 are all paywalled and none was read directly. Both are plausible mechanisms with long practical track records, and neither is a measured effect.
Note: The organizing move is that the workflow/agent line is about who decides what happens next, not about how adaptable the system is. Adaptability is the symptom; the criterion is whether control flow is readable in the source before the system runs. That framing is what makes the line checkable — and it is exactly what the analogy-first restatements (“a chef” vs. “a recipe”) lose.
Note: The post is kept in references/ as a specimen rather than an authority, which is a first for this wiki. Two findings justified the page rather than a decline: it attributes Anthropic’s agent definition — verbatim, word for word — to LangChain, one hop having erased the origin; and its nine citations contain no primary source at all (seven blogs, one vendor doc, and a link to Mermaid’s live editor). The schema’s “prefer the normative source over any summary” rule has a worked example now.
Note: The casualty of summarization is consistent and worth naming: what gets cut is Anthropic’s actual top-line advice, which is to build neither — “this might mean not building agentic systems at all,” since “optimizing single LLM calls with retrieval and in-context examples is usually enough.” Google Cloud’s pattern catalog reaches the same conclusion independently. Two vendors with agent products both leading with “you probably don’t need this” is the strongest agreement in this literature and the first thing a summary drops.
Note: The pattern taxonomies nearly but don’t quite line up. Anthropic files orchestrator-workers under workflows; Google Cloud files the equivalent Coordinator under model-orchestrated. Same architecture, classified differently depending on whether you weigh the predefined scaffold or the runtime routing decision — which is the most interesting edge case in the distinction, and the page says so rather than smoothing it over. Routing has no Google Cloud equivalent at all.
Note: The Anthropic post now carries a publisher’s note that its tooling landscape has changed since December 2024, pointing at Claude Managed Agents. The definitions and patterns aren’t what changed, but the page flags that it is built on a partially superseded document, and that the framework advice should be read as of its date.
Deprecation: Removed program-vs-project-management.md at the user’s request, along with its root index.md entry. Brooks’s Law keeps the point its “Where this connects” paragraph was making — that the trim-scope-or-move-the-date call belongs to whoever owns the benefit case — but no longer links out to it. The three reference excerpts the page was built from (GovS 002, NASA NPR 7120.5F, OMB M-18-19) stay in references/ — that layer is immutable — but no concept page cites them now. Earlier log entries still link the deleted path; they are left as written, since the log is a record of what happened.
Ingest: Created Brooks’s Law — the second page in the program/product strand, and the first one built from a live question rather than a source drop: what to cite when someone proposes fixing a late project with headcount. Added two reference excerpts, McConnell’s “Brooks’ Law Repealed?” (IEEE Software, 1999) and Farshchi et al. on personnel factors (ComSIS, 2012). Catalogued in the root index.md and references/index.md.
Note: The organizing move is to read the law as an attack on a unit of measurement rather than as a prohibition. The essay is called “The Mythical Man-Month” and the myth is the man-month — the assumption that people and time are interchangeable inputs, which is exactly what an FTE-based capacity model encodes. Framed that way, the law stops being folklore to recite and becomes a statement about why capacity plans mis-price schedule.
Note: Two mechanisms beyond Brooks’s original three are worth having. Gren (CHASE 2017) argues a team regresses down its group-development stages when members are added, forcing rework of norms, goals and roles — this fires even when the new hire is excellent, which is what disposes of “but we got a strong contractor.” And QSM’s data supplies a defect tail: heavier staffing bought ~30% schedule at ~350% cost and ~500% more testing defects, landing the extra work precisely in the phase a late project is already stuck in.
Note: The most operationally useful result found anywhere in this literature is Stutzke’s pair of conditions — r > a (remaining time exceeds effective assimilation time) and f < 1/m (fractional staff increase below the reciprocal of per-hire mentoring cost). The second is a cliff-marker rather than a target: at m = 0.25, f = 4 consumes the entire existing team in mentoring. The page says so, because the inequality invites being read as permission.
Note: COCOMO II’s SCED cost driver is the cleanest quantification of the capacity-planning error, and its rating scale bottoms out at 75% of nominal — the model declines to price compression beyond 25%. Better still is its stated mechanism: “Accelerated schedules tend to produce more effort in the later phases of development.” That is the late-project case exactly. Verified against the USC manual directly; the widely-quoted 1.43 multiplier is from the COCOMO II.2000 recalibration and is not in that manual’s rating summary, so the page flags it rather than asserting it.
Note: “Why managers do it anyway” is treated as a real question rather than a lapse, and the answer is mostly structural: headcount is often the only lever a delivery manager controls unilaterally, and escalation of commitment (Flyvbjerg’s bias #10) does the rest. Flyvbjerg’s “Cognitive bias is half the story; political bias the other half” is the line that explains why exhortation doesn’t fix it. McConnell’s charitable reading is kept alongside: managers mostly can’t tell whether they are inside the law’s window, and on chaotic projects they guess wrong in the direction that would have made adding people correct.
Note: Both new reference files are quotation excerpts, not mirrors, matching how the paywalled and rights-restricted sources were handled in the previous ingest. McConnell’s column is IEEE/McConnell copyright, its original URL 404s, and the live site is behind a bot challenge — the canonical copy is now an Internet Archive capture, which is the whole argument for keeping an excerpt locally. Farshchi et al. is open access but CC BY-ND, and its equations and figures are graphics that didn’t survive PDF extraction, so the file says plainly that the canonical PDF wins.
Note: Cross-linked in both directions rather than left as an orphan. Program Management vs. Project Management gains a paragraph on staffing as a project-level lever forcing a benefits-level decision; Parallel Sessions and Subagents gains the observation that its review-capacity ceiling is Brooks’s third mechanism — agents remove the ramp-up term but not the divisibility one, so the ceiling moved rather than disappeared. That second link is the first real load-bearing connection between the AI strand and the program-management strand, which is what the scope note added yesterday said these pages were for.
Note: The page ends with an unusually long “what this page can’t reach,” because the evidence here is thinner than its confident tone in circulation suggests. Stutzke (1994) has no free copy and is used only through others’ restatements; Cole (1995), the source of the “about half of runaway-project managers added staff” figure, isn’t online at all; QSM’s database is proprietary and sold alongside the estimation tools it supports. The quantitative base is system-dynamics simulation and vendor data, not controlled field study, and nearly all of it predates distributed teams and agentic tooling.
2026-09-15
Scope: The wiki now covers three subjects rather than one — LLMs/AI, technical program management, and technical product management, all first-class. Recorded in CLAUDE.md under a new “Scope” section and in the root index.md intro. The repo name predates the change and shouldn’t be read as a scope statement. The same section sets the bar the new material has to clear, because the PM literature needs it more than the AI literature does: standards, peer-reviewed papers, recognized books, primary vendor documentation — and none of the derivative layer of listicles restating standards nobody links to. It also says explicitly that pages should cross-link across the three subjects rather than staying in their lane.
Ingest: Added three sources on the program/project distinction that can be mirrored rather than merely linked — GovS 002: Project delivery (UK Cabinet Office, v2.1, Crown copyright under the Open Government Licence), NASA NPR 7120.5F, and OMB M-18-19 implementing the PMIAA (both US federal works, not subject to domestic copyright). All three are excerpts rather than verbatim copies — the definitional sections only, out of documents running 20 to 60 pages. Created Program Management vs. Project Management, catalogued under a new “Program and product management” section in the root index.md.
Note: The page is deliberately built from free sources only, at the user’s direction, after a first version leaned on paywalled standards and journal articles that couldn’t be mirrored or checked. That constraint turned out to cost less than expected, because the single most complete treatment of the question — the Praxis Framework, an integrated body of knowledge, methodology, competency framework and maturity model covering all three of project, programme and portfolio — is free to read in full. The page closes with an explicit “what this page can’t reach” section naming the paywalled standards and papers, so the gaps are visible rather than silently absent.
Note: The organizing claim is that the discriminator is neither size nor project count. A project is a bounded management environment accountable for meeting requirements; a programme is a deliberately flexible organisation accountable for benefits no single component produces. Praxis supplies the sharpest operational form of this, and it is three conditions checkable against a requirements document before anyone argues about org charts: multiple benefits, more than one area of business change, multiple outputs. APM supplies the other half — a programme contains business-as-usual work that is not a project at all, so capability embedding has nowhere else to live.
Note: Praxis’s underlying position differs from every other source here and is worth keeping distinct: it holds that the dividing lines are blurred, and that project, programme and portfolio are points on a continuum described by the complexity of the work. PMI and GovS 002 draw categorical boxes instead. The page records both rather than harmonizing them.
Note: NASA’s four program types — single-project, uncoupled, loosely coupled, tightly coupled, each with a worked example — are the most useful taxonomy found anywhere in this ingest, free or paid, and are almost never cited in general PM discussion. They also contradict PMI’s “related projects” phrasing by explicitly permitting a single-project program, which reframes “program” as a governance choice rather than a claim about scale.
Note: Artto et al. (2009) remains the empirical spine, and is the one research paper here freely readable in full. The deepest row of its eleven-characteristic table is object: for programs it is change of the permanent organization, for projects the permanent organization is taken as given. That reverses which one is the variable, and it is why programme governance can’t be project governance with a bigger board. Their conclusion — programs “cannot and should not be treated as scale-ups of projects” — rests on 517 program and 1,164 project articles.
Note: The gap this page is most exposed on is recorded on the page itself: Lycett et al. (2004) is paywalled, and its finding that standard programme approaches worsen the strategy/delivery tension they exist to resolve has no free equivalent. Without it the page reads more approvingly of the standards than the literature warrants, and it says so.
Note: OMB M-18-19 earns its own reference file purely as evidence for the terminology trap. Its federal definition of “program” — “the mission, functions, projects, activities, laws, rules, and regulations which an agency is authorized and funded by statute to administer and enforce” — is a permanent entity defined by statutory authority, the opposite of GovS 002’s temporary flexible organisation. Same word, opposite properties on the attribute that matters most. The memo scopes its own terms to “PMIAA implementation and guidance only,” which is the tell.
Note: Added Standard to the type list in CLAUDE.md, with the boundary against Paper and Comparison spelled out — now that normative documents are in scope, GovS 002, NPR 7120.5 and the ISO 21500 family are each plausible pages of their own. This page is a Comparison: it exists to hold two things apart.
Note: Two sources resisted direct fetching and the page flags both rather than hiding it. praxisframework.org sits behind a bot challenge, so its passages were read through search indexing and the footnote says to confirm wording in a browser before quoting. pmi.org blocks automated fetches, so its free learning library went unread; the free Lexicon PDF downloads fine and is what the PMI definitions here come from.
Fix: The publish commands in CLAUDE.md pointed at ~/Codebase/tech-llm-wiki and ~/Codebase/ismailkhan.xyz, neither of which exists — both repos now live under ~/codebase/ismailkhan/. All six occurrences corrected. The rsync in step 2 has --delete, so the stale path was a live hazard rather than a cosmetic one.
2026-09-09
Update: Rewrote all five GAIL module pages — Module 1, Module 2, Module 3, Module 4, and Module 5 — from telegraphic bullet outlines into prose study notes. They were compressed to the point of losing comprehension: 5,748 words against 14,062 words of slide transcription, with every term reduced to an appositive fragment (**Grounding** — anchoring responses in specific data) that names a concept without explaining its mechanism or the problem it solves. Now 13,146 words, still under the source. index.md needed no change — the frontmatter description fields are unchanged.
Note: The rewrite follows one template, capped to prevent the opposite failure. Each ## opens with a sentence or two of framing; each term gets definition → mechanism → one italic example, and no more; comparison tables stay. Deliberate additions: a “Don’t confuse these” block wherever the deck puts confusable terms side by side (foundation models vs. LLMs, Top K vs. Top P, Saved Info vs. Gems, agents vs. applications, CoT vs. ReAct), and an explicit sorting rule where the slides only imply one — augmentation vs. automation turns on whether a human still exercises judgment on the output; ReAct vs. CoT on whether the task needs information the model doesn’t already have.
Note: The slides’ concrete examples had been stripped out in the original pass and are now restored — the four multimodal pairings, the four augmentation/automation scenarios with their reasoning, the floral creative-matrix mappings, the edge-vs-cloud activity, the garden-consultation tool cycle. Examples are what make a term stick, and dropping them was most of why these pages read as reference cards rather than notes.
Note: Each page’s orphan “quiz-derived facts” section is gone, dissolved into inline > **Exam note:** blocks beside the concept each one tests. Module 4 keeps a caveat at the top that its answers are inferred rather than verbatim-confirmed: that deck’s answer slides marked correct options graphically and the highlighting didn’t survive text extraction. The other four modules’ quiz answers are in their transcriptions as text.
Note: Concepts appearing in several modules are now explained once at their deepest treatment and recapped with a link elsewhere, rather than re-explained three times — RAG and the reasoning frameworks in Module 5, grounding in Module 2, prompting techniques in Module 4. Module 5 is the longest page (3,131 words) because it absorbed that weight.
2026-09-08
Update: Added the course’s three figures to The AI-Native SDLC as Excalidraw sources — the moved bottleneck, line versus loop, and the play dependency graph. Like the MCP hub diagram and the twelve pattern figures these are replications of source figures rather than original arguments, which Diagrams/index.md records; redrawn in stock Excalidraw colors (blue for the stages, orange for the build phase that collapses and for the no-prerequisite plays, grey dashed for reclaimed time and for “helps, not required”) so they theme-adapt on the site the way the earlier diagrams do — the originals’ charcoal-and-terracotta would not.
Fix: Repaired nine dead links in the 2026-09-01 and 2026-09-02 entries below, left behind when the GAIL pages moved and were consolidated. The five module links now point at their current homes under Google GAIL/; google-GAIL.md and google-GAIL-cert.md no longer exist at all, so those references are now plain filenames rather than links to nothing.
Note: The organizing claim worth keeping is the committed artifact chain — intent.md → spec.md → plan.md → the diff and its tests → the PR and its findings → the incident record → the next intent.md. Each stage ends by writing a file to version control and the next begins by reading it, which is what lets the playbook argue the old control objectives survive under new enforcement: the chain of commits is the audit trail. It is context engineering applied to a process rather than a session.
Note: The distinction the playbook is most careful about, and the one that reframes Agent Skills as governance rather than productivity tooling: a skill is an advisory control and a hook is a deterministic one. A skill makes Claude likely to apply a policy while the code is written; nothing forces a session to comply. A policy that must always hold needs a hook behind it — the skill makes violations rare, the hook makes them close to impossible. Recorded on both the skills play and the hooks play.
Note: The hooks play carries the course’s fullest artifact, a managed-settings file for a regulated enterprise, annotated key by key. Two points there are easy to miss and worth flagging: sandbox and permissions.deny enforce one objective at two layers (a tool-level deny on WebFetch doesn’t stop a shell command reaching the network, and credentials covers what the file-tool deny rules miss for ~/.ssh and ~/.aws/credentials); and allowManagedHooksOnly silently invalidates the repo-level .claude/settings.json gate the same lesson shows first, so the gate has to be redefined in the managed file’s own hooks block.
Note: Three pages record the playbook’s own framing against the agentic design patterns vocabulary already in the wiki. Parallel Claude Code sessions are not a multi-agent system — no orchestrator, and the human is the only shared state — while subagents are the parallel pattern with context isolation as the point. The feedback loop is iterative refinement with a deterministic evaluator rather than a model as judge. The sigma tier ladder in closing the loop is human-in-the-loop expressed as a threshold, with autonomy granted in proportion to how far the metric has moved.
Note: Two caveats recorded on the overview. This is a vendor’s playbook for its own tools, and its value is the specificity rather than the thesis. And its measurement guidance is mostly proxy metrics readable from systems that already exist (Git timestamps, PR metadata, CI check runs, the OpenTelemetry export) — the leading indicators largely measure cycle time, and only the lagging ones (rework rate, change failure rate, escaped defects, DORA) speak to outcomes.
Note: The plan mode play holds the course’s only sustained treatment of legacy systems, which is the part most likely to matter in an enterprise adoption: for each artifact, name one system the source of truth and let the others hold a copy or a link, with the choice differing per artifact. The three configurations are the repo as truth, the legacy system as truth (Claude reading and writing back through an MCP connector in the same session), and linkage — record ID in the artifact, commit SHA in the record — as the transitional minimum.
Note: No diagrams yet. The course carries three figures (the moved bottleneck, line versus loop, and the play dependency graph); the reference file points at them by URL rather than embedding copies.
Note: Redrawn from the source images in stock Excalidraw colors (blue for the driving agent, green for the coordinator and success paths, red for rejection, pastel panels for the grouped regions), so they theme-adapt on the site the way the earlier diagrams do — the originals’ flat white-and-blue would not.
Ingest: Added five sources on Agent Skills — Anthropic’s Agent Skills overview and Skill authoring best practices, the Claude Code skills documentation, and agentskills.io’s specification and best practices for skill creators — all captured verbatim from the markdown source each docs site serves at the same path with a .md suffix. Created Agent Skills (what a skill is, the three levels of progressive disclosure, the open SKILL.md spec, and Claude Code’s discovery rules, extended frontmatter, invocation control, and context budgets) and Agent Skills Best Practices (sourcing, conciseness, scoping, calibrating control, discovery, structure, instruction patterns, executable code, and evaluation-driven iteration). Both catalogued under a new “Agent skills” section in the root index.md.
Note: The user asked for the overview page from Anthropic’s docs alone; the spec and the Claude Code skills page were added because that page can’t answer “the standard specification and organization for Claude Code users” on its own — the overview gives the two required frontmatter fields and the two skills directories, while the field constraints, the scripts//references//assets/ conventions, and the precedence and naming rules live in the other two.
Note: The two best-practice sources overlap heavily but split on one thing worth keeping: agentskills.io names the sourcing failure Anthropic’s guide assumes away — a skill generated by an LLM with no domain context reproduces what the reading agent already knows, and so earns nothing. Its “gotchas section” framing (environment facts that defy reasonable assumptions, kept in SKILL.md because the agent won’t know to go looking for a trap it doesn’t know exists) has no equivalent in Anthropic’s guide.
Note: Recorded the portability trap on Agent Skills: Claude Code accepts roughly twenty frontmatter fields, but claude.ai uploads, the Skills API, and package_skill.py accept only the spec’s six and fail with a hard Unexpected key(s) error rather than ignoring the rest. Skills written to the spec run in Claude Code unchanged; skills written to Claude Code’s full field set don’t travel. Also noted that workspace trust doesn’t gate a project skill’s allowed-tools, so a skill checked into a repository can grant itself broad tool access on a -p run in an untrusted folder.
Fix: Pinned the meaning of “bundle” in CLAUDE.md — it means this repo, always, and is never nested. A category folder like Agentic Design Patterns/ is a folder, not “the X bundle,” even though it carries its own index.md; only the root declares okf_version, which is what makes it the bundle root. The word is now reserved for places where OKF structure is the subject, with “in this wiki” the wording for ordinary cross-references on concept pages. Corrected the two slips that prompted this: the 2026-09-06 ingest entry below called Agentic Design Patterns/ a “bundle,” and Single-Agent Pattern said “everything else in this bundle” where it meant the other patterns — ambiguous anywhere, and especially so on a page that lives inside a subdirectory. Context Engineering reworded to match.
Ingest: Added the MCP documentation’s intro and architecture overview (both version 2026-07-28) to references/, and created Model Context Protocol (MCP) — the gap flagged in the A2A ingest, since three pages were already leaning on MCP without one of their own. Covers the USB-C framing from the intro plus the architecture’s core concepts: participants (host/client/server, one client per server), the data and transport layers, statelessness and server/discover, the server primitives (tools, resources, prompts) and client primitive (elicitation), and opt-in notifications. Cross-linked from A2A and Context Engineering, which now point at a real page instead of naming MCP in passing.
Note: The captured docs are version 2026-07-28, which differs from widely circulated accounts of MCP in ways the page flags explicitly: the protocol is now stateless (every request carries its version and capabilities in _meta, with server/discover replacing the initialize handshake), and the sampling and logging client primitives are deprecated — elicitation is the only client primitive left. Worth re-checking against the spec before relying on any older MCP summary.
Update: Added a replication of the official MCP hub diagram to the MCP page — AI applications left, data sources and tools right, bidirectional flow through one protocol in the middle. Unlike the other diagrams in this bundle it reproduces a source figure rather than making its own argument, which is recorded in Diagrams/index.md so the distinction stays visible. Redrawn in stock Excalidraw colors so it adapts to the site’s dark mode.
Correction: The context-engineering page credits Tobi Lütke with proposing the term on 2025-06-19, not Karpathy. Karpathy’s much-cited post six days later is a quote-tweet opening “+1 for ‘context engineering’ over ‘prompt engineering’” — he seconded it and supplied the definition that stuck, but the coinage isn’t his. Both posts are captured in one reference file because the coinage and the endorsement are a single unit of provenance. Also noted the half of Karpathy’s post that usually gets dropped in quotation: context engineering is “just one small piece” of the software layer around LLM calls, alongside control flow, model dispatch, guardrails, and evals.
Update: Recorded the convergence between Anthropic’s long-horizon techniques and the context-engineering vocabulary already on Multi-Agent Systems from Google Cloud’s guidance — sub-agents/isolating, note-taking/persisting, compaction/compressing are the same triad reached independently by two sources.
Note: The prompt engineering page deliberately does not carry status: deprecated. The sources don’t support it, and OKF status describes the document’s lifecycle rather than the subject’s. The page instead separates three things that are usually collapsed: the job title (effectively obsolete, per the WSJ via Wikipedia), the term as the name of the discipline (superseded by context engineering), and the practice itself (alive, and a component of context engineering — Anthropic’s own guidance still devotes sections to system prompts and few-shot examples). What actually eroded is manual trial-and-error prompt tinkering for everyday tasks; automated prompt optimization and prompt-injection defense are both growing.
2026-09-06
Ingest: Added the A2A protocol’s own “What is A2A?” to references/ as a verbatim capture, and wrote A2A (Agent2Agent) Protocol from it — the problems A2A solves, its position beside MCP in the agent stack, the five design principles, and the four-step request lifecycle. Introduced Protocol as an OKF type and recorded it in CLAUDE.md; opened a “Protocols” section in the root index.md to hold it. Cross-linked it to Multi-Agent Systems, the coordinator pattern — the trip-planning example is that pattern with the specialists in other organizations — and GAIL Module 5, whose three agent components (model, tools, reasoning loop) the A2A stack extends with a layer that framing has no name for. The page argues that A2A’s real subject is organizational boundaries rather than architectural ones; MCP has no page of its own yet, which is now the most obvious gap in this bundle.
Update: Added a diagram to A2A (Agent2Agent) Protocol carrying the page’s three arguments on one canvas. It leads with the comparison the source only makes in prose — an agent squeezed through a tool interface, with what that discards named in red, beside two agents holding a multi-turn exchange. The center makes MCP and A2A perpendicular: down to stateless tools, across a dashed organizational boundary to peer agents. The right column runs the lifecycle as a timeline with the real spec surface (the agent card fields, securitySchemes → JWT, sendMessage, and the SSE event sequence), and the agent-stack summary sits under it. The card artifact shows only fields the source actually names, rather than an invented JSON payload.
Update: Added a diagram to Choosing an Agentic Design Pattern mapping all twelve patterns at once. It argues the taxonomy rather than listing it: the patterns sit along a single axis — whether code or a model decides what runs next — hue encodes which family a pattern belongs to, and each pattern is drawn as the shape of its own architecture (chain, fan, cycle, tree, mesh, gate, branch), so the glyphs alone carry the structure. Every pattern carries a one-line “use when”, the loop and swarm carry their failure mode, and the source’s one explicit recommendation — start with a single agent — is the diagram’s only hero element.
Update: Gave each of the twelve pattern pages its own glyph image, cropped from that same map — _attachments/<pattern>.jpg, embedded above the first section with a [!diagram] callout back to the shared source. The crops aren’t pixel-cut from the PNG; each one is rendered natively from just that pattern’s elements in Diagrams/choosing-a-pattern.excalidraw, so they stay sharp and the master file remains the single source for all thirteen images. Edit the map and the crops need re-exporting.
Update: Split the consolidated google-GAIL.md back out into a Google GAIL/ folder, one file per module — Module 1, Module 2, Module 3, Module 4, Module 5 — with its own index.md cataloguing them. Dropped the certification-overview content (what the cert is, exam format, course objectives, study-resource links) that previously sat before Module 1, since it wasn’t pulling its weight as study material. Root index.md’s Certifications section now lists all five modules directly instead of the one consolidated page.
2026-09-02
Fix: Removed the leading # Title H1 from The LLM Wiki Pattern, Open Knowledge Format (OKF), Wiki Operations, Operating This Wiki, and the since-removed google-GAIL.md — the site’s article-title component already renders frontmatter title as the page H1 above the properties box, so every one of these was rendering its title twice. index.md and log.md were already clean. Added a rule to CLAUDE.md (next to the frontmatter block, and in the log.md section) so future pages don’t reintroduce this, and fixed CLAUDE.md’s own log.md template example, which still showed the offending # Wiki Update Log line.
Update: Added a “Type examples” subsection to Open Knowledge Format (OKF)‘s Design principles — the blog’s illustrative type list (table, dataset, metric, playbook, runbook, API) and its point that type isn’t a closed enum (the worked example uses a producer-defined BigQuery Table, not generic Table). Filled a gap rather than creating a new page for it, after weighing a separate “types” note against extending this one.
Update: Consolidated the six GAIL certification pages (overview + five module study guides) into a single page, google-GAIL.md. The six separate google-GAIL-*.md files are removed; all content now lives under ##/###-nested module sections on one page, with the same five source citations. Root index.md updated to link the one consolidated page instead of six.
Ingest: Added the five Google Cloud “Generative AI Leader (ILT)” course slide decks as sources (references/genai-leader-module-1-slides.md through module-5-slides.md, transcribed from the official PDFs). Created bullet-point study guides for each module — Module 1, Module 2, Module 3, Module 4, Module 5 — plus an overview page, google-GAIL-cert.md, with exam format and study-resource links. All marked status: draft; quiz answers in the source decks weren’t visually distinguishable after text extraction, so several were inferred from context rather than confirmed. Catalogued in the new “Certifications” section of the root index.md.
Update: Corrected Diagrams/ to hold only .excalidraw sources — no images. Moved llm-wiki-pattern.png out to a new _attachments/ folder, the wiki’s general home for every image going forward. Added Diagrams/index.md cataloguing each source and the note it belongs to. CLAUDE.md and README.md updated accordingly.
Update: Standardized how concept pages link to their diagram’s interactive version — a [!diagram] callout under the PNG, not a plain prose sentence or a link wrapped around the image. ismailkhan.xyz now defines a custom diagram callout type (quartz/styles/callouts.scss) with its own icon and color. The LLM Wiki Pattern uses the new pattern; CLAUDE.md documents it as the rule for every future diagram.
Update: Moved the diagram source and its PNG from the repo root and attachments/ into a new Diagrams/ folder — the one standing exception to the flat directory layout. The Excalidraw plugin has no frontmatter hook to hide individual diagram pages from the site’s Explorer sidebar, so grouping every diagram under one directory keeps the sidebar to a single collapsible “Diagrams” entry instead of one flat item per drawing. The LLM Wiki Pattern now embeds its PNG wrapped in a link to the .excalidraw file, so clicking the image opens the interactive, pan-and-zoom version directly.
Update: Added a diagram to The LLM Wiki Pattern, arguing the note’s central inversion visually — retrieval-only does its work after every question, the wiki compiles once at ingest. The Excalidraw source lives beside the note and publishes as an interactive, pan-and-zoom page; the PNG in attachments/ is the inline figure. Diagrams are authored with the excalidraw-diagram skill under .claude/, whose palette is restricted to Excalidraw’s stock colors so drawings adapt to the site’s dark mode.
2026-09-01
Update: Brought references/ documents into OKF §11 conformance — both source files had HTML comment headers instead of YAML frontmatter, which §11.1 requires of every non-reserved .md file. They now carry type: Reference plus resource, author, fidelity, and retrieved.
Creation: Added Operating This Wiki, the operator’s manual for this bundle — layer ownership, the prompts that drive each operation, the frontmatter fields in use, and the path from a push to the published site.
Update: log.md is now published to the site alongside the concept pages, and carries frontmatter so it renders with a real title. OKF §8 forbids frontmatter on index.md; §9 sets no such rule for log.md.