Governed Project Documentation — Deliverables, SOWs, Change Orders, and Project Records — with Lifecycle Controls, Audit Trails, and Post-Project Archives on AWS
Every project generates documents. Statements of work, project plans, requirements documents, design specifications, meeting minutes, status reports, change orders, deliverable submissions, acceptance records, lessons learned, and closure reports — the project file is the authoritative record of what was agreed, what was delivered, what changed, and why. When a dispute arises, an audit is conducted, or a warranty claim is filed, the project file is the evidence.
Yet most project management platforms are built to manage tasks, timelines, and resources — not documents. Project documents end up as attachments to tasks, links to shared drive folders, or files emailed between project team members. There's no version control beyond "Final_v3_FINAL_revised.docx." No retention policy beyond "the project manager will archive it when the project closes." No access control beyond whoever has access to the project workspace. And no audit trail for document access.
FormKiQ provides governed document management for project documentation — deployed directly into your AWS account, with deliverable tracking, change order management, project file governance, and post-project archival retention. Project documents are classified, access-controlled, version-managed, and retained as governed records from the moment they're created — not retroactively filed when someone remembers to do it.
The Project Documentation Problem
Project management tools are designed to manage schedules and resources, not documents. This creates governance gaps that become visible when projects are audited, when deliverables are disputed, or when teams try to reference past project documentation:
| Challenge | What Goes Wrong | FormKiQ Resolution |
|---|---|---|
| Documents as attachments | Project documents attached to tasks or stored in linked shared drive folders with no independent governance | Documents stored as governed records within a structured project file — classified, version-controlled, and independently managed |
| No version control | Multiple versions circulate via email; no single source of truth for the current version of a deliverable or specification | Full version history with creation date, approval date, and supersession chain; current version always identifiable |
| No approval evidence | Deliverable acceptance, change order approval, and milestone sign-off happen in email or verbal agreement — no auditable record | Approval workflows with audit-logged decisions, approver identification, and timestamps |
| No retention policy | Project files either retained forever (growing storage costs) or deleted when the project manager moves on | Configurable retention policies triggered by project closure date, with automated archival and defensible disposition |
| Scattered documentation | Project documents spread across the PM tool, shared drives, email, and personal folders | Single governed project file with all project documents classified and searchable |
| No access control after closure | Closed project files either locked entirely or remain open to everyone who had project access | Configurable post-closure access — restricted to specific roles (legal, audit, project archive administrator) while remaining searchable and producible |
| No audit trail | PM tools log task changes, not document access; no record of who viewed, downloaded, or modified project documents | Document-level audit trail recording every access, modification, and lifecycle event |
The Project Document Lifecycle
Project documents follow a lifecycle tied to the project itself. FormKiQ manages each phase:
| Lifecycle Phase | Documents Created or Collected | Governance Applied |
|---|---|---|
| Initiation | Business case, project charter, feasibility studies, stakeholder analysis, initial risk assessment | Classification, approval workflows, version control, access restricted to project sponsors and leadership |
| Planning | Statement of work, project plan, requirements documents, design specifications, resource plans, risk management plans | Version control, multi-stakeholder review and approval workflows, baseline version identification |
| Procurement | RFPs, vendor proposals, evaluation scoresheets, vendor selection documentation, contracts, purchase orders | Vendor evaluation workflows, contract management integration, procurement audit trail |
| Execution | Deliverable submissions, progress reports, meeting minutes, status reports, technical documentation, test results | Deliverable acceptance workflows, progress documentation, version control for evolving documents |
| Change Management | Change requests, change impact assessments, change order approvals, revised specifications, budget amendments | Change request workflows with approval chains, version control linking changed documents to the change order that authorised them |
| Closure | Lessons learned, final deliverable acceptance, project closure reports, warranty documentation, handover records | Closure checklist workflows, final document collection, transition to post-project retention |
| Post-Project Archive | Complete project file retained per organisational and contractual requirements | Automated archival with configurable retention; cost-optimised S3 storage tiers; full search and audit trail retained |
Deliverable Management
Deliverable tracking and acceptance is where project documentation governance matters most — it's the evidence of what was promised, what was submitted, and whether it was accepted.
| Step | What Happens | FormKiQ Governance |
|---|---|---|
| Definition | Deliverable requirements defined in the SOW or project plan | Requirements document version-controlled and linked to the deliverable record |
| Submission | Contractor or team submits the deliverable | Document uploaded with deliverable metadata (deliverable number, submission date, version); intake audit-logged |
| Review | Designated reviewers evaluate the deliverable against acceptance criteria | Multi-reviewer workflows with role-based assignment; review comments captured in document history |
| Acceptance or rejection | Reviewers accept, conditionally accept, or reject the deliverable | Approval workflow with audit-logged decision, reviewer identification, acceptance criteria assessment, and timestamp |
| Revision | If rejected or conditionally accepted, the deliverable is revised and resubmitted | New version created; revision linked to the rejection reason and review comments; full version chain maintained |
| Final acceptance | Accepted deliverable becomes part of the official project record | Final version flagged as accepted; acceptance record linked to the deliverable; access restrictions may change post-acceptance |
Change Order Management
Change management is one of the most contentious areas of project documentation. Disputes over scope, budget, and timeline almost always come down to change documentation — what was requested, what was approved, and what the impact assessment said.
| Change Document | What It Contains | FormKiQ Governance |
|---|---|---|
| Change request | Description of the proposed change, reason, requested by, date submitted | Classification, metadata linking to the project and affected deliverables, intake audit trail |
| Impact assessment | Scope impact, schedule impact, cost impact, risk impact, resource impact | Version control; linked to the change request; review workflow |
| Change order approval | Approval or rejection decision with authorisation | Multi-level approval workflow (project manager → client → steering committee as appropriate); audit-logged with approver identification and timestamp |
| Revised documents | Updated SOW, specifications, plans, or budgets reflecting the approved change | New versions of affected documents created and linked to the change order; prior versions retained with full history |
The key governance requirement: every revised document must be traceable to the change order that authorised the revision. FormKiQ's metadata architecture supports this linkage — each document version records which change order drove the revision, creating a complete chain from change request through approval to document revision.
Post-Project Archival and Retention
Project archives are among the longest-lived document collections in many organisations — particularly for construction, infrastructure, engineering, and regulated projects where warranty periods, statute-of-limitations windows, and regulatory requirements extend years or decades beyond project closure.
Retention Triggers and Periods
| Project Type | Typical Retention | Retention Trigger | Driver |
|---|---|---|---|
| Internal projects | 3–5 years post-closure | Project closure date | Organisational policy, lessons-learned reference |
| Client service projects | 5–7 years post-closure | Project closure or final deliverable acceptance | Contractual requirements, professional liability, statute of limitations |
| Construction and infrastructure | 10–15+ years post-completion | Practical completion date or defects liability expiry | Building regulations, professional liability, latent defects exposure |
| Government contracts | 3–7 years post-closure or final payment | Contract completion or final payment | FAR/DFARS (US), government procurement regulations by jurisdiction |
| Grant-funded projects | 3–10 years post-closeout | Grant closeout date | Funder requirements (2 CFR 200, Tri-Agency, UKRI, EU Horizon Europe) |
| Regulated industry projects | Varies by regulation — up to 30+ years | Project completion or product lifecycle | FDA, nuclear regulation, environmental compliance, safety records |
Archival Storage Tiers
Project archives transition through S3 storage tiers automatically — remaining searchable and governed regardless of tier:
- Current and recent projects — S3 Standard for active access
- 1–3 years post-closure — S3 Infrequent Access for occasional reference and warranty claims
- 3–10 years post-closure — S3 Glacier Instant Retrieval for audit and dispute production
- 10+ years — S3 Glacier Deep Archive for long-term statutory retention
A ten-year-old deliverable archived to Glacier Deep Archive is still searchable by project, client, deliverable number, and acceptance status.
Access Control for Project Documents
| Access Layer | What It Controls | Example |
|---|---|---|
| Project team access | Documents visible to designated project team members based on role | Technical specifications visible to engineering team; financial documents restricted to project manager and finance |
| Client access | Client-facing documents accessible to designated client contacts | Client portal access to deliverables, approved change orders, and project correspondence — but not internal cost estimates or resource plans |
| Vendor / subcontractor access | Vendor documents visible to the relevant vendor without exposing other vendors' documentation | Each subcontractor sees their own SOW, deliverables, and correspondence |
| Confidentiality classification | Sensitive project documents restricted to authorised roles | Proprietary design documents visible only to cleared engineering team members |
| Post-closure access | Closed project files restricted to archive administrators, legal, and audit | Project team members lose write access at closure; legal retains read access for dispute reference |
Who Uses Project Management Document Management on AWS
| Industry | Project Document Challenges | Key Drivers |
|---|---|---|
| Construction and engineering | Multi-phase project documentation across design, procurement, and construction; long warranty periods; multi-party documentation | Building regulations, professional liability, latent defects exposure (10–15+ year retention) |
| Government and public sector | Procurement project files, infrastructure programme documentation, public accountability records | Government procurement regulations, public audit, legislative reporting |
| Technology and software | Client delivery projects, product development documentation, agile artefacts, release documentation | Client contract compliance, IP documentation, product liability |
| Professional services | Client engagement documentation, deliverable tracking, project financial records, lessons learned | Professional regulatory requirements, client audit support, engagement retention |
| Healthcare and life sciences | Clinical system implementation, research projects, facility projects, validation documentation | FDA validation requirements, research compliance, clinical system qualification |
| Energy and utilities | Capital projects, maintenance programmes, environmental compliance projects, decommissioning documentation | Environmental compliance, safety documentation, long-asset-lifecycle retention |
| Manufacturing | Product development projects, facility projects, process improvement programmes, supplier qualification projects | Quality compliance (ISO 9001), product liability, engineering change documentation |
FormKiQ Editions for Project Document Management
| Capability | Core | Essentials | Advanced | Enterprise |
|---|---|---|---|---|
| Document Storage (S3) & API | ✓ | ✓ | ✓ | ✓ |
| Tagging, Search & Classification | ✓ | ✓ | ✓ | ✓ |
| OCR (Tesseract) | ✓ | ✓ | ✓ | ✓ |
| OCR & IDP (Textract) | ✓ | ✓ | ✓ | |
| SSO (SAML — Entra, Google, Auth0) | ✓ | ✓ | ✓ | |
| Workflows, Queues & Rulesets | ✓ | ✓ | ✓ | |
| Encryption (KMS — in-transit & at-rest) | ✓ | ✓ | ✓ | |
| Document Control & Versioning | ✓ | ✓ | ✓ | |
| Antivirus & Anti-Malware | ✓ | ✓ | ✓ | |
| AI Processing & Analysis (Bedrock) | ✓ | ✓ | ||
| Document Generation | ✓ | ✓ | ||
| eSignature Integration | ✓ | ✓ | ||
| ERP / CRM Integration Frameworks | ✓ | ✓ | ||
| Document Gateway Modules | ✓ | ✓ | ||
| Enhanced Full-Text Search (OpenSearch) | ✓ | ✓ | ||
| Multi-Instance & Multi-Region Licensing | ✓ | ✓ | ||
| Vendor-Managed & Hybrid Deployment | ✓ | |||
| Custom SLAs & Compliance Consulting | ✓ | |||
| Support | Community (Slack & GitHub) | Support Portal (2-business-day SLA) | Private Slack + videoconference + 40 hrs onboarding | Rapid response (8-business-hour SLA) + strategic architecture support |
Deployment Models
| Model | Description | Availability |
|---|---|---|
| Customer-Managed AWS | Deploys directly into your AWS account via CloudFormation. Full control of infrastructure, networking, encryption keys, and operations. | All editions |
| Vendor-Managed | FormKiQ manages the AWS infrastructure on your behalf — deployment, updates, and operational support. | Enterprise |
| Hybrid | You retain control of specific components (encryption keys, network config) while delegating operational management to FormKiQ. | Enterprise |
Every deployment is a dedicated, isolated instance. FormKiQ does not operate a shared multi-tenant environment.
Getting Started
FormKiQ Core can be deployed to your AWS account in fifteen to twenty minutes. Project document management capabilities — including AI Processing, Document Generation, eSignature Integration, and ERP/CRM Integration Frameworks — are available on FormKiQ Advanced and Enterprise.
Frequently Asked Questions
Why not just use our project management tool for document management?
Project management tools manage tasks, timelines, and resources. They treat documents as attachments — uploaded to tasks or linked from shared drives with no independent version control, access controls, retention policies, or audit trail for document access. FormKiQ provides the governed document layer — every project document independently classified, version-controlled, access-managed, and retained. The two systems are complementary: the PM tool manages the work; FormKiQ manages the documents the work produces.
How does FormKiQ handle deliverable acceptance?
Deliverables submitted to FormKiQ are processed through configurable acceptance workflows — multi-reviewer evaluation against acceptance criteria, with approval, conditional acceptance, or rejection decisions audit-logged with reviewer identification and timestamps. Rejected deliverables are revised and resubmitted with full version history linking each revision to the review feedback that prompted it. The accepted version, its acceptance record, and the complete review history are all retained as part of the project file.
How does change order management work?
Change requests, impact assessments, and change order approvals are managed through structured workflows. When a change order is approved, revised documents (SOWs, specifications, budgets) are created as new versions linked to the authorising change order. This creates a complete chain: change request → impact assessment → approval decision → revised documents — all traceable and audit-logged.
What happens to project documents after the project closes?
FormKiQ transitions the project file to post-closure retention automatically. Retention periods are configured by project type — internal projects, client projects, construction projects, government contracts, and regulated projects each have different retention requirements. Documents archive to cost-optimised S3 storage tiers while remaining searchable and producible for warranty claims, dispute resolution, and audit.
Can clients and subcontractors access project documents?
Yes. FormKiQ's ABAC model supports external access — each client or subcontractor can view their own deliverables, contracts, and correspondence without access to other parties' documents or internal project records. Access can be configured by role, document type, and project phase. All external access events are audit-logged.
How does FormKiQ handle project documents across multiple projects for the same client?
FormKiQ's metadata architecture supports cross-project search. All projects for a specific client can be queried across project boundaries — finding all deliverables, all contracts, or all change orders across the client relationship. Individual project files maintain their own governance, but the metadata layer enables portfolio-level visibility when needed.