You are writing an original LinkedIn Document Ad for a B2B company. The inspected reference below is a structural example, not permission to copy its words, branding, statistics or conclusions. Work from the user inputs and label every assumption.

REFERENCE INSPECTED
Atlassian and DZone native Document Ad, LinkedIn Ad Library 1580985156, captured 2026-09-23. Its Getting Started With DevSecOps reference card opens with a dense contents/introduction, then a Security Then vs. Now table and framework references. Page 3 continues framework rows and lifecycle integration points. Fine body text was not transcribed. Only three preview pages were inspected; gate and ad results are unknown. Borrow the comparison idea, but do not shrink dense reference-card pages into a feed preview.

USER INPUTS TO COLLECT OR USE
Company and offer: [ ]
Specific buyer and buying situation: [ ]
One document promise and desired next action: [ ]
Source material with URLs/files, dates and publication permission: [ ]
Approved customer names/quotes/figures, if relevant: [ ]
Available format: source report, checklist, case, survey or guide: [ ]
Free reading or Lead Gen Form, and why: [ ]
Asset/thank-you URL, privacy URL, CRM owner and follow-up sender: [ ]
Brand constraints and preferred page count: [ ]

SPECIFIC ASSIGNMENT
Create a short feed edition and a separate full-guide outline. Give one before/after contrast per preview page, a simple lifecycle diagram and a task the reader can try. Put framework citations and configuration detail in the full guide. Use the buyer’s terminology accurately; never invent a compliance guarantee.

WORKED PATTERN, CLEARLY HYPOTHETICAL
Hypothetical cloud security team: cover “Secrets handling: before and after.” Page 2 contrasts “Credential pasted into a ticket” with “Short-lived access issued from a vault.” Page 3 shows request, approve, issue, revoke. A longer guide would hold implementation details and cited framework references.

MISSING-INPUT RULE
If material is missing, ask up to three focused questions, then continue with a clearly labeled draft using bracketed placeholders. Do not invent a business fact, customer, quote, survey result, performance rate, source, permission or link. If the core proof is absent, give a non-numeric/process alternative and mark evidence-dependent pages “not ready to publish.” Do not claim the inspected advertiser used a gate or achieved a result.

OUTPUT CONTRACT
1. State the buyer, one-sentence document promise, why this format fits, and the proposed free/gated choice. Separate what is known from assumptions.
2. Give a complete 6–8-page document. For EVERY page provide a page number, exact headline and body copy ready to paste, what the reader learns, layout instructions that work at phone width, and the source/approval needed for each factual claim. Pages 2–3 must fulfill part of the cover promise, not just introduce the company. Mark the proposed preview boundary and show what remains after it. Do not fill pages with slogans or generic benefits.
3. Write the sponsored intro (aim under 150 characters where possible), a concise headline, and a plain-text end CTA. Make their promises match the document.
4. If gated, specify minimal form fields, the privacy URL placeholder, the exact confirmation message, full-asset URL placeholder, CRM routing owner and a test submission. If free, explain how a reader gets the PDF and what next action is offered. Do not assert that PDF links work inside the LinkedIn feed; print essential URLs visibly and test after download.
5. Write one delivery email or follow-up message that refers to a specific page. Distinguish an educational download from a request to speak with sales.
6. Finish with an evidence/permission checklist, a PDF-export and mobile-readability checklist, and three things to inspect after launch: page consumption, successful delivery, and qualified next steps. No invented benchmarks.
Return actual copy and page layouts, not advice about what someone could write.