Skip to content

Derivative Output Governance

Purpose

This document defines guidance for creating, tracking, governing, and reviewing derivative outputs that rely on the Alescent Strategic Framework, the Applied Value Library, the Alescent Semantic Model, the Value Realization™ Framework, or related source artifacts.

Derivative outputs include PDFs, decks, websites, one-page briefs, executive summaries, worksheets, assessments, articles, proposal inserts, templates, diagrams, and other audience-specific materials derived from repository-governed source content.

Core Principle

Derivative outputs are not source doctrine.

They may compress, sequence, visualize, adapt, reframe, or package source materials for a specific audience, channel, or use case. They must not silently redefine the source artifact, the Value Realization™ Framework, the Alescent Semantic Model, the Applied Value Library, or legal and commercial terms.

Source Hierarchy

When creating derivative outputs, use this source hierarchy:

  1. Legal instruments. Use applicable legal instruments for rights, obligations, order of precedence, enforceable terms, and commercial mechanics.
  2. Alescent Semantic Model. Use it for Alescent-specific controlled concepts and relationships.
  3. Value Realization™ Framework taxonomy and semantic model. Use these for portable framework terminology.
  4. Applied Value Library. Use this for applied Patterns, Practices, Products, Platforms, Playbooks, Proof artifacts, and Performance Measures.
  5. Brand and Communications. Use Brand Voice, Visual Identity, Reusable Language Library, and Content Creation and Prompting Standards for expression, style, and approved language.
  6. Derivative Asset Register. Use it to track recurring outputs, ownership, source dependencies, stale-risk, and review triggers.
  7. Source materials. Use meeting notes, drafts, decks, and other raw materials as evidence or candidates, not as canon unless incorporated through governance.

Required Register Treatment

Recurring, material, client-facing, market-facing, partner-facing, team-facing, or reusable derivative outputs should be tracked in the Derivative Asset Register.

At minimum, the register entry should identify:

  • asset name;
  • output type;
  • audience;
  • owner;
  • source canon artifacts;
  • applied source artifacts;
  • brand voice source;
  • prompting standard source;
  • approved language blocks, if any;
  • content review status;
  • last verified date;
  • stale-risk;
  • update triggers;
  • notes about derivative status and constraints.

Output Variant Tracking

A single source artifact may produce multiple derivative output variants. For example, a Persona Playbook may later produce:

  • an executive PDF;
  • a briefing deck;
  • a website page;
  • a one-page brief;
  • a workshop worksheet;
  • an assessment guide;
  • a proposal insert;
  • a partner enablement note;
  • a social or article derivative.

Each variant should either have its own Derivative Asset Register entry or be listed under a parent entry where the variants share the same source artifacts, owner, stale-risk, and review trigger.

If a variant has a different audience, owner, approval status, or update trigger, it should have its own register entry.

Derivative Output Rules

  • Traceability. Every material derivative output should identify the repository source artifacts it depends on.

  • No silent canon changes. Derivative outputs may explain or adapt canon, but they must not redefine it.

  • No uncontrolled terminology. If a derivative output introduces a new term, check whether it should be treated as an example, applied term, controlled term, or canon review candidate.

  • No duplicate source of truth. Do not maintain independent derivative copy that becomes more current than the source artifact without updating the source or recording the divergence.

  • Audience adaptation is allowed. Derivative outputs may be shorter, more visual, more executive-facing, or more operational than the source artifact.

  • Compression requires caution. Shorter outputs should not remove assumptions, limitations, valuation cautions, legal boundaries, or evidence requirements where those are material.

  • Visual design is derivative. Graphics, diagrams, layouts, and decks should clarify source material without creating competing doctrine.

  • Review triggers matter. When a source artifact changes, affected derivative outputs should be reviewed if their stale-risk or register entry requires it.

Output Types

PDF

PDFs are fixed-format derivative outputs used for polished reading, client sharing, executive briefings, or formal review packets.

PDFs should remain traceable to source Markdown and should not become the authoritative editing surface unless an explicit governance decision says otherwise.

Deck

Decks are sequenced derivative outputs used for presentation, sales, advisory, executive education, or workshop facilitation.

Decks may reorganize the source argument for live delivery, but should not introduce new doctrine merely for narrative flow.

Website Page

Website pages are derivative public or private knowledge surfaces. They should be shorter, more navigable, and more action-oriented than source artifacts.

Website pages should be created using the Website Content Architecture and tracked if reusable or material.

One-Page Brief

One-page briefs are compressed decision or orientation aids. They should preserve the central thesis, audience, value logic, source dependencies, and major cautions.

One-page briefs are high risk for oversimplification and should be reviewed against source artifacts before reuse.

Worksheet or Assessment

Worksheets and assessments are operating derivative outputs. They may include prompts, scoring, diagnostic logic, maturity cues, evidence questions, or interview guides.

Where they influence client decisions, Findings, Recommendations, Initiatives, or Value Statements, they should be traceable to source practices and evidence standards.

Publishing Guardrails

Derivative output governance does not authorize changes to default publishing workflows.

The default GitHub Pages MkDocs build must remain PDF-free. Companion PDFs are reserved for explicit PDF-capable publishing profiles or scripts. The workflow guard that fails when PDFs appear under .mkdocs/docs is a protective invariant and should not be removed, weakened, or bypassed.

When publishing scripts shell out to another PowerShell process, they should resolve pwsh or powershell by availability rather than hard-coding Windows PowerShell.

Review Checklist

Before releasing a derivative output, check:

  • Does it identify its source artifacts?
  • Does it preserve controlled terminology?
  • Does it distinguish source doctrine from applied interpretation?
  • Does it avoid implying guaranteed outcomes?
  • Does it preserve material evidence, valuation, and legal cautions?
  • Does it have an owner and update trigger?
  • Is it registered if recurring, material, or high-exposure?
  • Does it require a separate output variant entry?
  • Does it follow Alescent Brand Voice and Visual Identity guidance?
  • Does it avoid becoming a competing source of truth?

Governance

Derivative output governance belongs under the Alescent Strategic Framework because it governs Alescent-specific packaging, communication, publishing, and asset lifecycle management.

If derivative output rules affect portable Value Realization™ Framework doctrine, the issue should be recorded in the Value Realization™ Framework governance process before being treated as general canon.