Skip to content
pentaglyph

PEL — Project Engagement Layer (binder)

PEL (Project Engagement Layer) is pentaglyph’s sixth slot — but unlike slots 1-5, it is not a peer standard. It is a binder that composes eight well-known client-engagement primitives into one local home, so consulting / advisory practices can keep client-facing artefacts alongside their technical docs.

What it composesEight client-engagement primitives (see below)
Why a binder, not a standardThe client-engagement space has no single canonical framework — composing existing primitives is more honest than inventing a sixth peer
Local home in the kittemplate/docs/client-engagement/
Slot in pentaglyph#6 (binder) — not a peer standard

What problem does PEL solve?

Section titled “What problem does PEL solve?”

Consulting and advisory practices need to produce client-facing artefacts that don’t fit cleanly into engineering docs:

  • Inception decks for kick-offs.
  • Weekly status updates for steering committees.
  • One-page status reports for executive sponsors.
  • Decision documents for RACI / DACI sign-off.
  • RAID logs (Risks, Assumptions, Issues, Dependencies).
  • Press-release-style product announcements (Amazon-style PR-FAQ).

These artefacts have well-known primitives — each with its own canonical source — but no single industry standard covers all of them. PEL gives them a shared local directory without inventing a new framework.

The eight composed primitives

Section titled “The eight composed primitives”
PrimitiveOriginUse
Inception DeckJonathan Rasmusson, The Agile Samurai (2010)10-slide project kick-off
GitLab Handbook weekly updateGitLab HandbookPublic weekly progress + blockers
Atlassian weekly statusAtlassian Team PlaybookInternal team weekly status template
Basecamp HeartbeatBasecamp / 37signalsAsynchronous milestone update
Amazon 6-pagerAmazon internal practice (Bezos 2004 memo)Six-page narrative document for decision meetings (replaces slides)
Now-Next-Later roadmapProdPad / Janna BastowGoal-based roadmap without dates
DACI decision documentAtlassian Team PlaybookDriver / Approver / Contributor / Informed — group decision template
RAID logPMI / PRINCE2 practiceRisks / Assumptions / Issues / Dependencies tracker
PR-FAQAmazon working-backwards methodPress release + FAQ written before building the product

(Nine items in the table because PR-FAQ and 6-pager are sometimes counted together — pentaglyph keeps them as separate primitives because the audience differs.)

How pentaglyph uses PEL

Section titled “How pentaglyph uses PEL”
template/docs/client-engagement/
├── inception-deck/
├── weekly-update/         ← GitLab + Atlassian + Basecamp variants
├── 6-pager/
├── pr-faq/
├── now-next-later/
├── daci/
└── raid/

Each subdirectory contains a template + a one-page how-to that links out to the primitive’s authoritative source. Pentaglyph does not re-author the primitives; it just gives them a predictable place to live.

Why “binder” and not “sixth peer standard”?

Section titled “Why “binder” and not “sixth peer standard”?”

Slots 1-5 (arc42, C4, MADR, Diátaxis, TiSDD) all share three properties:

  1. A single authoritative source (one URL, one maintainer, one canonical spec).
  2. Wide industry adoption (each used at dozens of major organisations).
  3. Decade-stable (none have had breaking changes in 10+ years).

The client-engagement space has none of those. There are dozens of partial frameworks, each maintained by a different vendor (Atlassian / Basecamp / Amazon / GitLab), and the practices shift every few years. Inventing a “sixth peer standard” would mean creating a brittle, opinionated framework — exactly what pentaglyph’s design philosophy avoids.

A binder is honest about this: “here are the primitives we use, here is where they live, the upstream source of each is authoritative.”

When to use PEL

Section titled “When to use PEL”
  • Consulting / advisory practices — client kick-offs, weekly updates, decision documents.
  • Internal teams with executive stakeholders — Amazon 6-pagers and PR-FAQs are useful even inside engineering orgs.
  • Cross-functional projects — DACI and RAID for shared decision tracking.

When NOT to use PEL

Section titled “When NOT to use PEL”
  • Pure internal engineering teams with no external stakeholders or executive reporting.
  • Single-developer projects.

Authoritative references (per primitive)

Section titled “Authoritative references (per primitive)”

See also

Section titled “See also”