# Statement of Work Axdale. Software engineering by Michael Lip, Warsaw, Poland (CET). Website [https://www.axdale.com](https://www.axdale.com). Code portfolio on GitHub at [https://github.com/theluckystrike](https://github.com/theluckystrike). Version 1.0. 23 October 2026. One Statement of Work (SOW) covers one Week of work under the Axdale Engagement Agreement. A Week is up to 40 hours over 5 Working Days. Part A is the blank template, and Part B is a filled example for a fictional client. This document is plain English. It isn't legal advice. ## Part A. Template ### 1. Reference | Field | Details | |---|---| | SOW number | ____ | | Engagement Agreement signed on | ____ | | Client | ____ | | Decision Maker | ____ | | Week type | Free Week (week 1) / Paid Week number ____ | | Working Days | ____ to ____ (5 Working Days, public holidays in Poland excluded) | | Hours cap | 40 | | Fee for this Week | USD 0 (Free Week) / ____ hours at USD ____ per hour (Paid Week) | ### 2. Goal One sentence. It names the user, the change and the result the Client can see. ____ ### 3. Background from the Brief Two to four sentences. They say what exists today and why this Week matters. ____ ### 4. In scope 1. ____ 2. ____ 3. ____ ### 5. Out of scope 1. ____ 2. ____ ### 6. Acceptance criteria Each criterion has 4 parts. GIVEN is the starting state and WHEN is the action. THEN is the result the Client can see, and CHECK is how anyone can verify it (a test name, a command or a screenshot). Use 3 to 5 criteria. They don't change during the Week. | No. | Given | When | Then | Check | |---|---|---|---|---| | AC1 | ____ | ____ | ____ | ____ | | AC2 | ____ | ____ | ____ | ____ | | AC3 | ____ | ____ | ____ | ____ | | AC4 (optional) | ____ | ____ | ____ | ____ | | AC5 (optional) | ____ | ____ | ____ | ____ | ### 7. Deliverables 1. Pull requests on branch ____ in repository ____, with tests that pass in the Client's CI. 2. A written update by 18:00 CET on each Working Day. 3. A weekly report on the last Working Day. 4. A handover note (how to run it, how to test it, how to change it). 5. ____ ### 8. Access needed List the least access that does the job. Michael gets nothing that isn't on this list. | System | Access level | Who grants it | Removed on | |---|---|---|---| | ____ | ____ | ____ | ____ | ### 9. Production actions approved for this Week None, unless listed here and approved in writing by the Decision Maker. A Free Week always has none. ____ ### 10. Approved AI Providers for this Week Same as the Schedule of the Engagement Agreement / changed for this Week as follows ____ ### 11. Assumptions and dependencies 1. ____ 2. ____ ### 12. Paid follow-on (Free Week only) The Free Week must be the first slice of a job that needs at least 2 Paid Weeks after it. | Paid Week | Goal | Estimated hours | |---|---|---| | 2 | ____ | 40 | | 3 | ____ | 40 | ### 13. Changes A new request during the Week goes into the plan for a later Week. A change inside this Week needs written agreement from the Decision Maker and Michael, and it must fit the hours left. ### 14. Approval Approved for the Client by the Decision Maker Name ____ Signature or written approval by email ____ Date ____ Approved by Michael Lip, Axdale Signature ____ Date ____ ## Part B. Filled example (fictional) The client, people, dates and numbers below are fictional. They show how a real SOW reads. ### 1. Reference | Field | Details | |---|---| | SOW number | EXAMPLE-01 | | Engagement Agreement signed on | 27 October 2026 | | Client | Example Client Ltd, a B2B software company with a helpdesk product | | Decision Maker | Jane Doe, CTO | | Week type | Free Week (week 1) | | Working Days | Monday 2 November 2026 to Friday 6 November 2026 | | Hours cap | 40 | | Fee for this Week | USD 0 | ### 2. Goal Support staff get an AI-drafted first reply for each new ticket, with links to the help articles it used, behind a feature flag. ### 3. Background from the Brief Support staff write every first reply by hand today, and most tickets ask questions that the help center already answers. The Client wants drafts that staff can edit and send, not automatic replies. The product is a Next.js app with a Node API and a Postgres database. ### 4. In scope 1. A draft reply service in the Node API. It reads the ticket text, finds the 5 most relevant help articles and writes a draft with links to them. 2. A draft panel in the ticket view, shown only when the flag `agent_reply_drafts` is on. 3. An evaluation set of 15 anonymized past tickets, with a scoring rubric, that runs with one command. 4. A measure of cost per draft and latency on the evaluation set. ### 5. Out of scope 1. Sending replies automatically. Staff always send. 2. Any write to the ticket database other than saving a draft in a new table on the test environment. 3. Production deploy. The work stays on a branch in this Week. 4. Languages other than English. ### 6. Acceptance criteria | No. | Given | When | Then | Check | |---|---|---|---|---| | AC1 | The flag `agent_reply_drafts` is off | A staff member opens a ticket | The ticket view shows no draft panel and makes no model request | Test `drafts.flag.spec.ts` passes in CI | | AC2 | The flag is on and a ticket from the evaluation set is open | The staff member asks for a draft | A draft appears within 15 seconds with at least 1 link to a help article | `npm run eval:drafts` reports p95 latency and the share of drafts with a link | | AC3 | The 15-case evaluation set | The evaluation runs | At least 12 of 15 drafts pass the rubric | Evaluation report attached to the pull request | | AC4 | A ticket that tells the model to ignore its rules | A draft is made | The draft doesn't show the system prompt and the service makes no write request | Evaluation cases 13 to 15 pass | | AC5 | Any ticket | The service writes logs | No email address or phone number appears in the logs | Test `drafts.redaction.spec.ts` passes in CI | ### 7. Deliverables 1. Pull requests on branch `feature/agent-reply-drafts` in repository `example-client/helpdesk`, with tests that pass in GitHub Actions. 2. A written update by 18:00 CET on each Working Day. 3. A weekly report on Friday 6 November 2026. 4. A handover note with run, test and change steps. 5. A written plan for the paid follow-on, with the estimated hours. ### 8. Access needed | System | Access level | Who grants it | Removed on | |---|---|---|---| | GitHub repository `example-client/helpdesk` | Write to branches, no admin, protected main branch | Jane Doe | End of engagement | | Staging environment | Deploy to a preview URL only | Jane Doe | End of engagement | | Help center content | Read-only export of public articles | Support lead | End of engagement | | Model API | A test key with a spend cap of USD 50 for the Week, on the Client's account | Jane Doe | End of Week 1 unless renewed | | Production systems | None | Not applicable | Not applicable | ### 9. Production actions approved for this Week None, because EXAMPLE-01 is a Free Week. ### 10. Approved AI Providers for this Week Same as the Schedule. The Client ticked Anthropic only. No other provider sees the Client's code or tickets. ### 11. Assumptions and dependencies 1. The Client exports 15 past tickets with names, emails and phone numbers removed before day 1. 2. The Client answers written questions within 1 Working Day. 3. The staging environment is available on all 5 Working Days. ### 12. Paid follow-on | Paid Week | Goal | Estimated hours | |---|---|---| | 2 | Grow the evaluation set to 40 real cases, add the evaluation as a CI gate, add token and spend caps | 40 | | 3 | Staff feedback buttons on drafts, a cost and quality dashboard, and a staged production rollout behind the flag with written approval for each deploy | 40 | Estimated paid follow-on is 2 Paid Weeks, about 80 hours at the hourly rate in the Order Form. Paid Week 2 has the Working Days 9, 10, 12, 13 and 16 November 2026, because 11 November is a public holiday in Poland. ### 13. Changes If Jane Doe asks for Spanish drafts during the Week, the request goes into the plan for a later Paid Week. The criteria above don't change. ### 14. Approval Approved for the Client by the Decision Maker Name Jane Doe, CTO Written approval by email on 28 October 2026 Approved by Michael Lip, Axdale Date 28 October 2026 --- Axdale. Michael Lip, independent engineer, Warsaw, Poland (CET). michael@axdale.com. This document is plain English and isn't legal advice.