Six practical steps for moving from an idea to a useful result—and keeping the knowledge for your next project.
You ask AI to help with an idea. The conversation goes well. You get a plan, a few useful suggestions, and perhaps a first draft.
A week later, you return to the project.
Which decisions did you approve? What still needs work? Why did you choose that approach? You scroll through conversations, reopen documents, and explain the project again.
The Kraven AI Framework gives that work a structure:
Think → Design → Build → Validate → Document → Preserve
Each phase has a clear purpose and an output that helps the next phase begin. Kraven Knowledge OS, or KOS, holds the project context and knowledge that connect the cycle.
Here’s how it works.
Start with a familiar example
Imagine you run a small service business. Customer inquiries arrive through different channels, and some follow-ups get missed.
You want a simple way to see who contacted you, what they need, and what should happen next.
We’ll use that example throughout the framework.
1. Think: Understand the problem and choose the outcome
Before creating anything, clarify what you are trying to improve.
For the service business, “build a customer management system” is a large, vague request. A more useful starting point is:
“We lose track of customer inquiries. We need one place to record each inquiry, assign a person to follow up, and see the next action.”
Now you can decide what the first version actually needs:
- Customer name and contact details.
- A short description of the request.
- A person responsible for following up.
- A status and next action.
A customer portal, automated messaging, and detailed sales analytics can wait.
In the framework, ChatGPT takes the Think role: helping explore the problem, clarify requirements, compare options, identify risks, and define a manageable first version.
A useful prompt would be:
“Help me define the smallest useful solution for tracking customer inquiries. Ask about our current process, identify where follow-ups get missed, and separate essential requirements from optional features.”
The output is a clear direction you can approve.
2. Design: Decide how the solution should work
Once the outcome is clear, work out how someone will use the solution.
For our inquiry tracker, the basic flow might be:
New inquiry → Assign owner → Follow up → Mark resolved
You might sketch a screen showing all open inquiries, a form for adding a new one, and a detail view containing the next action.
This stage also exposes questions that are easier to answer before implementation:
Can two people handle the same inquiry? What information is required? Who can mark it resolved?
In the framework, Claude takes the Design role, helping turn approved requirements into user flows, layouts, data structures, and implementation instructions.
Design should remove enough uncertainty to make building practical. A small internal tracker may need only a simple sketch and a clear description of its behavior.
3. Build: Create the working deliverable
Building turns the approved plan into something people can use.
For the inquiry tracker, that means implementing the form, saving the records, displaying open inquiries, and allowing the team to update them.
In the framework, Codex takes the Build role, using the requirements, design, repository context, and project records to implement the solution.
Clear acceptance criteria help everyone recognize when the work is ready to review. For example:
“A team member can create an inquiry, assign an owner, save a next action, and see the inquiry in the open list.”
The output is a working implementation with evidence of what was built and checked.
4. Validate: Check whether it actually works
A working screen is only part of the result. You also need to check that the solution behaves correctly.
For our example:
- Does an inquiry remain saved after refreshing the page?
- Can the team identify who owns the next action?
- What happens when required information is missing?
- Does a resolved inquiry leave the open list?
- Can the intended users access the right information?
In the framework, Claude returns as a separate reviewer, checking the implementation against the requirements and identifying defects, gaps, and risks.
If something fails, the work returns to Build for corrections.
A second AI review provides another perspective. Actual tests, real use, and human approval still determine whether the result is acceptable.
5. Document: Explain the result and record the decisions
Once the work has been validated, capture what someone needs to understand and operate it.
For the inquiry tracker, useful documentation might explain:
- How to add and assign an inquiry.
- What each status means.
- What the system currently supports.
- Which limitations remain.
- Why certain features were deferred.
Documentation does not need to be long. A clear one-page guide can be more useful than a large document nobody maintains.
In the framework, ChatGPT takes the Document role, helping turn validated results and approved decisions into guides, summaries, and reusable project knowledge.
Working notes can be written throughout the process. This phase consolidates them into an accurate account of the finished work.
6. Preserve: Make the knowledge available next time
The final phase is where the current project begins helping future work.
Suppose you return three months later to add reminders. You should be able to find the existing workflow, the decisions behind it, the known limitations, and the next action without reconstructing every conversation.
The framework uses Obsidian and KOS as the knowledge hub for this preserved context.
Two files play distinct roles:
| File | What it holds | Inquiry-tracker example |
|---|---|---|
memory.md |
Approved project knowledge: purpose, scope, constraints, and decisions | “The first version tracks inquiries and manual follow-ups. Automated messaging is outside the approved scope.” |
handoff.md |
Current execution state: completed work, open issues, validation, and next actions | “Inquiry creation and assignment passed testing. Mobile layout review remains. Next: check the form on a small screen.” |
Think of memory.md as the project’s agreed understanding and handoff.md as its current progress note.
Keep both accurate. Saved notes provide context; the actual deliverable and validation evidence show what works.
What should move between AI tools?
A useful handoff carries the information needed for the next task:
Objective: Complete the inquiry tracker’s first version.
Approved scope: Create inquiries, assign owners, and track next actions.
Completed: Creation and assignment are implemented and tested.
Open issue: The mobile form still needs review.
Next action: Check the form on a small screen and correct any layout problems.
Include the relevant files, requirements, and test results alongside that summary.
This makes the next session easier to start and reduces the chance of reopening settled decisions.
Do you need every named tool?
The framework assigns these default roles:
ChatGPT → Claude → Codex → Claude → ChatGPT → Obsidian
Those assignments describe the chosen workflow. They are not a universal ranking of AI tools.
Start with the tools you already have and keep the phases proportionate to the task. A short article may need a brief planning pass, a draft, an editorial check, and a saved final version. A software project needs more detailed implementation and validation.
The framework also places Gemini and NotebookLM in a supporting research layer. Research can inform Think, Design, or Validate when the project needs additional evidence.
The same cycle can support other kinds of work
For a blog post, you can clarify the reader’s question, plan the structure, write the draft, check the facts and examples, record the editorial decisions, and preserve useful research.
For an employee onboarding process, you can define the outcome, map the steps, create the checklist, test it with a new hire, document responsibilities, and retain the improvements.
These are practical adaptations of the same six phases. The amount of work changes with the task.
Try it with one project
Choose something you already need to finish: a proposal, article, internal process, or small application.
Write down the intended outcome and approved scope. Create a short handoff showing where the work stands. Then move through the six phases, checking the result before treating it as finished.
KOS provides a place to keep the context, decisions, and lessons that emerge from that work.
The next time you return, you can begin from what you already know.