# Agent Standards Style Notes

## Purpose

These notes define the intended authorial style for the `TAK` and `GAID` standards family, especially the supporting white paper. They are derived from:

- `D:/DPF/docs/Reference/shift_to_digital_product.txt`
- `D:/DPF/docs/Reference/digital_product_portfolio_mgmt.txt`

The aim is not imitation for its own sake. The aim is to preserve the tone, structure, and practical clarity already present in Mark Bodman's published work.

## Source of Truth

- Markdown files are the editable source of truth.
- Generated `.docx` outputs are publication artifacts, not the primary authoring surface.
- Diagram source files are the editable source of truth for figures.

## Tone Markers To Preserve

- Declarative and position-taking, not tentative or meandering
- Formal, but still readable by executives and practitioners
- Pragmatic rather than academic for its own sake
- Explicit about management consequences, not only technical mechanics
- Market-aware and governance-aware
- Comfortable drawing practical conclusions from fragmented industry conditions
- Clear about why a concept matters operationally, not only conceptually
- Structured to help standards bodies, enterprises, and practitioners all find their entry point

## Structural Patterns To Reuse

- Open with a direct statement of the problem being solved
- Define the focal concept early and revisit it throughout
- Use sectioned progression from problem -> definition -> operating implications -> adoption implications
- Tie abstract concepts back to lifecycle management, accountability, governance, and operating model change
- Use concise tables where they improve precision
- Use examples to ground the concept rather than to decorate the prose
- End sections with implications, not just description

## Language Patterns To Prefer

- "We propose ..."
- "A key message of this document is ..."
- "The aim is ..."
- "This supports ..."
- "This creates ..."
- "This enables ..."
- "The problem is not ..."
- "The point is not ..."
- "In practice ..."
- "The consequence is ..."

## Habits To Preserve

- Define terms when they are overloaded in industry usage
- Distinguish architecture concerns from management concerns
- Explain why semantics matter
- Call out ambiguity directly instead of smoothing past it
- Use standards and industry frameworks as reference points without letting them dominate the argument
- Maintain a through-line from executive concern to operating reality

## Habits To Avoid

- Breathless "AI will change everything" language
- Marketing phrasing
- Hype adjectives such as "revolutionary", "transformative", or "game-changing" unless attributed in cited material
- Generic AI-safety boilerplate with no operational consequence
- List-heavy writing where a short argument would be clearer
- Jargon without definition
- Overly casual or chatty transitions
- Overclaiming certainty where the ecosystem is still evolving

## White Paper Voice

The white paper should read like a serious industry position paper:

- persuasive, but not polemical
- grounded in real implementation pain
- explicit about policy and standards relevance
- confident enough to recommend a direction
- clear that this is a practical proposal, not only a theoretical taxonomy

The white paper should sound like it belongs next to the existing Open Group-style material rather than next to a vendor blog post.

## TAK Voice

`TAK` should read as a normative operational standard:

- direct
- specific
- enforceable
- unambiguous where possible

It should preserve the clarity of the current architecture write-up, but shift from descriptive explanation toward normative requirements.

## GAID Voice

`GAID` should read as a normative identity and governance standard:

- precise
- federated in outlook
- globally aware
- explicit about issuer, registry, traceability, and assurance consequences

It should sound credible to people who understand DNS, ISBN, PKI, identity, software provenance, and enterprise governance.

## Diagram Expectations

- Diagrams must clarify, not decorate
- Figures should be publication quality
- Text inside diagrams must remain legible after Word embedding
- Prefer vector masters and high-resolution raster outputs
- Avoid dense text blocks inside diagrams when a nearby table would be clearer

