Proposal context
Discuss
Threads, objections, clarifications and attributed contributions.
← Back to projects
AI workflow / decision operations
Decision workflow knowledge assistant
We helped turn scattered discussion, approval and follow-through records into a searchable knowledge workflow with cited answers.
The assistant was not there to make decisions. It helped people find the records behind decisions, understand the context and verify the source material.
Context + lifecycle
Decision history existed. Reconstructing it was the problem.
Discussion happened in one place, approval or voting status lived in another, and follow-through was tracked somewhere else. People could find the information, but only by opening multiple systems and stitching the story together by hand.
The useful unit was not a loose document. It was the decision lifecycle: how an idea was discussed, approved, executed, questioned and verified.
Decision state
Approve
Voting or approval state, stage changes and dates.
Follow-through
Execute
Implementation status and follow-through records.
Natural-language interface
Ask
Questions without exact proposal titles, IDs or keywords.
Evidence layer
Verify
Citations back to the source material behind the answer.
System design
From scattered records to cited answers.
A generic chatbot over raw exports would have missed the point. The work was to make the decision workflow retrieval-ready first: preserve metadata, discussion attribution, approval state, dates, status and source links before asking the assistant to answer.
Knowledge flow
records to verification
DiscussLong-form
contextThreads, objections, clarifications and contributors.
ApproveDecision
stateApproval records, dates, stage changes and status.
ExecuteFollow-throughImplementation records and current
progress.
RAGRetrieval modelCanonical
metadata, attributed records and source links.
AskNatural
questionsNo exact proposal title or ID required.
FindSemantic
retrievalRelevant structured records brought into context.
AnswerGrounded
responseGenerated only from retrieved decision records.
VerifyCitationsUsers can inspect the source material behind the
answer.
Decision workflow retrieval ledger
asdloop project example / 02
Layer
Before
Build
Outcome
Discussion
Context buried in long threads
Attributed discussion records
Who said what remains traceable
Approval
Decision state in another tool
Canonical decision metadata
Status and dates become searchable
Execution
Follow-through tracked separately
Implementation/status records
Progress can be queried with context
Retrieval
Manual lookup or exact search
Semantic retrieval over prepared records
Relevant context can be found without exact IDs
Answering
Unsupported summary risk
Grounded generation with citations
Users can verify answers against source records
Simplified workflow map, not a full internal architecture diagram or fixed product template.
Assistant behavior
Useful answers, with a way to check them.
At query time, the assistant answered from retrieved decision records only. If the context was missing, it should say so instead of filling the gap. Retrieved user-generated discussion was treated as source data, not instructions.
- 01Questions did not require exact proposal titles, IDs or keywords.
- 02Answers cited the records used to support the response.
- 03Generation stayed scoped to retrieved context.
- 04Missing context was handled honestly instead of guessed.
Quality discipline
RAG quality was evaluated by failure mode.
When a RAG system gives a weak answer, the fix depends on what failed. The right record may be missing from retrieval, or the record may be present and the answer may still drift. The project separated those cases before changing prompts, chunks or architecture.
Retrieval checks
Find the right records
Is the expected source record present, and is it high enough in the retrieved context?
Answer checks
Stay faithful to context
Is the answer faithful to the retrieved context and relevant to the question?
Diagnosis before complexity
Add complexity only when measured
Only add reranking, hybrid search, routing or prompt changes when measured failures justify them.
Operating result
Scattered decision records became a trusted knowledge workflow.
The reusable pattern is clear: source records split across tools became easier to model, retrieve, answer from and verify in one workflow.
Three source types connectedDiscussion, approval and follow-through records
organized around one decision lifecycle.
Cited answersResponses linked back to source records instead of unsupported
summaries.
Quality checksRetrieval and answer failures diagnosed separately so improvements
could target the real issue.
How we helped We modeled the decision lifecycle, built retrieval-ready records, generated cited answers and evaluated quality by separating retrieval failures from answer failures.
Similar problem?
If important context is split across too many tools, we can help turn it into a workflow people trust.
We start with the records: where decisions begin, where approval happens, where follow-through lives, who needs answers and what evidence they need to trust those answers.