Now that our LLM work is setup, we want to store LLM-generated summaries of bills in Firebase so we can serve them on the bill details page.
A bill can have multiple summaries (it likely makes sense for this to be a sub-collection under bills)
For the first pass, we will only generate summaries when the model changes and we manually decide to generate new summaries
A bill summary has the following elements:
summaryText: The text of the generated summary
createdAt: Timestamp when the summary was added to our DB - For V1, I think we can safely assume that the most recently created summary is the currently active summary (we can look into more finely tuned control once we have a live MVP to experiment with).
source: String that specifies the reason the bill summary was generated (e.g. something like bill-update in response to a bill update, model-update or model-v7 in response to a model update, or manual for a manual override - actually setting this will be the responsibility
Bill Summaries should be readable, but not writable, from the Front End
The only actual query pattern for V1 should be fetching the most recently created summary for a given bill (to display on the bill details page).
Success Criteria
A "Bill Summary" data model meeting the above criteria is added to our Firebase types (Firebase auto-generates this stuff on the first field write - should just need to make sure the indexes/rules are set up right).
A corresponding BillSummary Typescript type is added for use in the maple codebase
At least one example BillSummary added to a bill on the dev environment to kick
Additional Links
Ticket for job to generate and backfilling summaries into the new data model:
Python code that generates the summaries: <TBD - link to cloud wrapper ticker>
Problem
Now that our LLM work is setup, we want to store LLM-generated summaries of bills in Firebase so we can serve them on the bill details page.
bills
)summaryText
: The text of the generated summarycreatedAt
: Timestamp when the summary was added to our DB - For V1, I think we can safely assume that the most recently created summary is the currently active summary (we can look into more finely tuned control once we have a live MVP to experiment with).source
: String that specifies the reason the bill summary was generated (e.g. something likebill-update
in response to a bill update,model-update
ormodel-v7
in response to a model update, ormanual
for a manual override - actually setting this will be the responsibilitySuccess Criteria
BillSummary
Typescript type is added for use in the maple codebaseAdditional Links