Inspiration
A document request rarely ends with one email. A reply arrives, an attachment follows, the scope changes, and someone still has to work out what is missing. An uploaded file can sit “under review” even when both sides expect the next step.
We built DossierRelay around those everyday distinctions: requested, received, reviewed and ready to follow up. The aim is to help a person continue a document-heavy conversation with the relevant context in front of them, while keeping approval and responsibility explicit.
Our requester-side example comes from an ongoing Dutch Woo information-request matter. It demonstrates planning a meeting, clarifying scope and preparing follow-up questions. The example contains three newly written, pseudonymized derivatives of the requester's own outgoing correspondence, with an English companion. It includes no ministry replies, quoted email chains, original attachments or private originals. The underlying matter remains ongoing.
What it does
DossierRelay brings messages, document requirements, uploaded files and review decisions into one case. A case-specific portal lets a client respond, upload files and see what still needs attention.
The operator can ask Amazon Bedrock to draft a follow-up from bounded conversation excerpts, the document checklist and file metadata. The draft includes source-message references. A person reads or edits it, then approves the exact text and recipient. Only an approved response can be sent through Amazon SES; subsequent case changes invalidate the previous approval.
Document review is a visible action. The operator opens a file, records an assessment and advances to the next pending item. While a client portal is visible and waiting for reviews, it refreshes the review state without discarding an unfinished message or the selected requirement. A normal reload retains access within the tab's bounded session. Closing the case in that tab clears its access.
The workflow distinguishes an email accepted by SES from a later provider event. It also distinguishes processing a demonstration checklist from concluding a real legal procedure. Completing the requester example is labelled Documents processed; it does not declare the source Woo matter resolved.
How we built it
The AWS edition uses API Gateway and a Node.js Lambda for the interface, authentication and workflow. DynamoDB stores case state, versions, approvals and usage records. Private S3 stores uploaded files with integrity metadata. Secrets Manager holds the workspace access key.
Amazon Bedrock's Converse API, using the EU Nova Micro inference profile, produces the proposed response. The SESv2 SDK sends the exact approved communication. SES events pass through SNS to a separate receipt Lambda, which records minimal events keyed by the SES message ID.
This is a bounded, human-approved AI workflow. The model proposes the next communication; deterministic application checks control approval, sending, document acceptance and completion. Uploaded PDF body text is not passed to the model. Human document inspection remains an explicit step.
For evaluation, we deployed a separate AWS judge workspace with its own case table, private document bucket and access secret. Reviewers can exercise the complete workflow using synthetic cases and Amazon SES's success mailbox simulator. The packaged requester example provides a more realistic document-review scenario, with clear provenance and a complete English reading copy.
Challenges we addressed
The most demanding part was keeping the draft, approval and external send connected to the same case state. An approval must become invalid when its context changes. A repeated accepted send request must not create another message. An uncertain provider outcome must remain visible instead of being presented as a successful delivery.
We also addressed two practical usability failures: documents remaining indefinitely in an ambiguous review state, and a cleaned-up portal URL losing access on reload. Explicit file assessments, background review updates and a bounded tab session make those transitions understandable.
A realistic demonstration needed equally careful boundaries. We preserved the sequence and purpose of requester correspondence while replacing identifying details and excluding the other party's messages. The resulting documents are labelled adaptations, with source identifiers and hashes for the curated assets. Pseudonymization is not a claim of complete anonymity, and the packet makes no claim about an agency's position or a legal outcome.
What we verified
The released AWS source passed 282 offline checks. A fresh run against the deployed judge release passed 91 live assertions, covering authentication, case and portal scope, file integrity, document review, approval invalidation, controlled sending, completion, export and session revocation.
That live run made one genuine Amazon Bedrock request and one Amazon SES success-simulator send. An independent receipt lookup confirmed both Send and Delivery events for the same simulator message. Replaying the accepted send key returned the existing result without another send. These results demonstrate the AWS service integration and simulator event path; they do not represent a production customer's inbox or measured customer outcomes.
A separate browser check confirmed that opening an invitation, reloading its cleaned URL, closing tab access and reopening the original invitation behave as intended. Dated earlier reports remain separate from the current release's evidence.
Prior work disclosure
DossierRelay's branding, workflow concept and earlier Sites/Cloudflare prototype predate this AWS edition. For this entry, work on 25 October 2026 added the AWS adapters, Lambda HTTP integration, infrastructure, SES event receipts, English AWS interface and AWS verification workflow, while reusing existing JavaScript authentication and case-workflow code. The entry also includes the document-review improvements, portal-session repair, isolated judge workspace and English demonstration material. This submission is an extension and port of disclosed prior work.
What we learned
A useful communication assistant needs more than a plausible draft. It needs to show which context informed the response, which version a person approved, what the communication provider accepted and what still requires a decision. The transitions around the model matter as much as the generated text.
What's next
We would next develop separate workspaces for multiple operators, explicit retention and recovery choices, pagination, and measured pilots with consenting users. Those pilots would establish whether the workflow reduces missed follow-ups or review delays. We have not yet measured those customer outcomes or deployed this as a production customer service.
Verified AWS release — 27 October 2026
The isolated judge release was updated through three bounded CloudFormation change sets: temporary model pause, AgentCore runtime update, and matched application deployment. AgentCore Runtime and its DEFAULT endpoint are both READY on version 3; both Lambda functions are Active/Successful. The two new S3 code artifacts were checked by full SHA-256. One non-model AgentCore health invocation returned HTTP 200 with the expected source binding, protocol v2 and Nova Micro configuration. The challenge page, judge guide, architecture, CSS and JavaScript were fetched from the live site and found byte-identical to the reviewed code. All three synthetic practice-file download buttons worked. The reviewed candidate passed 307/307 offline tests. There were no new model-bearing Nova calls or SES sends for this v3 release, and historical synthetic service evidence does not establish delivery to real customers.
The exact AWS/AgentCore implementation, tests and instructions are available on the published GitLab branch. Amazon SES is the qualifying CDS service used at runtime. AWS End User Messaging Social (WhatsApp) has NOT been deployed or used for this entry; any future WhatsApp work is a separate module.
Built With
- amazon-bedrock
- amazon-dynamodb
- amazon-ses
- amazon-sns
- amazon-web-services
- aws-cloudformation
- aws-lambda
- javascript
- node.js
- python
- typescript
Log in or sign up for Devpost to join the conversation.