Statement of Work

The Statement of Work (SOW) captures the formal scope of the project: what will be delivered, by when, under what acceptance criteria, and at what cost. Where the CONOPS is narrative, the SOW is contractual.

In Ngenaire a SOW is a versioned document of ordered sections. Requirement codes you type into the text trace automatically, highlighted spans become traceable SOW objects, and approved versions lock so the signed scope can't drift.

Location: /system-definition/sow (sidebar: Define → SOW).

What a SOW contains

Sections — an ordered outline (scope, deliverables, milestones, acceptance criteria, assumptions, exclusions, pricing, …), each with a rich-text body.
Version — every SOW carries a version; approving or baselining locks it and Revise opens the next one.
Auto-traced requirement references — REQ-codes in the text link to those requirements automatically.
SOW objects — highlighted spans promoted into coded, traceable annotations.

Walkthrough

1. Open the SOW

In the sidebar click Define → SOW. The page lists SOWs for the project. Click one to edit, or create a new one.

2. Author the sections

Add and order the sections your SOW needs and write each section's body in the rich-text editor. Edits save as you work.

3. Generate a draft with AI

Use Generate with AI to have the AI Assistant produce a full SOW draft from the project's requirements and artifacts, or regenerate a section to redraft just one. When regenerating, you can ask for prescriptive language (firm "shall"-style contractual wording). Always review AI output before promoting the document.

4. Auto-traced requirement references

Any requirement code written into a section's text (for example a REQ-000029 in an Applicable Documents table) is auto-detected and traced to that requirement when the section is saved or drafted. These automatic links surface the SOW as a node in the Network View, connected to each requirement it cites. Removing a code from the text drops its auto link.

5. Create SOW objects from highlighted text

Select any phrase in a section and promote it to a SOW object — a coded, traceable annotation. Give it a type/label, optionally link requirements, and save. The selection is marked in the text; click a highlight to edit or delete it.

Each object gets a derived code such as SOW_GPC_000001, where the middle part is an acronym the AI derives from the SOW title and reuses for every object in that SOW (falling back to the SOW's number if AI is unavailable). Objects that link requirements appear in the Network View as sow_object nodes, edged to those requirements and to their parent SOW.

6. Export

Use Export to produce the SOW as markdown or PDF.

Version history

Each save is captured in the version history. Open the Versions drawer to browse versions by date and editor, Compare two versions side-by-side, and Restore an earlier one.

Baseline lock and revising

Promoting a SOW to Approved or Baselined freezes it: the content becomes immutable, the editor goes read-only, and Save is replaced by Revise. This is intentional — once a SOW is signed off it is the contractual reference, so it can't be edited in place.

To work on a new version of a locked SOW, click Revise:

A dialog opens prefilled with the next version (e.g. 1.3 → 1.4); override it for a major bump (e.g. 2.0) if needed.
On confirm, the current baseline is snapshotted into version history (always viewable and restorable from the Versions drawer), the version is bumped, and the status returns to Draft so it is editable again.
Edit the new draft, then re-promote to Approved/Baselined when ready.

If you don't have edit rights, a project editor must Revise the SOW for you.

Tips

Let codes do the tracing. Cite requirements by their REQ-code in the prose and the trace links create themselves.
Keep deliverables granular. Each deliverable should map to specific requirements and verifications.
Cross-reference the CONOPS. A change to operational scope should trigger a review of both documents.