One Document, Five Architectures
Why the AI that writes each document type needs a different personality.
The Architecture Series · 9 minute read · By Ed | Founder & CEO, DealiOS
A proposal is a love letter. A contract is a prenup. A presentation is a highlight reel. An RFP response is a test. An execution item is the blueprint.
These are five fundamentally different types of professional document. Different audiences, different purposes, different formats, different legal implications, different definitions of "good."
Now explain to me why every document platform treats them as the same thing with different templates.
The Template Fallacy
Open any proposal tool's database schema. You'll find a documents table with a type field. Type equals "proposal" or type equals "contract" or type equals "presentation." Same table. Same AI prompt. Same export pipeline. Same engagement tracking.
That's like a restaurant serving steak, sushi, and birthday cake from the same recipe. The birthday cake should not have wasabi on it.
The template approach says: "Documents are all the same structure. The only difference is what text goes inside them." That's true in the way that cars, boats, and planes are all "vehicles." They do share a category label. They do not share an engine, a medium, or a physics model. And the boat won't fly no matter how confidently you label it "aircraft."
A cold proposal loses the deal. A casual contract loses the lawsuit.
When a platform treats content types as template variables, it collapses five distinct architectural problems into one. The AI prompt that generates a proposal is warm, benefit-driven, and structured around buyer outcomes. The AI prompt that generates a contract is precise, clause-driven, and structured around legal enforceability. When both run through the same prompt pipeline, you get proposals that read like legal disclaimers and contracts that read like marketing brochures.
Neither is correct. Both are dangerous. A cold proposal loses the deal. A casual contract loses the lawsuit.
What "First-Class" Actually Means
"First-class" is a programming concept that means "this thing has its own identity, its own behavior, and its own lifecycle." A first-class citizen in a language can be assigned to variables, passed as arguments, and returned from functions. It exists independently. It isn't a property of something else.
Content types should be first-class architectural entities. That means each one gets its own AI prompt module, its own rendering pipeline, its own export format, its own engagement model, and its own security posture. Not variations on a shared system. Independent systems that happen to share a data model.
Here's what that looks like in practice.
Proposals are persuasion engines. The AI prompt module uses warm, benefit-driven language calibrated to the buyer's industry and the deal's stage. The rendering pipeline is branded HTML and CSS, because a proposal's visual presentation is part of the argument. The export is PDF with full brand fidelity, because proposals get forwarded, printed, and reviewed in settings where the formatting itself communicates professionalism. Engagement tracking is granular: which pages, how long, how many deal participants, what sequence. A proposal that someone spent 74 minutes on tells a different story than one that got 30 seconds (Proposify, "State of Proposals," 2023).
Contracts are legal instruments. The AI prompt module uses precise, conservative language with explicit clause structures, ALL CAPS for limitation of liability provisions (because courts and procurement teams expect it), and zero marketing language. The rendering pipeline is DOCX with article-section numbering at the Open XML level, because contracts get redlined in Word by legal teams who will reject any format that disrupts their workflow. Export is DOCX, and when the deal reaches signature stage, DocuSign integration handles envelope creation and routing as a separate workflow step. Engagement tracking is binary: viewed or not, signed or not. Nobody cares which paragraph of the liability cap the client lingered on.
Presentations are controlled narratives. The AI prompt module generates content in JSON structures that map to slide templates, because presentations are fundamentally spatial. A slide has positions, not paragraphs. The rendering pipeline is a template registry that maps content blocks to pre-designed layouts, not a text-to-slide converter that produces bullet-point walls. Export is PPTX, and the quality bar is whether a sales rep would present it to a C-suite without embarrassment. Engagement tracking is per-slide: which slides got the most time, which got skipped. A presentation where the prospect spent 80% of their time on the pricing slide tells you exactly where the conversation is headed.
RFP Responses are compliance exercises that happen to also be sales documents. The AI prompt module writes into the client's format, not yours (Library #5: The Client Template Is Sacred). The rendering pipeline must preserve the client's styles, fonts, tables, and structure at the Open XML level. Export is the client's original file, modified invisibly. Engagement tracking matters less because the document enters the client's internal review process, where you have no visibility.
Execution Items are the bridge between "we agreed to do this" and "here's how we actually do it." Implementation plans, SOWs, training plans, project timelines, onboarding roadmaps. The AI prompt module shifts from selling to planning: concrete milestones, owner assignments, dependency chains, and success criteria. The rendering pipeline shares infrastructure with proposals (markdown to HTML to PDF), because execution items are still branded deliverables that communicate professionalism. But the content DNA is different. A proposal persuades. An execution item commits. Executive summaries are a variant here: the AI compresses a deal's entire story into a single high-density page, which requires a different kind of intelligence than expanding a deal into fifteen.
Five content types. Five AI prompt modules. Five definitions of "good." The rendering infrastructure is shared where the output format overlaps (proposals and execution items both produce branded PDFs through the same markdown-to-HTML pipeline, for example), but the AI personality driving each one is completely distinct.
One documents table with a type field doesn't get you there.
The AI Quality Problem
This is where the architectural choice becomes a quality problem, not just an organizational preference.
A general-purpose AI prompt that tries to handle all content types will produce output that's mediocre at all of them. The prompt tries to be warm enough for proposals and precise enough for contracts simultaneously, which means it's too warm for contracts and too precise for proposals. It splits the difference, and the difference is the uncanny valley of professional documents.
The failure mode is specific and recognizable. A proposal generated by a contract-flavored AI opens with something like: "This document outlines the terms under which the proposed services will be delivered." That's contract language wearing a proposal costume. The buyer reads it and feels, without quite knowing why, that the vendor is cold and transactional.
A contract generated by a proposal-flavored AI includes phrases like "We're excited to partner with you on this journey." That's proposal language in a legal document. The client's lawyer reads it and wonders whether the vendor's legal team reviewed the agreement. They didn't wonder that about the last vendor's contract, and that subconscious comparison is where deals get decided.
The cost isn't aesthetic. It's material. A proposal that sounds like a contract loses warmth. A contract that sounds like a proposal loses credibility. Both lose deals, just at different stages and for different reasons.
Content-type-specific AI modules solve this structurally. The proposal AI never sees the contract prompt. The contract AI never sees the proposal prompt. They share a data model (same deal, same client, same pricing) but diverge on everything that touches language, formatting, and presentation. The shared data model means the pricing in the proposal matches the pricing in the contract. The separate prompt modules mean the proposal says "your investment" and the contract says "the fees set forth in Section 3.1."
Same facts. Different voices. Because the audience is different, the purpose is different, and the definition of "correct" is different.
Same facts. Different voices. Because the audience is different, the purpose is different, and the definition of "correct" is different.
The Rendering Pipeline Problem
AI quality gets most of the attention, but the rendering pipeline is equally important and almost always overlooked.
A proposal rendered as a Word document looks cheap. Full stop. Proposals are marketing documents. They compete for attention with every other vendor's proposal. The one that looks like a PowerPoint exported to DOCX loses to the one that looks like a brand experience. The rendering pipeline for proposals needs to produce pixel-perfect HTML/CSS that converts to high-fidelity PDF. That's a web rendering problem, not a document generation problem.
A contract rendered as a branded PDF looks unprofessional. Contracts are legal instruments. They get printed, redlined, and filed. Legal teams expect DOCX with standard formatting because that's what their tools work with. A beautifully branded contract that can't be opened in Word's track-changes mode is a contract that slows down the deal. The rendering pipeline for contracts needs to produce clean Open XML with proper paragraph styles, heading hierarchies, and embedded signature anchors.
A presentation rendered as a document is not a presentation. Presentations are spatial compositions. The content doesn't flow top-to-bottom like a document. It occupies specific positions within a visual framework. A bullet-point list exported to PPTX is not a presentation. It's a document pretending to be a presentation, and every audience member can tell.
Each content type's rendering pipeline has different inputs, different outputs, different quality criteria, and different failure modes. Combining them into one pipeline means optimizing for none of them.
The Engagement Divergence
Engagement tracking is where most platforms reveal that they don't actually treat content types differently.
A proposal's engagement data is rich and predictive. Page-by-page reading patterns reveal buyer intent. A prospect who reads pages 1-3 and skips to the pricing page is in a different buying mode than one who reads every page in order. Session duration, stakeholder count, and return-visit frequency all correlate with close probability. This data feeds the pipeline and informs follow-up strategy.
A contract's engagement data is binary and sequential. Was it viewed? Was it signed? If signed, when? The intermediate steps (how long someone spent on the indemnification clause) aren't commercially meaningful. They're legally interesting but they don't change how the deal progresses.
A presentation's engagement data is per-slide and diagnostic. Which slides got attention? Which got skipped? If the prospect spent 4 minutes on the architecture slide and 10 seconds on the team slide, that's a signal about what matters to them. This data restructures the next conversation.
Three content types, three engagement models, three sets of commercial implications. A platform that tracks "was this document opened?" for all three is leaving most of the signal on the table.
The Security Dimension Nobody Discusses
Different content types have different security requirements, and this is the dimension that gets ignored most consistently.
A proposal can be shared broadly. It's a marketing document. The more people who see it, the better. Generous sharing permissions and easy forwarding are features, not bugs.
A contract contains negotiated terms, pricing concessions, and liability positions. It should be shared narrowly. Download restrictions, watermarking, and audit trails matter. A contract that gets forwarded to the wrong person at the client's organization can create legal exposure.
An RFP response contains competitive intelligence: your pricing strategy, your technical approach, your differentiation story. It enters the client's internal systems where you have zero control over who sees it. The security model isn't about restricting access (you can't). It's about not including information that shouldn't survive outside a controlled context.
One security model for all content types means either over-restricting proposals (which reduces their marketing value) or under-restricting contracts (which creates legal risk). Neither is acceptable. Content-type-specific security models let each type have permissions appropriate to its purpose.
The Universal Principle
The template fallacy isn't unique to document platforms. It shows up everywhere software tries to flatten distinct entities into a single abstraction.
CRM platforms do it with "activities." A phone call, an email, a meeting, and a site visit are all "activities" with a type field. But a phone call has duration. An email has recipients and threading. A meeting has attendees and a location. A site visit has travel logistics. Flattening them into one table means losing the data that makes each one useful.
E-commerce platforms do it with "products." A digital download, a physical product, a subscription, and a service engagement are all "products." But they have different fulfillment pipelines, different revenue recognition, different return policies, and different inventory models.
The pattern is always the same: a team builds a general-purpose abstraction to avoid complexity, then spends the next three years adding if (type === 'X') branches everywhere until the "simple" abstraction is harder to maintain than separate systems would have been.
First-class treatment costs more upfront. Separate prompt modules, separate rendering pipelines, separate engagement models. More code. More testing. More architectural decisions.
But it costs less over time. Because each content type evolves independently. When you need to add DocuSign anchor tags to contracts, you change the contract rendering pipeline. The proposal pipeline is untouched. When you need to add per-slide analytics to presentations, you change the presentation engagement model. The contract engagement model is untouched.
Separate systems that share a data model scale linearly. A single system with type-branch spaghetti scales exponentially. In the wrong direction.
A proposal is a love letter. A contract is a prenup. An execution item is the blueprint. The architecture should know the difference before the first word is generated.
The takeaway: A proposal is a love letter, a contract is a prenup, an execution item is the blueprint: each content type needs its own AI personality and engagement model because the definition of "good" is fundamentally different for each.
References
1. Proposify. (2023). "State of Proposals." Annual Benchmark Report. 2. Loopio. (2025). "RFP Response Benchmark Report." Annual Survey Data. 3. Bidara. (2026). "RFP Statistics 2026." Research compilation. 4. Architecture Library #5: "The Client Template Is Sacred." The Architecture Series. 5. Architecture Library #4: "Constrained Generation." The Architecture Series.
This paper is part of The Architecture Series by Ed, Founder & CEO of DealiOS. For the weekly series and more technical deep-dives, visit dealios.app/library.
See how these principles come together. Explore the platform →