Policy Publishing & Legal Proof Guide

Two questions answered here:

1. Which documents go public on webility.local/legal — and which stay private?
2. How do you prove what your policies said on the day a client signed?

Part 1 — What Goes Public vs. What Stays Private

Public — Lives on webility.local/legal

These are policies that govern your relationship with anyone who uses your website or services. They must be publicly accessible before you reference them in any contract.

A /legal hub page at webility.local/legal links to all of the above. This is the single URL you put in contracts.

Private — Never Posted Publicly

These documents are confidential to specific client engagements or internal operations.

Semi-Public — Available on Request

These can be shared with prospects/clients who ask but are not posted openly:

Part 2 — The Real Problem: Proving What the Policy Said

Here is the exact dispute scenario you're protecting against:

Client scenario: You update your Refund Policy in March. A client signed in January. In April they dispute a charge and claim: "Your refund policy is different from what it said when I signed — you changed it after."

Or worse:

Fraudulent client scenario: "I never saw any policy. There was nothing at that URL when I signed. You can't hold me to it."

You need to be able to prove — with a timestamp — exactly what your policy said on the exact date they signed.

Part 3 — The Proof System (5 Layers)

Use all five. Each one is evidence. Together they're airtight.

Layer 1: Version Numbers in Every Policy (Already Done)

Every policy document already has a Document ID with a version number:

WBL-POL-TOS-v1.0
WBL-POL-PP-v1.0
WBL-POL-RCP-v1.0

And your contracts reference the URL — but they should also reference the version:

Instead of:

"...subject to Webility's policies at webility.local/legal"

Write:

"...subject to Webility's published policies (currently: Terms of Service v1.0, Privacy Policy v1.0, Refund Policy v1.0, IP Policy v1.0, AUP v1.0), available at webility.local/legal. Effective versions at time of contract signing are recorded in Webility's policy archive."

This pins the version number in the signed document itself. If a client later claims the policy changed, you point to the signed contract which names the version.

Layer 2: Git History — Your Best Proof (Already Set Up)

This is the most powerful tool you already have and probably don't realize.

Every policy document in this repo is tracked by git. Every commit has:

• An exact timestamp (to the second)
• The full content of the file at that moment
• Who made the change
• A commit message explaining the change

To prove what your Terms of Service said on January 15, 2026:

git log --all -- docs/legal/policies/terms-of-service.md
# Shows every commit that touched this file with timestamps

git show abc1234:docs/legal/policies/terms-of-service.md
# Shows the exact content at commit abc1234

Git commits are cryptographically signed with SHA hashes — they cannot be backdated or altered without detection. A court can subpoena git history. It is legitimate evidence.

What this means for you:

• Never directly edit a policy without committing the change with a clear message
• Use commit messages like: "Update Refund Policy v1.0→v1.1: added Section 3.4 on maintenance cancellation - 2026-03-01"
• Keep the repo in a hosted service (GitHub, GitLab, Bitbucket) — the remote timestamps are independent of your local machine

Layer 3: Policy Archive — Frozen PDFs at Signing

When you send a contract for signature, simultaneously generate PDF snapshots of all referenced policies and store them in the client's project vault.

Process:

1. Client is about to sign the contract
2. Before sending: print-to-PDF each policy page from your live website
3. Name the files: WBL-POL-TOS-v1.0-SNAPSHOT-2026-01-15.pdf
4. Store in the client's project folder: [CLIENT-CODE]/legal/policy-snapshots/
5. These snapshots are your "as of signing" record

You never need to send these to the client. They live in your files. If a dispute arises 18 months later, you pull the snapshot.

Time required: 3 minutes per contract. Worth it.

Layer 4: Internet Archive — Automatic Third-Party Record

The Internet Archive (web.archive.org) crawls websites and stores timestamped snapshots. This is a third-party record independent of you — which makes it particularly valuable as evidence because you couldn't have altered it.

Active steps:

1. Submit your policy pages manually at web.archive.org/save — enter each URL and save it. Do this when you first publish your policies, and every time you update them.

2. Verify the snapshots exist: Go to web.archive.org/web/*/webility.local/terms to see all archived versions.

3. Before updating any policy: First visit the current page and save it to the Archive so there's a record of the version before your change.

Using it in a dispute:

"Here is the Internet Archive record from [DATE] showing the exact text of our Refund Policy on the day you signed. The URL is: web.archive.org/web/20260115143000/webility.local/refunds"

The Archive's timestamps are completely outside your control — a client cannot argue you fabricated them.

Layer 5: DocuSign / E-signature Audit Trail

Every contract signed through DocuSign (or HelloSign/PandaDoc/Adobe Sign) generates an audit trail certificate that records:

• When the envelope was created
• When each email was sent to the signer
• When the signer opened the document
• What IP address they used
• When they signed each field
• A cryptographic hash of the document

This audit trail is stored permanently by DocuSign and is admissible evidence. The document is locked at signing — neither party can alter it after.

Best practice: Attach the policy snapshot PDFs (Layer 3) to the DocuSign envelope as additional documents. The signer doesn't need to sign them — they just need to be in the envelope. DocuSign's timestamp then proves the policies existed in that form on the signing date.

In DocuSign this is called a "non-signing attachment" — the client sees the policies are attached, and the envelope timestamp covers all documents.

Part 4 — What Happens When You Update a Policy

This is critical. You will need to update policies over time. Here's the protocol:

The Update Process

Policy Update Notification

Your policies already include a clause like:

"We may update this Policy. We will notify you of material changes by [email / website notice] with [30] days' advance notice."

For clients mid-engagement: email them directly with:

• What changed
• Why
• Effective date
• Link to the new version

Keep a record of that email. It's proof of notice.

For past clients whose projects are closed: post a notice on the website. You're not obligated to email them for non-material updates, but you should for material ones.

The Grandfather Rule

Changes to your policies do not retroactively change the terms of signed contracts. A client who signed when your Refund Policy said "50% refund if cancelled within 7 days" is entitled to that, even if you later change it to "no refund after signing."

This is why the version reference in the contract is so important — it freezes their rights at the version in effect when they signed.

Part 5 — The Policy Changelog

Add this section to the bottom of each policy document. Update it every time the policy changes.

---

## Policy Changelog

| Version | Date | Summary of Changes |
|---------|------|--------------------|
| v1.0 | 2026-02-19 | Initial publication |
| v1.1 | [DATE] | [Brief description of what changed] |
| v1.2 | [DATE] | [Brief description] |

This changelog is visible on your website. It shows clients — and courts — that you maintain careful records of policy history. It also signals professionalism.

Part 6 — Putting It Together: The Signing Workflow

This is the exact process to follow every time you send a contract:

CONTRACT SIGNING WORKFLOW
──────────────────────────────────────────────────────────

Step 1: Prepare the contract
  → Fill in all client-specific fields
  → Reference the current policy version numbers in the incorporation clause
  → Example: "...per Webility's policies (ToS v1.0, Privacy v1.0, Refund v1.0,
    IP Policy v1.0, AUP v1.0) at webility.local/legal"

Step 2: Snapshot the policies (3 minutes)
  → Print-to-PDF each policy page from your live website
  → Name: WBL-POL-[TYPE]-v1.0-SNAPSHOT-[YYYY-MM-DD].pdf
  → Store in: [CLIENT-CODE]/legal/policy-snapshots/

Step 3: Send via DocuSign / e-signature tool
  → Upload the contract as the main document
  → Attach the policy snapshots as non-signing attachments
  → Set up signature fields for the client
  → Send

Step 4: Archive to Internet Archive
  → Go to web.archive.org/save
  → Save: webility.local/terms
  → Save: webility.local/privacy
  → Save: webility.local/refunds
  → Save: webility.local/ip-policy
  → Save: webility.local/aup
  (takes 2 minutes — do it once at launch, then after each policy update)

Step 5: After client signs
  → DocuSign sends you the signed PDF with audit trail certificate
  → Store the signed contract + audit trail in: [CLIENT-CODE]/legal/signed/
  → Store the policy snapshots in: [CLIENT-CODE]/legal/policy-snapshots/
  → Done — you are fully protected

──────────────────────────────────────────────────────────
Total extra time: ~5 minutes per contract
Total protection: airtight

Part 7 — If a Dispute Actually Happens

A client claims your policies weren't published, weren't accessible, or were different from what they agreed to:

Your evidence stack:

1. The signed contract — names the policy versions and confirms the client's agreement
2. DocuSign audit trail — proves the contract was delivered, opened, and signed on a specific date
3. Policy snapshot PDFs — shows the exact policy text on the signing date (stored in your files)
4. Internet Archive record — independent third-party timestamp of the page content
5. Git history — cryptographic proof of when the policy was created and what it said
6. Policy changelog — public record showing version history

If you have all five, you can respond to a client dispute with:

"Here is the signed contract (dated [DATE]) referencing Refund Policy v1.0. Here is the Internet Archive snapshot of webility.local/refunds from [DATE] confirming the published text. Here is the PDF snapshot stored in our records at signing. Our git history confirms this version was in place from [DATE] with no changes until [DATE]. We are happy to share the DocuSign audit trail confirming the contract was signed at [TIME] on [DATE]."

That response ends most disputes. The client has no counter-evidence.

Summary: Your Minimum Viable Setup

Total cost to be fully protected: ~$20/month (e-signature tool) + 1 afternoon of setup.

Webility — POLICY-PUBLISHING-AND-PROOF-v1.0 Internal reference — legal operations guide.