OpenKnowledge

Billing & Invoices

docs/billing-and-invoices.md · Updated today, 11:02 by Claude · Co-authored with you · main

Overview

Invoice generation, payment terms, and plan pricing live in this document. It is the source of truth for the billing squad and feeds the customer-facing help center.

Pricing tiers

Pricing tiers reflect the plan a customer selects at signup and can be changed at any time.

Pricing is the quietest promise we make to customers. Every tier should exist because a real customer told us they would use it — we price for outcomes, not seats. We would rather launch a slightly-too-expensive tier and grandfather early customers than paint ourselves into a corner. And we revisit pricing twice a year, out loud, with customers in the room.

PlanPriceForNotes
Free$0Solo evaluation3 seats · community support
Team$28 / user / mo Growing teams SSO · audit logs · 99.9% SLAremoved — merged into Pro
Pro$12 / user / mo Small teams Unlimited docs · priority support
Pro$12 / user / mo Small & growing teams Unlimited docs · priority support · SSO · audit logs · 99.9% SLA
EnterpriseCustomLarge orgsDedicated support · private cloud

Customers

Customer expectations are captured here so billing can route each account to the right workflow.

Billing is per-account, not per-user. Large accounts should email billing@pipeline.co to consolidate invoices under one master agreement instead of paying per seat.

Invoices generate on the 1st of each month and land with the billing contact on file. Payment is due net-30 from the invoice date.

Invoicing process

A default invoice runs: draft → finance review → send → follow-up. Dunning kicks in at day 45 with a polite email; at day 60, finance hops on a call.

Open questions

Things the billing squad is still deciding.

  • What credit does a grandfathered team get when Pro pricing changes?
  • Should usage-based billing ship before enterprise self-serve?
  • What's the SLA promise for the first 90 days?

Design rationale

docs/design-rationale.md · Created today, 14:30 by Yuanyuan · Co-authored with Claude · main

The problem

The core problem isn't showing diffs — it's helping every user, technical or not, answer four questions.

The core problem is not just showing diffs — it is helping both technical and non-technical users answer four questions.

What changed?
Why did it change?
Do I want to keep this change?
How can I easily recover if the AI made a mistake?

Principles

1

Keep the document as the primary experience

Users already understand documents (Notion, Google Docs). The goal is reviewing AI work, not learning a new review tool. Context matters — a change is meaningful only when seen in the surrounding content.

Design decision

The latest document remains the main canvas. Changes are surfaced inline when relevant, so users can inspect them without leaving their workflow.

2

Use progressive disclosure instead of showing all diffs at once

Displaying every change, comparison state, and metadata at once creates cognitive overload. Most users don't need to inspect every AI action — they need confidence that they can review the important changes.

Design decision

A lightweight indicator that AI made changes → enter review mode when you want details → before/after comparison only for the selected change. Technical users can drill deeper; non-technical users get a simple flow.

The top-bar pill is the only always-on signal — everything else stays hidden until you opt in.

3

Compare versions, not "AI vs Human"

Framing it as "Claude vs Yours" implies conflict. The AI should feel like a collaborator iterating with you — not a rival competing with you.

Framing the experience as "Claude vs Yours" implies conflict. The goal is collaboration — AI should feel like a collaborator making iterations, not another person competing with the user.

Design decision

Compare the latest version against the last reviewed version. The user decides which version represents the desired document state.

4

Make reviewing reversible

The key interaction is "Which version do you want to keep?" AI-generated content requires trust.

The key interaction is "Which version do you want to keep?" AI-generated content requires trust — users need a safe way to explore changes without fear of losing their original work.

Design decision

Users can switch between versions before committing. This creates confidence, control, and easy recovery.

5

Preserve editing continuity

AI editing should feel like a natural extension of writing, not a separate workflow with its own "Edit" mode.

Design decision

The document remains editable by default. Users can review AI changes, modify content, and save the final version — no mode split.

6

Use clear AI attribution

Users need to know something changed and who made it — but they don't need a large banner explaining AI behavior.

Design decision

Lightweight signals: "4 changes made by Claude", Claude avatar attribution, and blue indicators on documents with updates.

7

Support different document types

The same pattern extends beyond normal text documents — preview documents and code files included.

Design decision

One mental model everywhere: see what changed, review the differences, decide what to keep.

In one line

Design rationale

I designed the experience around AI trust and human control. Instead of overwhelming users with a traditional diff view, I kept the document as the source of truth, used progressive disclosure to reveal changes only when needed, and created a reversible review flow where users can understand, compare, and confidently accept AI-generated edits.

Onboarding

docs/onboarding.md · Updated today, 10:20 by Claude · Co-authored with you · main

Quick start

This guide walks a new workspace from signup to first published doc. Most teams are up and running in under an hour.

Invite your team

The workspace owner adds people, and every member shares the same plan.

Invite teammates with an email invite — they land on the same plan as the workspace owner, and their seats are billed from the workspace account.

Invite teammates from the People page. Every new member gets a free seat for 30 days before billing starts.

First project

Projects start in draft and get published to an audience folder.

Projects start in draft. Publish to docs/, engineering/, or a custom folder — the folder decides which audience sees it.

You can connect a GitHub repo and keep docs in sync with code; the docs build runs on every push.

FAQ

Common questions from new teams.

  • Can I cancel anytime? Yes — billing is monthly and you keep access until the end of the period.
  • Do you offer a student discount?
  • Is there a lifetime deal?

Help Center

docs/help-center.md · Updated today, 09:45 by Claude · Co-authored with you · main

Getting started

Everything you need to set up your first workspace.

  • How long does it take to index my docs? Usually under 2 minutes per repo.
  • What happened to the legacy search widget?

Accounts & billing

Invoices, plans, and how payments work.

Change it in Settings → Billing. Invoices are re-sent to the new address automatically; the old one is kept on file for compliance.

Send a request to support@ and we will update it within 2 business days.

Troubleshooting

Stuck on something? Start here.

Why is my sync stuck on "Waiting"? A sync stays Waiting when the connected repo is paused or a concurrent build is running. Re-trigger it from the repo page, or wait for the build to finish.

If it is still Waiting after 15 minutes, check the repo's access token — a revoked token pauses all syncs silently.

API Architecture

engineering/api-architecture.md · Updated today, 14:05 by Claude · Co-authored with you · main

Authentication

Every API request must carry a valid credential.

Requests are authenticated with a bearer token scoped to a project. Rotate tokens from the Dashboard; tokens are hashed at rest and never returned again after creation.

Use an API key sent as a query parameter. Keys never expire and can be shared across the team.

Rate limits

Requests are limited per project, not per key.

PlanRequestsBurst
Free60 / min120
Pro1,000 / min2,000
Pro2,000 / min5,000
EnterpriseCustomCustom

Webhooks

Event delivery for integrations.

Subscribe to doc.published, doc.reviewed, and build.failed events. Payloads are signed with an HMAC secret you set in the Dashboard; redelivery retries 5 times with exponential backoff.

Dashboards

engineering/dashboards.md · Updated today, 16:40 by Claude · Co-authored with you · main

Metrics

Every dashboard is a saved query over the events pipeline.

Every dashboard is a saved query. Metrics are computed from the events pipeline with a 5-minute freshness window, so dashboards reflect near-real-time data.

Dashboards refresh every 15 minutes on a cron. To see fresher data, refresh the page.

Charts

The building blocks of every dashboard.

P95 response time is now tracked per route and per region. Use it to spot slow regions before they show up in error rates.

Filter any chart by region, plan, or workspace size with a single click.

Release Spec

engineering/release-spec.md · Updated today, 17:22 by Claude · Co-authored with you · main

Rollout plan

How a release moves from canary to full traffic.

Ship to a 10% canary for 24h, then 50% for another 24h, then full. Canary windows exist to catch issues before a full rollout, and the schedule is a floor, not a ceiling — hold any stage if metrics look off.

Deploy to prod on Tuesday. Monitor for an hour. If nothing breaks, we are done.

Checklist

Required steps before each release.

  • Verify log streaming works from the new region
  • Manually run the legacy export script
  • Ping the #releases channel for sign-off

Rollback

Automatic and manual rollback criteria.

Rollback is a re-deploy of the previous tagged image with a 10-minute TTL. If the error rate crosses 1.5% for 5 consecutive minutes, on-call rolls back automatically.

Changelog

docs/changelog.md · Updated yesterday · main

This week

  • P95 response time is now tracked per route and region
  • Faster sync for repos with more than 10k docs
  • Settings → Billing shows the next invoice date

Incident Playbook

engineering/incident-playbook.md · Updated last week · main

Severity levels

SEV-1: the service is down for a wide audience. SEV-2: degraded but usable. SEV-3: an isolated incident with a workaround.