Grief to Action (G2A) is described in my project index as an AWS-hosted annotation web application paired with a conversational agent for community legal data work. Unlike my archived course projects, I do not have a public source repository to point to for G2A. This write-up therefore stays at the level of the project's stated goals and design notes. It should not be read as a claim that every component below reached production or was independently verified.
The problem the design addressed
The central idea was to support two related activities: consistently labeling incoming records and making the resulting structured information easier to query. An annotation interface could give contributors a focused queue instead of asking them to work directly with underlying tables. A narrow conversational layer could then help answer constrained questions over reviewed records.
That combination creates an important constraint: convenience cannot come at the expense of provenance. A conversational answer should be traceable to reviewed data, and an annotation change should retain who made it and when. For a legal-data context, those are design requirements rather than optional polish.
Proposed workflow and boundaries
The working architecture separated the annotation path from the question-and-answer path:
record queue -> annotation UI -> REST API -> relational routines
\-> attachment storage
reviewed labels -> constrained retrieval -> conversational response
The annotation flow was intended to assign a record, collect a label set, save the change, and route it for review. Server-side assignment and a locking strategy were considered to reduce duplicate work. Optimistic updates and retry behavior were also part of the design discussion, but without a public implementation or operational record I cannot claim specific reliability characteristics.
For the conversational layer, the safest scope was deliberately small: lookups, counts, and recent changes over labeled records. Low-confidence questions should fall back to guided search rather than produce a confident-sounding answer. Caching repeated, normalized questions was another possible optimization, though correctness and access control would have to take priority over speed.
Security as a requirement, not a result
The original notes called for token-based authentication, short token lifetimes, annotator and reviewer roles, encryption at rest, a strict CORS allowlist, and an audit log. These are sensible controls, but they are listed here as intended safeguards—not as an audit of a deployed system.
The same distinction applies to monitoring. Queue depth and annotation latency would be useful CloudWatch signals for an AWS-hosted service. They indicate whether work is accumulating and whether the workflow is slowing down, but no measured values are available here.
Retrospective
The clearest lesson is that the label taxonomy is part of the data model. Changing labels midway affects the interface, stored records, review rules, and any conversational retrieval built on top. Defining examples and edge cases early would reduce that cascade.
A second lesson is that conversational UX needs an explicit failure mode. In a sensitive domain, “I cannot answer from the reviewed records” is better than an unsupported response. Any future active-learning feature should follow the same rule: suggested labels remain suggestions until a person reviews them.
Finally, this project would benefit from stronger public evidence before making broader claims. Useful next artifacts would include a sanitized schema, a threat model, a small test dataset, and documented acceptance criteria for assignment, review, and retrieval. A richer diff view could then help reviewers understand complex edits.
For comparison, the EasyTrip retrospective discusses what can be learned from an archived application with inspectable source, while the Data Science Toolbox post examines a containerized course project. G2A remains a design-focused entry until similarly reviewable implementation material is available.