How do you build your first Super Intelligence learning routine? The best SI routine is small enough to repeat, practical enough to produce real work and structured enough to show you when an answer is wrong. A routine should create skill, not merely increase the amount of time you spend chatting with AI.
A good AI learning routine combines one real task, one observable standard, one checked attempt and one short reflection. The learner gradually adds research, reasoning, writing, data, coding or tool use only after the earlier skills remain dependable on fresh examples.
This eduKateSG guide gives beginners, students and working adults a daily and weekly Super Intelligence practice system. It completes Stage 1 of the How to Learn Super Intelligence Quickly curriculum after What Super Intelligence Can and Cannot Do and prepares readers for Stage 2 instruction and prompting skills.
Terminology: SI is our editorial term for practical contemporary AI learning. The routine below is a learning framework, not a promise that a particular number of days or minutes guarantees mastery.
A Routine Should Reduce Friction Without Reducing Thinking
The reason to create a routine is not to turn learning into a rigid schedule. It is to remove unnecessary decisions. When the learner already knows what kind of task to practise, what evidence to keep and how to review the result, more attention can go to the skill itself.
A weak routine says, “Use AI every day.” This may produce a lot of activity without improving anything in particular. A stronger routine says, “Complete one source-grounded task, check the important details, record one failure and repeat the repaired method on fresh material.”
The second routine has a feedback loop. It creates evidence that can change the next session. That feedback loop is the engine of skill development.
The Five Parts of a First SI Learning Routine
1. One recurring task
Choose something that already matters to you. A student might use revision notes. A professional might use a meeting brief. A writer might revise a paragraph. A programmer might implement a small function. Real tasks create motivation and reveal practical constraints.
Keep the first task bounded. You should be able to understand the source and independently judge whether the output is acceptable. Do not begin with a project whose correctness you have no way to evaluate.
2. One skill target
A session should have a target such as source fidelity, question quality, numerical checking, transfer or tool permissions. “Get better at SI” is too broad to produce focused feedback.
Write the target at the top of your notes. When the session drifts into unrelated experiments, return to it. Curiosity can be saved for a separate exploration period.
3. One acceptance standard
Before prompting, define what a successful result must preserve. A summary might require the date, owner and unresolved issue. A coding exercise might require three tests. A learning exercise might require an independent transfer question.
This standard prevents the learner from deciding after the fact that whatever the system produced must be good.
4. One review step
Review the result using evidence outside the answer itself. Compare with the source, reproduce the arithmetic, run the tests or inspect the destination record.
The review step should be strong enough for the consequence of the task. A low-stakes idea list needs less review than a public factual document.
5. One saved lesson
End the session by recording one sentence: what worked, what failed or what should change next time. Do not write a long diary unless reflection itself is useful to you.
Over several sessions, these sentences become a personalised error map. The routine begins to teach you what to practise next.
The Fifteen-Minute Routine
A short routine is useful on busy days. The exact duration is flexible; fifteen minutes is simply a compact example of how to divide attention.
- Choose one small source or task and write the acceptance standard.
- Run one attempt without overengineering the prompt.
- Check the two or three details that matter most.
- Make one targeted repair if needed.
- Write one line explaining what the next session should test.
This routine is best for maintaining a skill or practising one distinction, such as preserving optional versus compulsory language. It is not designed for complex research or a large project.
The Thirty-Minute Routine
A longer session allows a transfer step. Begin with a normal task, inspect the result, diagnose one error and apply the repair to a fresh example.
The transfer case is the important addition. It prevents the learner from becoming good only at the example used to teach the method. Change the names, numbers, topic or wording while preserving the underlying skill.
End by saving a reusable instruction or workflow only if the method survived the new example. A prompt that works only after extensive manual rescue is not yet ready for your permanent library.
The Sixty-Minute Project Session
A project session can combine several skills: source preparation, generation, checking and final production. The learner should still break the hour into stages rather than asking for the whole project in one request.
For example, spend the first stage confirming sources and scope, the next stage building structure, the next stage producing one section, and the final stage reviewing. Adjust the exact timing to the task. The structure matters more than the clock.
Project sessions are useful for reports, presentations, study guides, small websites or code prototypes. Keep the final review proportional to the importance of the output.
The Weekly Rhythm
A week can combine repetition and novelty. Use several sessions to strengthen one skill, one session for a small project and one review to decide what should change next week.
Do not schedule a completely different topic every day. Some repetition is necessary for a pattern to become visible. If the learner changes from research to coding to images to automation in four consecutive sessions, the error log may never contain enough comparable evidence to guide improvement.
At the same time, do not repeat an exercise that has become trivial. Once a skill transfers consistently, maintain it through normal work and allocate deliberate practice to the next bottleneck.
A Four-Week Beginner Routine
Week 1 — Task definition and fidelity
Practise short source-grounded work. Define the task, audience and protected details. Check every date, number and obligation. Learn to preserve unknown information rather than inventing it.
The week ends when you can explain what the task required and identify a factual or meaning error without asking SI to judge itself.
Week 2 — Evidence and calculation
Add one factual lookup, source comparison or simple dataset. Practise identifying authority, date, denominator and scope. Reproduce important calculations independently.
The week ends with one short evidence-based brief whose central claims can be traced back to their sources.
Week 3 — Transfer and creation
Use the same foundational skills in a different output: a study guide, document, presentation outline or small coding task. Protect the evidence while changing the form.
The week ends when the method survives a new example or format without losing the important controls.
Week 4 — Workflow building
Choose one repeated process and document its inputs, steps, checks and stop conditions. Test the workflow on fresh cases. Keep consequential external actions behind human approval.
The week ends with a reusable method, not a claim of complete SI mastery.
Build a Practice Queue
Keep a short queue of tasks rather than deciding from scratch every session. The queue should contain real work ordered by learning value. Label each item with the skill it practises.
For example: rewrite a notice without changing requirements; compare two source versions; check a percentage; create five retrieval questions from notes; debug a small function; turn meeting notes into a verified brief.
Remove tasks that no longer expose a weakness. Add tasks when the error log shows a new recurring problem.
Use a “Repair / Stabilise / Extend” Decision After Every Session
Repair when the learner does not understand the failure or keeps repeating the same mistake. Reduce the task and practise the missing distinction directly.
Stabilise when the method sometimes works and sometimes fails. Use several comparable examples with the same checks until the behaviour becomes consistent.
Extend when the skill transfers. Add one new complication such as a second source, a larger file, a new audience or one connected tool.
This decision keeps the routine adaptive. The calendar does not force the learner forward when the foundation remains unstable.
A Routine for Students
Students should include an unaided attempt in the routine. Begin by answering the question, writing the paragraph or explaining the concept before requesting help where possible.
Then use SI to diagnose confusion, provide a hint, create another example or give feedback on reasoning. End with fresh independent work. The final evidence should come from the learner’s own performance.
Follow school and assessment rules. A routine designed for learning should not become a system for disguising generated work as independent student work.
A Routine for Teachers
Teachers can choose one preparation task per week: examples, question variation, feedback phrasing or lesson structure. Begin with the learning objective and source material.
Check generated questions and answer keys. Record the types of mistakes that recur. Build a small failure set that future workflows must pass.
Use learner information only according to school policies, permissions and appropriate privacy practices. The routine should improve preparation without weakening professional responsibility.
A Routine for Professionals
Professionals can centre the routine on source-grounded deliverables: meeting briefs, reports, document comparison or spreadsheet explanation.
Define protected fields such as owner, deadline, decision, risk and unresolved issue. Review those fields before polishing style.
When the process stabilises, document it for handoff. A professional routine becomes more valuable when another authorised colleague can understand and reuse it.
A Routine for Creators
Creators can separate exploration from selection. Use one part of the session to generate genuinely different possibilities, then switch to a human selection phase using the project’s criteria.
Keep source and attribution responsibilities visible when factual material or external references enter the work. Creative generation does not remove the need to verify factual claims.
End the routine by choosing and developing one direction. Infinite ideation feels active but can delay actual creation.
A Routine for Programmers
Start with a specification and test cases. Ask SI to explain, implement or debug one bounded component. Run the code. Preserve the error output.
When the code fails, diagnose the smallest cause. Ask for the smallest repair. Re-run tests and read the changed implementation.
Use a fresh boundary case before accepting the method. For production work, add the engineering practices required by the project: security review, dependency checks, deployment controls and observability.
A Routine for Research
Write the question and the kind of evidence capable of answering it. Search for original or authoritative sources where appropriate. Record date and scope.
Use SI to compare, extract and synthesise. Then verify the claims that carry the conclusion. Keep disagreement visible when the evidence genuinely conflicts.
End with a research state: supported conclusion, unresolved questions and next source needed. This prevents endless browsing.
Keep a Small Learning Log
A useful log needs only a few fields: date, task, skill target, error, repair, transfer result and next step.
The log should be easy enough to maintain. If the documentation takes longer than the learning task, simplify it.
Review the log weekly for repeated failure patterns. Those patterns become the next curriculum rather than relying on generic lists of what an SI user “should” learn.
How to Measure Progress Without a Fake Score
Measure observable changes: fewer source errors, better transfer, less review time, clearer handoffs, more independent student performance or more consistent tests.
Do not invent a universal SI score. Capability is multidimensional. You may improve rapidly in writing workflows and remain a beginner in data analysis.
Keep examples. A dated before-and-after pair shows progress more honestly than a self-rating without evidence.
The Receiver Test
At the end of a session, ask whether the intended receiver can use the output. A study guide should support independent recall. A colleague should understand the decision and next action. A program should receive the expected fields.
If the receiver needs to reconstruct missing context, the workflow is not yet complete. Improve the handoff before adding more automation.
The Closure Test
Define what allows the session to stop. One corrected task plus a successful transfer example may be enough. A research session may stop with one verified answer and one unresolved question.
Closure protects attention. Once the learning objective has been met, save the result and move on instead of continuing to prompt because the system can keep responding.
What to Do When You Miss a Day
Do not turn the routine into a fragile streak. Resume with the next useful task. Skill development depends on repeated meaningful practice, not on preserving a perfect calendar.
If the gap has been long, begin with a familiar benchmark to see which controls remain automatic and which need refreshing.
What to Do When the Routine Becomes Boring
Boredom can signal that the task is too easy or too repetitive. Add a meaningful complication rather than merely switching to a random new feature.
For example, move from one source to two, from a plain summary to a receiver-specific brief, or from a manual calculation to a small dataset.
If the skill is genuinely stable, retire dedicated practice and let normal work maintain it.
What to Do When the Routine Becomes Overwhelming
Reduce the scope. Return to one source, one output and one check. Remove connected tools that are not necessary for the learning objective.
Overwhelm often appears when learners add complexity faster than they add control. Rebuild from the earliest unstable point.
A Worked Daily Routine
Source: “The study group meets Friday at 4 pm for forty-five minutes. Lina brings the algebra set. Omar brings the vocabulary list. The room has not been confirmed.”
Skill target: preserve confirmed facts and unknowns. Acceptance standard: correct day, time, duration, owners and no invented room.
Attempt: ask for a reminder. Review: compare every protected detail. Repair: if a room is invented, instruct the system to preserve missing information. Transfer: use a new brief with different people and an unconfirmed start time.
Saved lesson: “When planning information is incomplete, explicitly label unknowns instead of allowing the draft to fill them.” This one line becomes the next session’s control.
A Worked Weekly Review
At the end of the week, choose the three strongest tasks and the three most important failures. Do not judge the week by volume alone.
Ask which failure repeated. Ask which repair transferred. Ask which task required less review because the process became clearer. These answers determine next week’s focus.
Archive prompts that did not help. Keep workflows that survived transfer. The learning system should become cleaner over time.
Frequently Asked Questions
Should I practise SI every day?
A daily rhythm can be useful if it fits your schedule, but it is not a universal requirement. Regular high-quality practice matters more than protecting a streak.
How long should one session be?
Long enough to complete a task and meaningful review. Use shorter sessions for one distinction and longer sessions for projects. Stop when attention is too weak for checking.
Should I learn one tool or many tools?
Begin with the tools needed for your current task. Add another tool when it provides a capability the existing workflow lacks.
How many prompts should I save?
Save only prompts or workflow cards whose purpose, inputs and checks you understand. A small tested library is more useful than a large uncurated collection.
How do I know when to advance?
Advance when the skill works on fresh examples and you can explain its failure conditions. Repeat or repair when the same error remains unstable.
Can a routine make me an expert?
A routine can support skill development. Expertise also requires domain knowledge, experience, judgment and feedback appropriate to the field.
What comes next?
Move into Stage 2 with How to Write Better Instructions for Super Intelligence, followed by How Prompting Super Intelligence Really Works.
Design the Routine Around a Skill Ladder
A good routine has a progression. If every session repeats the same level of difficulty, the learner may become fluent without becoming more capable. If every session jumps to a new difficult task, the learner may never stabilise the foundations.
Use a ladder with four rungs. Rung 1 is guided practice on visible source material. Rung 2 is independent performance on comparable tasks. Rung 3 is transfer to new contexts. Rung 4 is workflow design, where several skills are combined into a repeatable method.
Move up only when the lower rung remains stable. Return down when a new task exposes an old weakness. This prevents the routine from becoming a one-way race toward complexity.
The Monday-to-Sunday Example Routine
The following weekly example is optional. It shows how to combine depth and variety without turning every day into a different subject.
Monday — Baseline
Choose the week’s skill and run one normal example without special optimisation. Preserve the source, prompt and output. Record the first important failure. This baseline gives the rest of the week something concrete to improve.
Tuesday — Repair
Practise the exact distinction that failed. If a deadline changed, work with several short notices containing dates and optional requirements. If a calculation used the wrong denominator, practise small percentage problems where the correct base changes.
Wednesday — Stabilise
Use two or three comparable examples. Keep the evaluation standard fixed. The purpose is consistency, not novelty. If the repair works only once, it has not stabilised.
Thursday — Transfer
Change the domain or output format while preserving the underlying skill. A source-fidelity method used on a school notice might be tested on meeting notes. A numerical check used on attendance might be tested on a completion rate.
Friday — Project
Apply the skill inside a larger real task. Combine it with related capabilities such as structuring a document, producing a short analysis or preparing a study guide.
Saturday — Review
Inspect the week’s error log. Which failure repeated? Which repair transferred? Which prompt or workflow should be kept? Which should be discarded? Use this review to choose the next bottleneck.
Sunday — Light exploration or rest
Use optional exploration for curiosity, not for replacing the main curriculum. Try a new feature, read documentation or simply stop. A sustainable routine must fit the learner’s actual life.
The Routine Notebook
Your notebook can be a document, spreadsheet, paper notebook or another simple system. It does not need to be sophisticated. The important part is that it preserves enough information to compare sessions.
- Date and task.
- Skill target.
- Source or input.
- Acceptance criteria.
- First output.
- Important failure.
- Repair attempted.
- Transfer result.
- Next step.
Do not record private or sensitive material in a place where it does not belong. Use summaries or fictionalised practice cases when appropriate.
Build a Failure Library, Not a Hall of Shame
A failure library is a collection of examples where the workflow did something wrong. It is useful because future versions of the method can be tested against known weaknesses.
For example, keep one case where SI invented a missing room, one where it changed “may” to “must”, one where it used the wrong denominator and one where a tool action failed. These examples become regression tests.
The library should be small and representative. You do not need to save every mistake forever. Keep failures that reveal an important class of problem.
The Routine Should Produce Artifacts
Learning becomes more concrete when each week produces something usable: a checked summary, a verified research brief, a study guide, a small script, a spreadsheet or a workflow card.
Artifacts create motivation because the learner is not practising in a vacuum. They also create evidence. You can inspect how the quality changes over time.
Keep both the finished artifact and a short note about the process. A polished final result alone hides how much correction was required.
A Routine for Reading With SI
Choose one article, chapter or approved document. Before asking for a summary, write three questions you want the reading to answer. Then ask SI to map the structure of the text and identify passages relevant to those questions.
Read the key passages yourself. Compare the generated interpretation with the source. Ask SI to explain difficult sections only after you know which part is difficult.
End by writing your own short summary without looking at the generated one. Compare afterward. This protects comprehension from becoming passive consumption.
A Routine for Vocabulary and Language Learning
Choose a small set of words or phrases from real reading. Ask for definitions, examples and contrasts. Then create your own sentence before seeing additional model examples.
Use retrieval later in the week. Hide the definitions and explain each word from memory. Ask SI to create a new context where the word might or might not fit, then justify the choice.
The routine should move from recognition to production. Knowing that a word looks familiar is not the same as being able to use it precisely.
A Routine for Mathematics
Begin with one problem attempted independently. Mark the first step where you become uncertain. Ask SI for a hint or conceptual explanation rather than a full solution.
Complete the problem, then solve a comparable fresh problem without assistance. Check the answer through substitution, estimation, calculation or another appropriate method.
Record error categories: sign, algebraic manipulation, reading, formula choice, arithmetic or presentation. Use the largest recurring category as the next practice target.
A Routine for Science
Use SI to clarify concepts, generate predictions and compare explanations, but keep evidence and experimental reasoning visible. Start from a real curriculum concept or source.
Ask what observation would support or weaken an explanation. Distinguish the model’s hypothesis from established scientific evidence. When equations or data are involved, check units and calculations.
Finish with a transfer question requiring the learner to apply the concept to a new situation.
A Routine for Writing
Separate planning, drafting and editing. In the planning stage, define audience, purpose and evidence. In drafting, focus on structure and meaning. In editing, protect facts while improving clarity and style.
Ask SI to identify the weakest paragraph or transition rather than rewriting the entire document automatically. Compare the original and revised versions.
Keep your own final editorial decision. A routine should help you become a stronger writer, not erase the difference between your judgment and generated text.
A Routine for Public Speaking and Presentations
Start with the audience and the one idea they should remember. Ask SI to help create a structure, then write the opening and key transitions yourself or revise generated drafts carefully.
Practise aloud. Use the recording or your own notes to identify where explanations become unclear or too long. SI can help generate alternative phrasing for those specific sections.
For slides, check every factual claim and chart. The presentation routine should connect spoken explanation, visual evidence and receiver understanding.
A Routine for Spreadsheet Skills
Use a small table you understand. Write what each column represents and what question you want to answer. Attempt the formula yourself or describe the calculation in plain language.
Ask SI to propose the formula and explain it. Compare with your own reasoning. Test the formula on known values and edge cases.
Gradually add complexity: filters, lookups, conditional logic or charts. Keep a copy of the source data before making transformations.
A Routine for Coding
Choose a small specification and write tests before generation where possible. Ask SI to implement only the bounded component. Run the tests and inspect failures.
Use debugging sessions to understand causes rather than replacing whole files blindly. Ask why the error occurs, make the smallest repair and rerun the relevant tests.
Once the component works, explain the code without assistance. Add documentation and one boundary test. Then move to the next component.
A Routine for Research
Begin with a narrow question and a source strategy. Identify what kind of evidence could answer the question. Use SI to discover sources, then open and evaluate them.
Keep a source table containing title, date, authority, relevant passage and role in the argument. This prevents attractive summaries from replacing the evidence record.
End each session with a state of knowledge: what is supported, what is disputed and what remains unknown.
A Routine for Decision Support
Write the decision and criteria before asking SI for a recommendation. Gather the evidence relevant to each criterion. Ask for alternatives and assumptions.
Use SI as analyst and challenger. Ask what would make the preferred option fail. Verify the claims on the critical path.
Record the human decision separately. The routine should improve the decision process without obscuring accountability.
A Routine for Tool Use
When learning a new tool or connector, begin read-only if possible. Identify what information the tool returns and how success or failure is represented.
Add a reversible write action only after the read behaviour is understood. Use test data or a safe environment. Confirm the destination state after the action.
Document the permission boundary. Tool learning includes knowing what not to allow.
The Routine’s Receiver
Every practice artifact should have a receiver, even if the receiver is your future self. Identify what that receiver needs to act correctly.
A future student needs enough explanation to reproduce the skill. A colleague needs the decision and next action. A developer needs the specification and tests. A future version of you needs the source and reasoning behind the workflow.
Receiver design prevents practice from becoming an exercise in producing content with no practical endpoint.
The Routine’s Closure Condition
A session should stop when its learning objective has been met or when the next step requires new information. Define closure before beginning.
Examples: one successful transfer problem, one verified research claim, one passing test set, one approved brief or one diagnosed failure with a clear next practice target.
Closure protects attention and prevents the routine from becoming endless conversation.
The Routine’s Maintenance Cycle
Every month, review the routine itself. Which steps catch real errors? Which have become ritual? Which new task now matters? Which old task no longer deserves deliberate practice?
Simplify where possible. Keep the controls that protect important outcomes. Retire prompts and tools that add little value.
A mature routine should become more focused as your understanding improves.
A 90-Day Progression Without a 90-Day Promise
You can organise a longer learning period into three phases without claiming that the calendar guarantees mastery. The purpose is sequencing.
Phase 1 — Foundations
Build task definition, source fidelity, verification and independent checks. Use simple tools and small tasks.
Phase 2 — Transfer
Apply the foundations across documents, data, writing, research or coding. Build a portfolio of checked artifacts.
Phase 3 — Systems
Turn stable repeated work into workflows. Introduce tools, automation or agents only when the simpler method has a documented limitation.
At the end, evaluate what you can actually do rather than how many articles or prompts you completed.
A Routine Audit
- Does every session have a skill target?
- Is there an observable acceptance standard?
- Does the learner keep the source or input?
- Is important work checked independently?
- Are errors classified specifically?
- Is there a transfer step?
- Does the routine produce useful artifacts?
- Are permissions and privacy respected?
- Can the method be handed to another authorised person?
- Does the routine know when to stop?
If several answers are no, repair the routine before adding more topics. A smaller disciplined routine can outperform a larger unfocused one.
The Routine as a Personal Learning Operating System
Over time, the routine becomes an operating system for learning. The inputs are real tasks and sources. The processes are attempt, diagnosis, repair and transfer. The outputs are checked artifacts and stronger skills. The feedback is the error log.
This system is portable. A new SI tool can be inserted into the routine and evaluated using the same standards. The learner does not have to start from zero because the learning process itself is stable.
That is the deeper purpose of the first SI routine: not to create a habit of using one product, but to create a habit of learning intelligent tools with evidence and control.
The Routine Failure Library
A learning routine improves when repeated failures have names. The names do not need to be technical diagnoses of a model. They are working descriptions that help you choose the next exercise instead of changing everything at once.
- Task drift: the session begins with one learning objective and ends with unrelated exploration.
- Source drift: the answer no longer reflects the supplied material or uses an outdated version.
- Meaning drift: a rewrite changes a date, owner, obligation, uncertainty or other protected detail.
- Verification drift: checking becomes weaker as the learner gets faster or more confident.
- Transfer failure: a method works on the repaired example but fails on fresh material.
- Tool drift: new tools are added without a clear job and the workflow becomes harder to understand.
- Routine inflation: the learner keeps adding templates and checklists until practice itself becomes burdensome.
- Independence failure: the learner can follow SI assistance but cannot perform a comparable task without it.
When one of these patterns appears, select the smallest repair. Task drift may need a one-sentence objective at the start. Meaning drift may need a protected-facts checklist. Transfer failure may need three fresh examples. The routine becomes stronger when the correction is proportional to the problem.
The Routine Transfer Ladder
Level 1 — Repeat the same skill with new surface details
Change names, numbers, dates or topic while keeping the underlying skill constant. This is the simplest transfer test because the learner can see whether the method survives beyond the original example.
Level 2 — Change the format
Move from a paragraph to a table, from notes to a document or from a short explanation to a checklist. The learner must recognise the same control principle in a different representation.
Level 3 — Change the domain
Apply the skill in another subject or work context. Meaning preservation learned on school notices can transfer to workplace messages. Denominator checking learned on attendance can transfer to conversion rates or survey percentages.
Level 4 — Add one operational tool
Only after the manual skill is stable should the learner add search, a calculator, file access or another application. The purpose of the tool must be explicit and its result must have a checking method.
Level 5 — Build the reusable workflow
Document the input requirements, steps, checks, receiver, closure and stop conditions. A skill reaches a strong practical stage when another authorised person can use the workflow without depending on the original learner’s undocumented memory.
A Routine Audit at the End of Every Month
A monthly audit prevents practice from turning into habit without improvement. Select three recent tasks: one that went well, one that failed and one that required substantial repair. Compare what the routine did in each case.
Ask whether the acceptance criteria were clear before generation. Check whether source or input quality caused failures that were mistakenly blamed on prompting. Review whether verification was strong enough for the consequence of the task.
Then inspect the routine itself. Which step catches important errors? Which step has become redundant? Which recurring failure does the routine not yet address? Simplify low-value ceremony and strengthen the missing control.
Finish the audit by choosing one capability for the next month. Do not attempt to improve everything. A focused learning cycle produces clearer evidence than a constantly expanding list of goals.
Routine Design for Search and Current Information
When a task depends on current information, build freshness into the routine. State what date or time window matters. Prefer current authoritative sources when the question concerns an organisation’s own rules, schedules or data.
Save the source identity and relevant passage with the learning record. This makes later review possible when the information changes. A strong routine distinguishes knowledge that is stable from knowledge that must be retrieved again.
Do not assume that every answer in a conversational interface used current search. Treat retrieval as an observable step. The learner should know whether the answer came from a supplied source, a live search or general model knowledge.
Routine Design for Long Documents
Long documents create a different learning problem from short passages. Before asking for a full summary, map the structure: title, sections, appendices, tables and any part that contains the decision or data you actually need.
Work section by section when necessary. Preserve page, heading or other location information so important claims can be traced back. Then produce the synthesis from checked section notes rather than from an unverified memory of the entire document.
A routine for long documents should also state what to omit. Not every detail deserves equal compression. Define the reader and their next action before deciding what counts as relevant.
Routine Design for Collaborative Work
When several people use SI on the same project, create a shared current-state brief. Include objective, source owners, current decisions, unresolved questions and approval rules. This reduces contradictions caused by different conversations carrying different versions of the project.
Agree on which records are authoritative. A generated summary should not become the source of truth simply because it is easier to read than the original decision log.
At handoff, include what changed during the session and what still requires action. The routine should support collaboration between people, not create a private intelligence silo around whoever owns the longest conversation.
Routine Design for High-Consequence Work
The routine should become stricter as the consequence of error rises. Add stronger source checks, independent review, explicit permissions and reversible stages. Draft before publish. Test before deploy. Propose before changing shared records.
SI can still be useful in high-consequence workflows for organising information, drafting and generating questions. The routine must make clear which decisions require qualified human expertise or organisational approval.
The learning objective here is not maximum autonomy. It is learning how to use powerful assistance without losing accountability.
A Routine Handoff Test
Take one workflow you believe is stable and give its written instructions to another authorised person, or simulate a clean session with no prior conversation. Observe what is missing.
If the person does not know which file to use, the input requirement is incomplete. If they cannot tell whether an output is acceptable, the check is incomplete. If they do not know whether they are allowed to send or publish, the permission boundary is incomplete.
Repair the handoff until the method is understandable without oral explanation. This turns personal skill into reusable organisational capability.
A Routine Retirement Rule
Not every practice exercise should remain permanent. Once a skill transfers reliably, reduce dedicated drill time and maintain it through normal work. Archive prompts and checklists that no longer add protection.
Retire tools whose unique value has disappeared. Remove permissions that are no longer needed. Consolidate duplicate workflows that solve the same problem.
The best routine becomes lighter as understanding grows. It keeps the controls that still matter and discards the ceremony that no longer teaches or protects anything.
The Routine Completion Standard
Before moving to the next major SI topic, you should be able to define one recurring task, name the skill being practised, state the acceptance check, diagnose a meaningful failure and transfer the repair to a fresh example.
You should also know when the task requires evidence, another tool or another person. A routine that only teaches how to keep prompting is incomplete.
When these behaviours become normal, the routine has done its job. You are ready for Stage 2: communicating tasks with greater precision through instruction design, prompting, context and examples.
The Routine Transfer Gate
Before describing your routine as stable, use it on a task from a different surface context. If you learned source fidelity on school notices, test it on a short meeting brief. If you learned percentage checking on attendance, test it on assignment completion. Preserve the underlying skill while changing the surface.
Write the acceptance conditions before the transfer attempt. Do not loosen them merely because the new task feels unfamiliar. If the method fails, identify which new condition exposed the weakness.
Transfer protects the routine from becoming a collection of memorised examples. The point of daily practice is to build a method you can carry into tomorrow’s unfamiliar task.
The Routine Handoff Gate
A mature routine should be understandable to another authorised learner or colleague. Write a one-page handoff containing purpose, required input, steps, checks, stop conditions and expected output.
Give it to someone else or simulate a clean session. Note which pieces of hidden knowledge are missing. Add only what is necessary. A routine that depends on undocumented memory is fragile.
Handoff is also a useful learning test. If you can explain why each step exists, you probably understand the process more deeply than if you can only repeat the sequence.
The Routine Retirement Gate
Every few weeks, identify one drill, prompt or tool that no longer exposes a meaningful weakness. Test whether removing it changes quality. If not, retire it from deliberate practice.
Retirement protects attention. The routine should not become longer forever. Mature learning systems simplify stable skills and redirect effort toward the next genuine bottleneck.
The goal is a small, high-value practice system that continues evolving as your work and SI tools change.
Your First Routine Can Begin With One Checked Task
Choose one real task today. Write the skill target and acceptance standard before asking SI for help. Preserve the first attempt, perform the check and record one lesson.
Repeat the process on a fresh example. That is enough to begin. The routine becomes more sophisticated only when the work demands it.
Return to the complete SI learning hub whenever you need to choose the next skill. A durable routine does not teach you to depend on one interface. It teaches you how to learn intelligent systems themselves.
Deep connection: place this topic inside the wider Super Intelligence master framework, then follow the practical sequence through how Super Intelligence works, what SI can and cannot do, and the core SI skills.
Deep connection: place this topic inside the wider Super Intelligence master framework, then continue through how Super Intelligence works and the core SI skills.