Part 028 — Document Models, Templates, Rendering, Attachments, and Presentation Consistency

Positioning

Proposal adalah customer-facing representation dari Quote.

Ia dapat berupa:

• PDF;
• HTML;
• portal view;
• DOCX;
• email attachment;
• structured digital offer;
• atau package berisi beberapa artifact.

Proposal sangat penting secara komersial dan legal, tetapi proposal tidak boleh menjadi second source of truth yang terpisah dari structured Quote.

Core thesis: document pipeline harus menghasilkan immutable artifact dari exact quote revision, exact pricing/terms evidence, dan versioned templates. Artifact harus dapat dibuktikan cocok dengan source revision, delivered securely, dan diterima tanpa ambiguity.

1. Proposal versus Quote

Quote

Structured commercial domain object.

Proposal

Rendered representation of a specific Quote revision.

Proposal should not own:

• authoritative price calculation;
• product configuration;
• approval logic;
• or lifecycle rules.

2. Document Generation Boundary

Document generation consumes:

• finalized quote revision;
• price snapshot;
• terms;
• party data;
• template;
• localization;
• and attachment references.

It produces immutable artifacts and metadata.

3. Proposal Identity

Each generated proposal needs stable identity.

Example:

Proposal ID: PROP-2026-000123
Quote: QUO-123
Revision: 7

4. Artifact Identity

A proposal package may contain multiple artifacts:

• cover letter;
• commercial proposal;
• price appendix;
• technical appendix;
• terms;
• and supporting documents.

Each artifact needs identity/version/checksum.

5. Proposal Version

Proposal version is not Quote revision.

A proposal can be regenerated from same revision for:

• corrected rendering;
• language;
• channel;
• or accessibility format.

Policy must define when regeneration creates new proposal version.

6. Quote Revision Binding

Every proposal must reference exact:

• Quote ID;
• Revision ID/number;
• content checksum;
• price snapshot;
• term versions;
• and template versions.

7. Document Manifest

A proposal package manifest may include:

proposalId
quoteId
revisionId
sourceChecksum
templateVersions
clauseVersions
locale
currencyFormatPolicy
artifacts
artifactChecksums
generatedAt
rendererVersion

8. Generated Artifact

An artifact should be immutable after generation.

A correction creates a new artifact/version.

9. Proposal Package

A package groups artifacts delivered together.

10. Package Checksum

A checksum can cover:

• manifest;
• artifact checksums;
• and delivery metadata.

11. Source of Truth

Structured Quote revision remains commercial source.

Proposal is evidence of what was presented.

12. Why Document-Only Truth Fails

If PDF is sole source:

• downstream cannot reliably parse;
• price lineage is lost;
• changes are opaque;
• and order conversion becomes document extraction.

13. Why Quote-Only Evidence Is Insufficient

The customer saw a rendered artifact.

Legal/commercial evidence may require exact artifact and delivery history.

14. Hybrid Evidence

Preserve:

• structured revision;
• rendered artifact;
• checksums;
• and delivery/acceptance linkage.

15. Document Model

A Document Model is a normalized rendering input.

It may contain:

• cover data;
• parties;
• offer summary;
• item hierarchy;
• prices;
• terms;
• clauses;
• attachments;
• and metadata.

16. Quote-to-Document Transformation

Transformation should be:

• deterministic;
• versioned;
• testable;
• and free from hidden commercial calculation.

17. Transformation Version

Store version of mapping from Quote domain to Document Model.

18. Renderer Version

Store the software/component version that produced artifact.

19. Template Version

Each template must be immutable/versioned.

20. Clause Version

Each reusable legal/commercial clause needs identity/version.

21. Localization Resource Version

Labels and translations can affect meaning.

Version them for reproducibility.

22. Formatting Policy Version

Price/date/number formatting rules may be versioned.

23. Rendering Context

Typical context:

locale
language
timezone
market
brand
channel
customer type
document type
accessibility mode

24. Locale

Locale affects:

• numbers;
• dates;
• currency;
• language;
• and collation.

25. Language

One quote may require:

• one language;
• bilingual output;
• or market-specific translations.

26. Timezone

Display dates using explicit business/customer timezone.

27. Brand

Branding may affect:

• logo;
• typography;
• legal footer;
• and template selection.

It should not alter authoritative commercial values.

28. Channel

Portal, email, partner, and print channels may use different layouts.

29. Customer Segment

Enterprise versus SMB may use different presentation depth.

30. Document Type

Possible types:

• indicative estimate;
• formal proposal;
• quote summary;
• price appendix;
• order form;
• and renewal offer.

31. Template Selection

Selection may use:

• tenant;
• market;
• brand;
• channel;
• language;
• document type;
• and effective date.

32. Template Selection Trace

Record:

• candidates;
• selected template;
• rule/version;
• and reason.

33. Template Fallback

Fallback may use:

• market default;
• global default;
• or manual review.

Do not silently use wrong legal template.

34. No Template Found

Return domain error:

PROPOSAL_TEMPLATE_NOT_AVAILABLE

35. Multiple Templates Found

Require deterministic precedence or conflict resolution.

36. Template Governance

Before activation:

• review legal content;
• test rendering;
• verify placeholders;
• and perform regression.

37. Template Lifecycle

Possible:

• Draft;
• InReview;
• Approved;
• Active;
• Deprecated;
• Retired.

38. Effective Dating

Templates and clauses may be effective by:

• market;
• legal entity;
• and date.

39. Immutable Published Template

Published template version should not be edited in place.

40. Template Schema

Define required input fields and allowed components.

41. Placeholder

A placeholder references a structured field.

Example:

{{quote.customer.legalName}}

42. Placeholder Validation

Validate:

• field exists;
• type compatible;
• visibility allowed;
• and null behavior.

43. Missing Placeholder Data

Possible behavior:

• fail generation;
• omit section;
• show fallback;
• or require manual review.

Critical legal/price fields should normally fail.

44. Conditional Section

Example:

Include tax section if tax estimate exists.

Conditions must be deterministic.

45. Repeating Section

Used for:

• quote items;
• sites;
• charges;
• and terms.

46. Nested Hierarchy Rendering

Bundle hierarchy can be shown as:

• nested table;
• grouped sections;
• summary + appendix;
• or flattened lines with relationship labels.

47. Presentation Hierarchy versus Domain Hierarchy

Document may simplify structure.

Lineage must remain traceable to Quote Item IDs.

48. Hidden Technical Components

Some technical components may be omitted customer-facing.

They remain in structured Quote and order lineage.

49. Customer-Visible Component

Visibility should be governed by metadata/policy, not ad hoc template code.

50. Price Presentation

Price rendering must preserve:

• currency;
• charge type;
• period;
• quantity;
• unit;
• tax status;
• and discount duration.

51. One-Time and Recurring Separation

Do not sum without clear normalization.

52. Usage Rate Presentation

Show:

• rate;
• unit;
• allowance;
• tier;
• and estimate assumptions.

53. Discount Presentation

Possible:

• show base and discount;
• show net only;
• show promotion name;
• or show duration.

Policy and transparency matter.

54. Tax Presentation

Clearly state:

• included;
• excluded;
• estimated;
• or final.

55. Currency Formatting

Use:

• correct symbol/code;
• decimal scale;
• grouping;
• and locale.

Binding currency should not be confused with display conversion.

56. Rounding Consistency

Rendered totals must use the same rounded values stored in Quote snapshot.

Do not recalculate from raw rates in template.

57. Price Table

A price table should reference structured component IDs.

58. Total Reconciliation

Generated artifact totals must match Quote totals exactly.

59. Rounding Adjustment Visibility

Show according to policy.

60. Terms Presentation

Terms may include:

• payment;
• contract duration;
• renewal;
• cancellation;
• price validity;
• service levels;
• and special conditions.

61. Structured Term Rendering

Use exact term values and versions.

62. Clause

A clause is reusable legal/commercial text with:

• ID;
• version;
• language;
• scope;
• and effective period.

63. Clause Selection

May depend on:

• product;
• market;
• legal entity;
• customer type;
• term;
• and exception.

64. Clause Selection Trace

Store why each clause was included/excluded.

65. Mandatory Clause

Cannot be removed without authorized exception.

66. Optional Clause

May be included by context or user selection.

67. Customer-Specific Clause

Requires strong governance and versioning.

68. Negotiated Clause

Should reference:

• source;
• legal approval;
• exact wording;
• and revision.

69. Clause Ordering

Some clauses require deterministic order.

70. Clause Conflict

Two clauses may contradict.

Publication or generation validation should detect.

71. Clause Localization

Legal translation must be governed.

Do not machine-translate binding clauses without policy.

72. Bilingual Clause

May preserve both authoritative and translated text.

73. Governing Language

Proposal may specify which language controls.

74. Dynamic Text Risk

Free-form generated text can introduce unsupported commitments.

75. Generative AI Boundary

If generative text is used:

• restrict to non-binding summaries;
• require review;
• preserve prompt/model/version;
• and never allow it to alter structured price/terms.

76. Customer Name and Address

Use authoritative party snapshot.

77. Personal Data

Minimize and protect:

• contact name;
• email;
• phone;
• signature;
• and address.

78. Sensitive Internal Data

Never render:

• cost;
• margin;
• price floor;
• internal approval comment;
• and implementation secret.

79. Visibility Classification

Every document field can be:

• Customer;
• Partner;
• Internal;
• Confidential;
• Restricted.

80. Field-Level Rendering Guard

The renderer should enforce visibility, not trust template author alone.

81. Attachment

Attachments may include:

• product datasheet;
• technical design;
• implementation plan;
• terms;
• SLA;
• and customer-provided document.

82. Attachment Reference

Store:

• document ID;
• version;
• checksum;
• type;
• and visibility.

83. Embedded Attachment

An attachment may be embedded in package/PDF.

84. Linked Attachment

Delivered as separate secure link.

85. Attachment Version

Never replace an already presented attachment in place.

86. Attachment Virus/Malware Scanning

Customer-uploaded or external files require scanning.

87. Attachment Content Type

Validate type and extension.

88. Attachment Size

Apply limits and asynchronous processing.

89. Attachment Access

Use tenant/customer authorization.

90. Attachment Retention

Align with proposal and quote retention.

91. Document Generation Request

A command should include:

quoteId
revisionId
documentType
locale
templateSelectionContext
expectedChecksum
idempotencyKey

92. Generation Preconditions

Typical guards:

• revision finalized;
• price/terms stable;
• required approval valid;
• template available;
• required fields complete;
• and actor authorized.

93. Generation Does Not Imply Presentation

Artifact may be generated for internal review.

94. Draft Watermark

Internal/draft artifacts should be unmistakably marked.

95. Final Artifact

Only approved/finalized artifact can be presented.

96. Generation Lifecycle

Possible states:

• REQUESTED;
• PREPARING_MODEL;
• RENDERING;
• ASSEMBLING;
• VALIDATING;
• COMPLETED;
• FAILED;
• CANCELLED;
• SUPERSEDED.

97. Asynchronous Generation

Useful for:

• large quote;
• many attachments;
• PDF conversion;
• and digital signing.

98. Generation Job Identity

Needed for retry and diagnostics.

99. Idempotent Generation

Same request/idempotency key should not create uncontrolled duplicates.

100. Deterministic Artifact

Given identical:

• source revision;
• template;
• renderer;
• localization resources;
• and formatting policy,

artifact should be reproducible or explainably variant.

101. Deterministic Metadata

PDF metadata timestamps can break byte-identical output.

Decide whether reproducibility means:

• byte-identical;
• content-identical;
• or semantically identical.

102. Reproducibility Levels

Byte Reproducible

Exact binary hash.

Visual Reproducible

Rendered pages visually identical.

Semantic Reproducible

Same commercial content, values, and clauses.

103. Generated Timestamp

If embedded, regeneration naturally changes bytes.

Preserve original artifact for evidence.

104. Renderer Nondeterminism

Potential causes:

• font substitution;
• external image change;
• unordered iteration;
• timezone;
• random IDs;
• and floating layout.

105. Resource Pinning

Pin:

• fonts;
• images;
• CSS;
• template assets;
• and renderer dependencies.

Do not expose font files to users; they are internal deployment assets.

106. External Asset Risk

Loading remote logo/image at render time can change artifact.

Use versioned internal assets.

107. Rendering Isolation

Render untrusted template/content in sandboxed environment.

108. Template Injection

Escape or constrain customer data inserted into:

• HTML;
• XML;
• Markdown;
• and office templates.

109. Server-Side Request Forgery

Renderer must not fetch arbitrary URLs from template/customer fields.

110. Path Traversal

Attachment/template references must be validated.

111. Macro Risk

DOCX/office outputs should not embed untrusted macros.

112. HTML Sanitization

For portal/HTML proposal, sanitize user-generated rich text.

113. PDF Security

Potential controls:

• encryption;
• password;
• permissions;
• and digital signature.

Use only where business policy requires.

114. Digital Signature

Can prove artifact integrity and signer identity.

115. Document Seal

Provider may apply digital seal to final artifact.

116. Artifact Checksum

Store cryptographic checksum.

117. Source Checksum

Store Quote revision checksum used.

118. Consistency Proof

A proposal manifest can prove:

artifact checksum
was generated from
quote revision checksum
using
template and renderer versions

119. Proposal Validation

Before completion, validate:

• source IDs;
• totals;
• term versions;
• required clauses;
• attachment checksums;
• and no unresolved placeholder.

120. Structural Validation

Ensure:

• all sections present;
• hierarchy valid;
• and page/package manifest complete.

121. Monetary Validation

Compare rendered structured data against Quote price snapshot.

122. Clause Validation

Verify exact selected clause versions are rendered.

123. Visibility Validation

Ensure internal fields do not appear.

124. Accessibility Validation

Depending on policy:

• tagged PDF;
• text alternatives;
• reading order;
• and contrast.

125. Localization Validation

Check:

• missing translation;
• overflow;
• date/currency format;
• and legal wording.

126. Page Overflow

Large tables or long product names can break layout.

127. Widow/Orphan Layout

Not the domain orphan concept—document pagination may split headings/rows poorly.

128. Table Splitting

Define behavior for multi-page item/price tables.

129. Large Quote Rendering

Thousands of items may require:

• summary proposal;
• external appendix;
• pagination;
• and generated CSV/XLSX attachments.

130. Summary + Appendix

A customer-friendly summary links to detailed line appendix.

131. Appendix Identity

Appendix must reference same revision and manifest.

132. Partial Artifact Failure

If appendix fails, package should not be marked complete.

133. Retry

Retry transient rendering/storage failures.

134. Retry Safety

Do not duplicate customer delivery.

Generation and delivery are separate operations.

135. Cancellation

A superseded revision may cancel running generation job.

136. Supersession

A completed proposal can be superseded by newer revision.

Artifact remains immutable.

137. Regeneration

Reasons:

• rendering defect;
• language change;
• channel format;
• or accessibility output.

138. Commercial Regeneration

If commercial content changes, a new Quote revision is required.

139. Non-Commercial Regeneration

A renderer bug may justify new proposal version from same revision.

Preserve original and reason.

140. Proposal Correction

A corrected artifact should link to:

• original proposal;
• correction reason;
• and source revision.

141. Document Storage

Store artifacts in:

• object/document storage;
• with immutable key;
• checksum;
• encryption;
• and retention.

142. Database Storage

Database stores metadata and references, not necessarily large binaries.

143. Content Addressing

Artifact hash may serve as integrity identity.

144. Object Versioning

Enable where needed to prevent overwrite.

145. Retention Lock

Accepted artifacts may require write-once retention.

146. Deletion

Deletion policy must consider:

• privacy;
• legal hold;
• accepted evidence;
• and tenant contract.

147. Legal Hold

Prevents deletion during dispute/investigation.

148. Data Residency

Artifact storage may be regional or on-prem.

149. Backup

Backups must preserve encryption and retention requirements.

150. Proposal Read API

Returns:

• proposal metadata;
• state;
• revision;
• artifact list;
• checksums;
• and secure access links.

151. Artifact Download

Use short-lived authorized URL or proxy.

152. Link Security

Protect against:

• guessing;
• forwarding;
• expiry bypass;
• and cross-tenant access.

153. Delivery

Possible channels:

• email;
• customer portal;
• partner portal;
• API;
• secure file exchange;
• and physical print.

154. Delivery Identity

A Delivery Attempt needs:

• ID;
• proposal;
• recipient;
• channel;
• time;
• and result.

155. Delivery versus Presentation

Delivery

Technical transmission.

Presentation

Business fact that exact proposal was offered to customer.

A successful email send may not prove receipt.

156. Delivery State

Possible:

• REQUESTED;
• SENT;
• DELIVERED;
• BOUNCED;
• FAILED;
• VIEWED;
• DOWNLOADED;
• ACKNOWLEDGED.

Not all channels provide all evidence.

157. Presentation Record

Store:

• quote/revision;
• proposal;
• recipients;
• channel;
• presentedAt;
• actor;
• and evidence.

158. Presentation Guard

Check:

• proposal completed;
• source revision still active;
• approval valid;
• price current;
• quote not expired;
• and actor authorized.

159. Presentation Idempotency

Retry should not create duplicate business presentation records unless it is a deliberate resend.

160. Resend

A resend of same proposal should be distinguishable from a new commercial presentation.

161. Delivery Failure

Quote may remain approved but not yet presented.

162. Bounce

May create task to correct recipient.

163. Portal Publication

Publishing to portal can be the presentation action.

164. Access Window

Proposal access link may expire before Quote expires.

They are separate.

165. Revocation

Withdrawing a proposal can revoke portal access.

Downloaded copies cannot be technically recalled.

166. Watermark

Possible:

• Draft;
• Confidential;
• Superseded;
• or Copy.

167. Superseded Proposal

Portal should clearly mark or hide it from acceptance.

168. Customer Acceptance Linkage

Acceptance must reference exact:

• Proposal ID;
• Quote revision;
• and checksum.

169. Acceptance Token

Bind token to:

• recipient;
• proposal;
• revision;
• expiry;
• and nonce.

170. Tamper Detection

Verify artifact/token/checksum before acceptance.

171. Viewed Event

Useful but not legal proof of agreement by itself.

172. Downloaded Event

May support engagement analytics.

173. Acknowledgement

Customer acknowledges receipt but has not accepted.

174. E-Signature Integration

May send artifact to external signing provider.

175. Signing Package Identity

Map:

• external envelope;
• proposal;
• quote revision;
• signatories;
• and signed artifact.

176. Signing Status

Separate from Quote business state.

177. Signing Callback

Callbacks may be:

• duplicate;
• delayed;
• out of order;
• or forged.

Validate signature and idempotency.

178. Signed Artifact

Preserve:

• provider evidence;
• signed document;
• checksum;
• timestamps;
• and signatory identity.

179. Partial Signature

Some signatories may complete, others pending.

180. Signature Decline

Does not automatically equal commercial Quote decline unless policy maps it.

181. Signature Expiry

Signing envelope expiry can differ from Quote validity.

182. Proposal Generation API

Possible command:

{
  "quoteId": "QUO-123",
  "revisionId": "QUO-123-R7",
  "documentType": "FORMAL_PROPOSAL",
  "locale": "en-ID",
  "idempotencyKey": "..."
}

183. Generation Result

Returns:

• job/proposal ID;
• status;
• source checksum;
• and links when complete.

184. Delivery API

Should reference Proposal ID, not regenerate implicitly.

185. Regeneration API

Needs reason and expected source/template identity.

186. Generic Template API Risk

Allowing arbitrary template code creates security and governance risk.

187. Event Model

Representative events:

• ProposalGenerationRequested;
• ProposalGenerated;
• ProposalGenerationFailed;
• ProposalValidated;
• ProposalDelivered;
• ProposalViewed;
• ProposalSuperseded;
• ProposalRevoked.

188. Event Payload

Include:

• proposal;
• quote/revision;
• artifact metadata;
• state;
• channel;
• and timestamps.

Avoid embedding full documents.

189. Outbox

Persist proposal metadata/state and event intent atomically.

190. Event Ordering

Use Proposal ID.

191. Idempotent Consumers

Email, portal, CRM, and analytics consumers handle duplicates.

192. Document Generation Metrics

• generation latency;
• failure rate;
• queue depth;
• retry rate;
• and artifact size.

193. Template Metrics

• use by template version;
• missing placeholder rate;
• and fallback rate.

194. Consistency Metrics

• proposal/quote total mismatch;
• missing clause;
• wrong revision;
• and checksum failure.

195. Delivery Metrics

• send success;
• bounce;
• delivery;
• view;
• download;
• and time-to-view.

196. Proposal SLI

Examples:

• zero presented artifacts with quote-total mismatch;
• all final proposals traceable to exact revision;
• target generation latency by document size;
• and zero cross-tenant artifact access.

Internal targets must be verified.

197. Stuck Generation

Examples:

• rendering job running too long;
• attachment scan pending;
• storage failure;
• and missing font/resource.

198. Reconciliation

Detect:

• completed proposal without artifact;
• artifact checksum mismatch;
• presented record with wrong revision;
• active proposal for superseded revision;
• and accepted quote without accepted artifact reference.

199. Recovery Commands

Examples:

• RetryProposalGeneration;
• RebuildProposalManifest;
• SupersedeProposal;
• RevokeProposalAccess;
• ReconcileDelivery;
• CorrectProposalMetadata.

200. Direct File Replacement Risk

Replacing a stored PDF bypasses:

• checksum;
• audit;
• proposal identity;
• and acceptance evidence.

201. Proposal Incident

Examples:

• wrong customer document;
• stale revision rendered;
• internal margin exposed;
• incorrect total;
• missing clause;
• cross-tenant access;
• and accepted artifact overwritten.

202. Incident Containment

Possible:

• revoke access;
• stop delivery;
• mark artifact compromised;
• withdraw proposal;
• notify affected parties;
• block acceptance;
• and preserve forensic evidence.

203. Template Incident

A template defect may affect many proposals.

Impact analysis should identify:

• template version;
• quote revisions;
• generated artifacts;
• delivered proposals;
• and accepted proposals.

204. Correction Strategy

For delivered but unaccepted proposal:

• supersede and re-present corrected artifact.

For accepted proposal:

• explicit correction/amendment process.

205. Proposal Smells

• PDF is the only truth;
• proposal has no revision reference;
• generated file is mutable;
• and no checksum.

206. Template Smells

• one mutable template;
• legal text hard-coded in code;
• placeholder errors discovered in production;
• and remote assets fetched live.

207. Rendering Smells

• document recalculates totals;
• current catalog names used;
• unordered items;
• and timezone defaults.

208. Delivery Smells

• generation automatically emails customer;
• retry duplicates delivery;
• public permanent links;
• and no recipient evidence.

209. Localization Smells

• legal text machine-translated;
• currency formatting differs from Quote;
• and missing language fallback is silent.

210. Attachment Smells

• presented attachment overwritten;
• unscanned upload;
• and cross-tenant document ID accepted.

211. Anti-Patterns

Document as Second Commercial Model

Prices and terms recalculated in template.

Current Data Rendering

Historical revision mixed with current customer/catalog data.

Mutable PDF Path

Old evidence can be replaced.

Generate-and-Send as One Operation

Retries create duplicate customer delivery.

Template Logic as Business Rule Engine

Commercial semantics become hidden.

Accept Current Proposal

Exact artifact/revision ambiguity.

212. Proposal Manifest Template

## Proposal Identity and Version

## Quote / Revision

## Source Checksum

## Document Type

## Locale / Timezone / Brand / Channel

## Document Model Version

## Template Versions

## Clause Versions

## Renderer Version

## Artifacts

For each:
- Artifact ID
- Type
- File name
- Content type
- Size
- Checksum
- Visibility

## Generated At

## Validation Result

## Delivery / Presentation References

## Supersession

## Retention

213. Template Definition Template

Template ID/version:
Document type:
Tenant/market/brand/channel:
Languages:
Effective period:
Input schema:
Required placeholders:
Conditional sections:
Assets:
Clause slots:
Visibility rules:
Approval:
Renderer compatibility:

214. Clause Definition Template

Clause ID/version:
Type:
Language:
Authoritative language:
Scope:
Eligibility:
Mandatory/optional:
Effective period:
Text checksum:
Legal approval:
Conflicts:
Ordering:

215. Generation Request Template

Request ID:
Quote/revision:
Expected source checksum:
Document type:
Locale:
Template context:
Attachments:
Requested by:
Idempotency key:

216. Artifact Validation Template

Proposal/artifact:
Source revision:
Source checksum match:
Totals match:
Terms match:
Required clauses:
Visibility scan:
Placeholder errors:
Attachment checksums:
Accessibility:
Result:

217. Delivery Record Template

Delivery ID:
Proposal:
Recipient:
Party role:
Channel:
Requested at:
Sent at:
Delivered/viewed at:
Result:
Failure reason:
Correlation:

218. Presentation Record Template

Quote/revision:
Proposal:
Artifact checksums:
Presented by:
Presented to:
Channel:
Presented at:
Delivery evidence:
Quote validity:
Approval evidence:

219. Proposal Invariants

Representative invariants:

• final proposal references exact finalized revision;
• artifact checksum is immutable;
• rendered totals equal quote snapshot totals;
• required clauses use exact versions;
• internal fields are excluded;
• delivery does not mutate artifact;
• acceptance references exact proposal;
• and superseded proposal cannot be newly accepted.

220. Worked Example: Formal Proposal

Source:

• Quote Revision 7;
• Price Snapshot P7;
• Term Set T4;
• Approval A12.

Generation selects:

• enterprise template v9;
• English locale;
• legal clauses C2/C8;
• renderer 4.1.

Manifest stores all versions and checksums.

221. Worked Example: Bilingual Proposal

Package contains:

• authoritative English proposal;
• translated Indonesian version.

Manifest states governing language and links both to same revision.

222. Worked Example: Large Multi-Site Quote

Proposal contains:

• executive summary;
• aggregated price;
• site appendix;
• CSV detail;
• technical appendix.

All artifacts share one package manifest and revision identity.

223. Worked Example: Template Fallback Failure

No approved legal template exists for market/brand.

Generation fails with:

• PROPOSAL_TEMPLATE_NOT_AVAILABLE.

It does not silently use global template.

224. Worked Example: Rendering Correction

A renderer bug truncates one table label.

Commercial values are correct.

System creates Proposal Version 2 from same revision, preserves Version 1, and records correction reason.

225. Worked Example: Commercial Change

Customer quantity changes.

A new Quote Revision is created.

The previous proposal is not regenerated in place.

A new Proposal ID is generated from the new revision.

226. Worked Example: Total Mismatch

Artifact validation detects:

• rendered recurring total 999;
• Quote total 1000.

Proposal generation fails before presentation.

227. Worked Example: Attachment Replacement

Technical appendix changes.

If customer-visible commercial content changes or appendix is part of presented package, create new artifact/package version and re-presentation as required.

228. Worked Example: Secure Portal

Proposal is published to portal using authorized access.

Customer view event is recorded.

Acceptance references Proposal ID and checksum.

229. Worked Example: Email Bounce

Email delivery bounces.

Quote remains Approved, not Presented, unless business presentation policy considers another channel successful.

A task requests recipient correction.

230. Worked Example: Revoked Proposal

Seller withdraws offer.

Portal access is revoked and proposal marked withdrawn/superseded.

Previously downloaded file remains evidence but acceptance endpoint rejects it.

231. Worked Example: E-Signature Callback

Signing provider sends duplicate completed callbacks.

Idempotent handler records one signed artifact and one acceptance process.

232. Worked Example: Cross-Tenant Attack

A user submits attachment ID belonging to another tenant.

Authorization rejects it before generation.

233. Senior Engineer Operating Model

Keep Quote authoritative

Document rendering must not recalculate commercial meaning.

Bind every artifact to exact revision

With checksums and version manifests.

Version templates, clauses, mappings, and renderer

Reproducibility requires all of them.

Separate generation, validation, delivery, and presentation

Retries and business semantics differ.

Treat final artifacts as immutable

Corrections create new versions.

Build consistency validation

Totals, terms, clauses, and visibility.

Secure the rendering pipeline

Sandbox, sanitization, asset pinning, and tenant checks.

Link acceptance to exact artifact

Not generic current proposal.

Operate documents as mission-critical evidence

Metrics, reconciliation, incident containment, and retention.

234. Internal Verification Checklist

Architecture

• Which system renders proposal artifacts?
• Is document generation a separate service/component?
• Does it consume immutable Quote revisions?
• Does it perform any hidden pricing or term logic?

Identity and reproducibility

• Does every proposal store Quote revision identity?
• Are source, template, clause, mapping, renderer, and localization versions retained?
• Are artifact and source checksums stored?
• Can an artifact be regenerated semantically or byte-identically?

Templates and clauses

• How are templates selected?
• Are published templates immutable/effective-dated?
• How are customer-specific clauses governed?
• Are conflicts and required clauses validated?

Monetary and hierarchy presentation

• Are totals rendered from stored price snapshots?
• Are one-time, recurring, usage, discount, and tax semantics clear?
• How are bundles and hidden technical components presented?
• Are rounding and currency formatting consistent?

Localization

• Which locales/languages are supported?
• Who approves legal translations?
• Is governing language explicit?
• What happens when a translation is missing?

Attachments and storage

• Are uploads scanned and authorized?
• Are attachments versioned and immutable after presentation?
• Where are artifacts stored and retained?
• Is legal hold/data residency supported?

Delivery and presentation

• Are generation and delivery separate operations?
• What constitutes business presentation?
• How are resends, bounce, portal publication, and revocation handled?
• Is acceptance tied to exact proposal/checksum?

Security and operations

• Are renderer sandboxing, injection prevention, SSRF controls, and tenant isolation implemented?
• Are mismatch, generation, and delivery metrics available?
• Can support reconstruct exact artifact lineage?
• What recovery/correction commands exist?

235. Practical Exercises

Exercise 1 — Document boundary

List all fields that must come from Quote versus template/presentation policy.

Exercise 2 — Manifest

Design a manifest sufficient to prove artifact lineage.

Exercise 3 — Template selection

Create deterministic rules for market, brand, language, channel, and document type.

Exercise 4 — Consistency validation

Define checks for totals, terms, clauses, hierarchy, and visibility.

Exercise 5 — Secure delivery

Model email, portal, resend, revocation, and acceptance linkage.

Exercise 6 — Incident analysis

Design response to a template defect affecting delivered and accepted proposals.

236. Part Completion Checklist

You are done if you can:

• distinguish Quote and Proposal responsibilities;
• create a versioned Document Model;
• select immutable templates and clauses;
• preserve locale, formatting, and renderer versions;
• generate immutable artifacts with checksums;
• prove proposal-to-revision consistency;
• separate generation, delivery, presentation, and acceptance;
• secure templates, attachments, rendering, and access;
• handle regeneration, supersession, and correction;
• and create an internal proposal-pipeline verification backlog.

237. Key Takeaways

1. Proposal is a representation, not the commercial source of truth.
2. Every artifact must bind to exact Quote revision.
3. Templates, clauses, mappings, localization, and renderer need versions.
4. The renderer must not recalculate price or terms.
5. Final artifacts should be immutable.
6. Generation, validation, delivery, and presentation are separate.
7. Totals and clauses must be validated before presentation.
8. Acceptance must reference exact proposal and checksum.
9. Rendering and attachment pipelines require strong security.
10. Internal CSG proposal and document architecture must be verified.

238. References

Conceptual baseline:

• General enterprise CPQ proposal, document-generation, template, clause, and digital-delivery practices.
• Immutable artifacts, checksums, manifests, content-addressing, and long-term evidence retention.
• Secure templating, sandboxed rendering, attachment scanning, access control, and signed-document concepts.
• Domain-Driven Design projections, versioned transformations, and separation of authoritative models from representations.

These references do not define internal CSG proposal-generation systems, templates, or delivery channels.