BXUP Track progress & test yourself — free
Cloud & Solutions Architecture · Playbook · Foundation · ~5 min read
CLOUD & SOLUTIONS ARCHITECTURE · PLAYBOOK · FOUNDATION

Exec One-Pagers & the Three-Altitude Pack

One architecture decision, three audiences: the board wants risk and money, engineering leadership wants trade-offs and staffing, the build team wants specifics. AI removes the production cost of writing all three well — and a final consistency check ensures the three altitudes describe the same decision.

Tier: Foundation · Hands-on time: ~25 minutes

Gregor Hohpe's architect-elevator framing is this playbook's vocabulary: the architect's differentiating skill is riding between the penthouse and the engine room without garbling the message on the way. Most architects write one document — pitched at their own altitude — and force every other audience to translate. The failure that costs credibility is not bad writing but altitude drift: the board version quietly promises what the build-team version quietly walks back. AI makes producing three purpose-built renderings cheap; the discipline this playbook adds is checking them against each other before anyone else does.

When to use

  • A significant decision (platform choice, migration approach, AI feature go/no-go) needs communicating upward and downward in the same week.
  • A steering committee or client executive asked for "the one-pager" and all you have is a 30-page HLD.
  • India-based architects presenting to US/EU stakeholders async — the pack must stand alone across timezones, with no meeting to catch misreadings.

Skip AI when you do not yet understand the decision well enough to brief it verbally — the model will fluently render your confusion at three altitudes.

Prerequisites

  • The decided, verified source materialthe ADR (pb-14), the options matrix (pb-06), and the verified cost model. The pack renders decisions; it must not invent them.
  • An LLM chat assistantwith your firm's voice examples if exec materials have a house style; deck tooling for the leadership tier.
  • Named audiencesactual readers, not personas: this board, this VP of engineering, this build team, and what each already knows.
  • Numbers with provenanceevery figure that will appear at any altitude traces to the verified model (pb-05 discipline); the exec tier is where unverified numbers do the most damage.

The workflow

  1. Write the invariant core first — ten lines, by hand. The decision, the top three reasons, the principal risk with its mitigation, the cost envelope, the date. This is the anchor: all three altitudes are renderings of these ten lines, and the consistency check at the end runs against it. If you cannot write the core, return to the decision artifacts — the gap is upstream.

  2. Generate the three renderings from the same core.

    Below is the decision core (10 lines) and supporting artifacts for
    Meridian Retail's agent-platform decision. Produce three renderings.
    
    1. BOARD ONE-PAGER (≤400 words): business outcome, cost envelope,
       top risk and its mitigation, decision requested, date needed.
       No service names, no architecture vocabulary. Risk stated plainly
       — do not soften "requires client data-sharing approval" into
       "subject to alignment".
    2. ENGINEERING-LEADERSHIP BRIEF (1 page + a 5-bullet deck outline):
       the trade-off we made and what we gave up, staffing/skill
       implications, delivery risks, what leadership must unblock.
    3. BUILD-TEAM BRIEF (1–2 pages): the decision's binding constraints,
       what is fixed vs open for team decision, links to the ADR and
       skeleton repos, first-sprint implications.
    
    Rules: every number must come from the core or the attached cost
    model — introduce no new numbers. Each rendering must state the same
    decision, the same top risk, and the same cost envelope. Do not add
    claims at one altitude that the others do not support.
    ###
    [paste core + artifacts]
    
  3. Run the consistency check as its own pass. Fresh prompt, all three drafts: "Compare these three renderings of one decision. Report: numbers that differ or appear in only one; risks present at one altitude and absent at another; commitments the board version makes that the build-team version does not support; tone drift where the same fact reads as solved in one and open in another. Cite locations." Altitude drift is exactly the cross-document contradiction hunting models do well (pb-16's skill, pointed at your own pack).

  4. Resolve drift toward the truth, not the middle. Every finding gets resolved against the decision core and source artifacts — usually by making the optimistic rendering honest rather than the honest one vague. The classic finding: the board page says "live in Q1," the build brief says "Q1 assuming client staging access by week 3." The fix is adding the dependency to the board page, not deleting it from the brief.

  5. Fact-check the exec tier hardest. Counterintuitive but right: the shortest document carries the highest risk per sentence, because executives act on it without reading the appendix. Every number, date, and commitment on the one-pager gets a provenance check against the verified artifacts. A hallucinated figure in an HLD embarrasses you in review; on a board page it becomes policy.

  6. Ship as a pack, and read the room's echo. Send each audience its rendering with the others available ("full pack attached") — audiences trust materials more when they can see the other altitudes agree. Async across timezones, add one line inviting the specific readback you fear ("if the week-3 dependency is news, flag it"). The response tells you whether the altitude landed.

Verify before you trust it

  • Three-way number audit. Build the table yourself: every figure × where it appears × source artifact. Any number in a rendering but not in the verified sources gets deleted — this is the pb-05 register discipline applied to communication.
  • The commitments match. Read only the sentences containing "will," "by," and dates, across all three. These are the sentences that get quoted back to you in six months; they must agree.
  • Softening audit on the board page. Compare each risk statement against the ADR's version. "Subject to alignment" for "client has not approved" is the drift that converts a communication into a misrepresentation.
  • A build-team reader recognizes the board page. The cheapest real check: one engineer reads the one-pager and answers "is this the project you are building?" Hesitation is a finding.

Restricted-environment variant

Exec materials concentrate the engagement's most commercially sensitive content — pricing, risks, client names — so the pb-03 register governs. Workable paths: draft from a redacted core (placeholders for client and commercial figures, restored locally in the final documents), or run the whole pack on the approved tenancy (enterprise or client-subscription endpoint). The consistency check works on redacted drafts without loss, since it compares the pack against itself. Board materials for listed companies may carry insider-information constraints beyond the MSA — if the decision touches disclosable numbers, the safe path is drafting structure with AI and inserting all figures manually, offline.

Key Takeaway:

Three audiences, three renderings, one truth. AI writes the altitudes; the consistency check — numbers, risks, commitments agreeing across all three — is what makes the pack an act of communication instead of three small acts of drift.

This is the free reading view. Open BXUP to track your progress, run the hands-on labs, and prove it with original, exam-pattern assessments.
© Anvi Innovate · BXUP — Be Exponentially Upskilled · BXUP is an independent learning platform, not affiliated with or endorsed by AWS, Microsoft, Google, NVIDIA, IBM, Salesforce, Databricks, Oracle or Anthropic. All trademarks belong to their respective owners. · bxup.in