Paper Process

Evidence-gated enterprise sales workflows, without handing a robot the keys to your CRM.

Paper Process is a vendor-neutral TypeScript engine that calculates opportunity milestone eligibility from verifiable commercial-process evidence. It keeps that calculation separate from CRM mutation, outbound communication, contact creation, enrichment, countersigning, and waivers. Those actions are approval-gated by default.

Release status: public v0.1.0 reference release. The core engine, local stores, configuration schemas, secure generic webhook ingestion, synthetic examples, and credential-free reference adapters are implemented. Named-provider adapters and mappings are illustrative/reference-only, not production connectors. No hosted service or npm package is provided. See the release checklist and audit for unresolved production gaps.

See it in 42 seconds

Watch the full-resolution silent walkthrough · Evidence gates · Human approval · No autonomous CRM writes

Why this exists

A rep-selected stage is an assertion. Paper and stakeholder activity can provide stronger evidence:

• an executed NDA can identify authorized legal and signatory participants;
• an explicitly accepted reference call can reveal stakeholders and validate fit;
• a current mutual action plan can show owners, dates, and dependencies;
• security, privacy, and commercial artifacts can expose the real approval path;
• an executed, correlated agreement bundle can support Closed Won.

Paper Process turns those observations into explainable gates. It does not assume every sale needs an NDA, reference call, RFI, DPA, SOW, or MSA. Applicability belongs in each organization's policy and, where needed, each opportunity.

flowchart LR
  S[Authorized source event] --> V[Verify integrity and freshness]
  V --> N[Normalize immutable event]
  N --> E[Derive evidence with provenance]
  E --> G[Evaluate configured gates]
  G --> X[Explain eligible, blocked, or review required]
  X --> P[Propose consequential action]
  P --> A{Exact payload approved?}
  A -- No --> H[Hold without mutation]
  A -- Yes --> M[Adapter may execute idempotently]

Loading

Who it is for

• CROs and VPs of Sales: define what pipeline stages must mean.
• RevOps and Sales Ops: map evidence-backed milestones to CRM stages and govern exceptions.
• Sales managers and AEs: see why a deal is eligible or blocked and what evidence is missing.
• GTM engineers: integrate authorized systems behind stable contracts and safe mutation boundaries.
• Legal, security, privacy, and reference-program owners: retain authority over their workflows.

What is implemented

Capability	Status
Typed events, evidence, workflows, evaluations, approvals, actions, contacts, waivers, and audit records	Implemented
Deterministic gate evaluation and contiguous highest-eligible milestone	Implemented
CRM current stage kept separate from calculated eligibility	Implemented
Exact-payload approvals, action transitions, idempotency helpers	Implemented
Hash-chained waiver audit records	Implemented reference implementation
In-memory and local SQLite stores	Implemented for local/reference use
Generic raw-body HMAC-SHA256 webhook verification, replay defense, normalization, dead letters	Implemented framework-neutral reference layer
Contact review queue before CRM creation or enrichment	Implemented in-memory reference layer
Salesforce, HubSpot, DocuSign, PandaDoc, Dropbox Sign, Signaturely adapters	Credential-free reference mocks only
Production API clients, hosted API/UI, durable queue, IAM, migrations, telemetry backend	Not implemented
Runnable local CLI and blocked-to-success synthetic SQLite demo	Implemented, credential-free
Public npm package or supported production service	Not released

Default lifecycle

The TypeScript default contains 11 milestones and 25 criteria. Labels and CRM IDs are mappings, not hard-coded assumptions.

flowchart LR
  D[Qualified discovery] --> NS[NDA sent]
  NS --> NC[NDA complete]
  NC --> RR[Reference ready]
  RR --> RA[Reference accepted]
  RA --> RC[Reference complete]
  RC --> V[Validation in progress]
  V --> SC[Security complete]
  SC --> C[Commercial ready]
  C --> K[Contracting]
  K --> W[Agreement executed]

Loading

Milestone	Default evidence intent	Important guardrail
Qualified discovery	Completed interaction, mutual interest, concrete next step	Transcript inference is not authoritative by itself
NDA sent	Approved version sent to configured party	Launching a workflow does not advance a stage
NDA complete	Verified/correlated version, required parties, configured countersignature	Provider completed alone is insufficient
Reference ready	Eligible match and reference-owner approval	Capacity, conflict, consent, and expiry apply
Reference accepted	Approved request, explicit acceptance, scheduled call	Silence is not consent
Reference complete	Call occurrence, authorized outcome, next step	Calendar attendance is corroborating only
Validation in progress	Current MAP and reviewed seller-side RFI	Requirements should be conditional
Security complete	Applicable security, DPA, assurance, compliance evidence	This project does not make legal/security decisions
Commercial ready	Current MAP, approved proposal, applicable SOW	Drafts and uncorrelated files do not qualify
Contracting	Required MSA/version sent and correlated	“Sent” is not “executed”
Agreement executed	Configured agreement bundle, correct parties/entity/version	This is the only default path to Closed Won eligibility

For a smaller, conditional deployment template, see examples/workflow/vendor-neutral.yaml.

Architecture

flowchart TB
  subgraph Sources[Authorized systems]
    CRM[CRM]
    DOC[Document or e-sign]
    MAIL[Email]
    CAL[Calendar]
    WF[Workflow]
  end
  Sources --> ING[Verifier and normalizer]
  ING --> EVT[(Immutable domain events)]
  EVT --> EV[(Evidence and provenance)]
  EV --> ENG[Deterministic evaluator]
  CFG[Versioned workflow and mappings] --> ENG
  WAV[Scoped waivers] --> ENG
  ENG --> RES[Evaluation and evidence snapshot hash]
  RES --> ACT[Approval-required action proposal]
  ACT --> APR[Exact-payload approval]
  APR --> PORT[Vendor-neutral adapter port]
  ING --> CQ[Contact review queue]
  EVT --> AUD[(Audit trail)]
  ACT --> AUD
  APR --> AUD
  WAV --> AUD

Loading

Core records stay distinct so replay does not create hidden side effects:

1. Events record what an authorized source reported.
2. Evidence records what a criterion may rely on and with what integrity/authority.
3. Evaluations explain eligibility, missing criteria, invalid evidence, and snapshot hash.
4. Approvals authorize an exact action payload under a policy version.
5. Actions represent proposed or executed consequences with idempotency.
6. Audit entries preserve decisions and exceptions.

Quick start

Requires Node.js 20+ and a native build toolchain supported by better-sqlite3.

git clone <repository-url>
cd paper-process
npm ci
npm run check
npm run build

Run the complete credential-free scenario:

npm run demo

Or inspect each operator step:

npm run cli -- init
npm run cli -- ingest --phase blocked
npm run cli -- evaluate
npm run cli -- replay
npm run cli -- ingest --phase success
npm run cli -- evaluate
npm run cli -- actions
npm run cli -- contacts
npm run cli -- audit
npm run cli -- reset --yes

The default SQLite database is .paper-process/demo.sqlite; use npm run cli -- --db /tmp/paper-process-demo.sqlite <command> to select another path. evaluate computes contiguous eligibility and may write an approval_pending exact-payload proposal, but no CLI command executes it. All demo contacts stay in review. No command contacts a service.

npm run check runs formatting, ESLint, strict TypeScript, Vitest, example-schema validation, documentation-link checks, and secret/private-data scans. The latest adversarial findings and residual production gaps are in AUDIT.md. See:

• Installation
• 15-minute local CLI walkthrough
• Configuration examples
• v0.1.0 release notes
• Release checklist
• Security policy
• Support
• Governance
• Changelog

Safe adoption modes

flowchart LR
  A[Audit only] --> R[Recommendations]
  R --> G[Approval gated]
  G --> N[Narrow automation]

Loading

1. Audit only: compare computed eligibility with CRM state; write nothing.
2. Recommendations: show missing evidence and proposed next steps.
3. Approval gated: permit exact, role-authorized proposals after review.
4. Narrow automation: automate only proven, low-risk actions with rollback, monitoring, and policy ownership. Legal signature authority must never be inferred.

Do not start in mode four. See the enterprise rollout checklist.

Adapter pattern

Adapters declare truthful capabilities, normalize events, and return approval-required proposals. Reference mocks do not hold credentials and do not call vendor APIs.

interface CrmAdapter extends EventNormalizer {
  proposeStageUpdate(opportunityId: string, stageId: string): ProposedMutation;
  proposeContactCreation(candidate: ContactCandidate): ProposedMutation;
}

Production integrations must add provider-specific verification, durable replay claims and dead letters, least-privilege credentials, rate-limit handling, retries, observability, and contract tests. Read Adapter extension contract, CRM mapping, and e-sign webhooks.

Privacy and security posture

• Preserve exact raw webhook bytes and verify before parsing.
• Reject stale, unsigned, invalid, and replayed requests.
• Use tenant-scoped IDs and idempotency keys.
• Store metadata, hashes, and access-controlled source references by default, not full contracts or message bodies.
• Queue observed stakeholders as review_pending; observation is not consent.
• Keep CRM association and enrichment as separate approved decisions.
• Bind approvals to exact payload hash, action, policy version, approver role, and expiry.
• Keep connected systems authoritative for legal files and operational CRM state.

The in-memory replay, dead-letter, and contact queues are demo stubs, not durable production controls. Review the threat model, production deployment guide, and observability guide.

Configuration map

Concern	Starting point
Conditional workflow	examples/workflow/vendor-neutral.yaml
Salesforce / HubSpot stages	examples/mappings/
Webhook normalization	examples/mappings/docusign-style-webhook.yaml, pandadoc-style-webhook.yaml
Approval and separation of duties	examples/policies/approval-policy.yaml
Stakeholder review	examples/policies/stakeholder-contact-review.yaml
Reference governance	examples/policies/reference-customer-registry.yaml
MAP/RFI and security review	examples/checklists/
Commercial evidence	examples/evidence/commercial-event-rules.yaml
Machine-readable validation	schemas/examples/

Operator guides

• Installation
• 15-minute local walkthrough
• Production deployment
• CRM stage mapping
• E-sign webhook ingestion
• Reference-customer operations
• Stakeholder discovery and review
• MAP/RFI operations
• Security and compliance review
• Observability
• Threat model
• Enterprise rollout checklist

Roadmap

Before production use:

• durable PostgreSQL persistence, migrations, transactional outbox, and queueing;
• authenticated API and role/tenant authorization;
• production-grade secret management and provider-specific webhook verifiers;
• official-provider API clients with contract and sandbox tests;
• OpenTelemetry traces/metrics, structured redacted logs, alerting, and runbooks;
• evidence invalidation/regression review and disaster-recovery tooling;
• privacy retention/deletion controls and security review;
• release packaging, compatibility policy, and public maintainer approval.

See SPEC.md for requirements and DECISIONS.md for the design record.

Origin, independence, and trademarks

The product thesis comes from Josh Gillespie's founder-supplied experience: a decade in enterprise sales leadership and more than $10M in personal ARR bookings. That background informed the operating problem; it is not an independently audited performance claim and does not make this project authoritative for every sales process.

Paper Process is an independent, methodology-neutral project. It frames Paper Process as a dimension commonly used in MEDDPICC practice; it does not define MEDDPICC or claim a universal, owned definition. MEDDPICC and vendor names are third-party marks. Their mention does not imply affiliation, sponsorship, certification, or endorsement.

This repository contains operational examples, not legal, security, privacy, or compliance advice.

Contributing and license

Read CONTRIBUTING.md and CODE_OF_CONDUCT.md. This project is licensed under Apache-2.0.