What can Super Intelligence do, and what can it not do? The useful answer is not a giant list of impressive features. A strong SI user learns to distinguish capability from access, fluent output from verified work, assistance from authority and a generated proposal from an action that actually happened.
Super Intelligence can help with explanation, writing, research, coding, data analysis, planning, image creation, document work and multi-step workflows when the required information and tools are available. But an SI system can also produce wrong facts, invented citations, weak reasoning, incorrect calculations, outdated information or confident guesses when evidence is missing.
This eduKateSG guide explains the practical capabilities and limits of contemporary AI systems, how connected tools change what they can do, and how to decide whether an output deserves trust. It continues Stage 1 of the How to Learn Super Intelligence Quickly curriculum after thinking with SI instead of just asking questions.
Terminology: In this series, Super Intelligence or SI is our editorial term for practical contemporary AI learning. We are not claiming that a particular product meets the stronger research definition of superintelligence.
The First Rule: Ask “Under What Conditions?”
The question “Can SI do this?” is usually incomplete. A more useful question is “Can this system do this task with these inputs, these tools, these permissions and this verification method?” The answer often changes when one of those conditions changes.
For example, a language model may be capable of analysing a spreadsheet, but it cannot analyse a spreadsheet it has not received. A system may be capable of searching the web, but only if search is available and actually used. It may be capable of drafting an email while lacking permission to send it.
This condition-based view prevents both underestimation and overconfidence. You do not need to treat SI as magic, and you do not need to treat it as a simple text autocomplete tool. You need to understand the operating environment of the specific task.
What Super Intelligence Can Do Well in the Right Conditions
Explain concepts in different ways
SI can often rephrase a difficult idea, generate examples, compare explanations and adapt language for different readers. This is useful in learning because a student who does not understand one explanation may benefit from another representation.
The limitation is that clarity does not guarantee correctness. A beautifully simple explanation can oversimplify a rule or introduce a misconception. The learner should compare important explanations with trusted sources, teacher guidance or independently verifiable reasoning.
Summarise and reorganise information
When the source is available, SI can condense long material, extract themes, identify action items and reorganise information into structured formats. This can reduce the effort required to navigate large documents.
The limitation is source fidelity. Important qualifiers, exceptions, owners or dates can disappear. A summary should therefore have a preservation standard: which information must survive, which detail may be compressed and which uncertainty must remain visible.
Rewrite for audience and purpose
SI can turn technical language into plain language, make a draft more concise, adjust tone or reorganise a message. The most useful editing workflows state what may change and what must not change.
The limitation is semantic drift. An optional action can become compulsory, an uncertain promise can become a guarantee or a technical caveat can be removed. This is why meaning preservation is a core SI skill.
Generate ideas and alternatives
SI is particularly useful for expanding the search space. It can propose headings, lesson activities, product ideas, research questions or alternative solution paths quickly.
The limitation is that novelty and feasibility are separate. Generated ideas may be repetitive, unrealistic or based on unstated assumptions. Use SI to broaden possibilities, then apply evidence and domain judgment to narrow them.
Support research
With current retrieval tools, SI can help locate sources, compare documents and produce cited summaries. This can make research faster because search, extraction and synthesis can occur in one workflow.
The limitation is that retrieved sources still need evaluation. Search results can be outdated, weak or irrelevant. A citation may exist without supporting the sentence attached to it. Important research requires source checking and attention to population, date and scope.
Work with data
SI can help interpret tables, write formulas, calculate statistics, create charts and explain results. Connected code or data-analysis tools can improve precision for computation.
The limitation is that a correct calculation can answer the wrong question. A percentage can use the wrong denominator. A chart can use a misleading scale. An average can hide a skewed distribution. Users need numerical literacy as well as computational capability.
Write and explain code
SI can generate functions, explain unfamiliar code, suggest tests and help debug errors. This is valuable for both learners and experienced developers because it reduces the friction of exploring unfamiliar libraries or patterns.
The limitation is that generated code may be insecure, inefficient, outdated or subtly wrong. Code should be read, tested and reviewed in an appropriate environment. A passing demonstration is not the same as production readiness.
Create documents and presentations
SI can turn structured information into reports, lesson plans, proposals, tables and presentations. The main advantage is the ability to connect content structure with language production.
The limitation is that formatting quality can hide content weakness. A polished deck may contain unsupported claims or poor data interpretation. Check the content before trusting the visual finish.
Create images and multimodal content
Image-generation systems can create illustrations, concept art, diagrams, layouts and other visuals from descriptions. Multimodal systems can also analyse images and combine visual and textual information.
The limitation is visual accuracy. Small labels, counts, physical relationships or text inside images can be wrong. Important diagrams and factual visualisations require inspection, and some tasks are better served by deterministic diagramming or charting tools.
Use connected tools
When granted access, SI can sometimes search, calculate, work with files or interact with external applications. This turns a conversational system into a workflow system.
The limitation is operational. Tool availability, permissions and failures matter. The system may propose an action it cannot execute, or a tool call may fail. Consequential results should be checked in the destination system.
What Super Intelligence Cannot Reliably Do by Itself
Guarantee truth
OpenAI’s current guidance on answer reliability states that ChatGPT can produce incorrect or misleading outputs and may sound confident when wrong. This is a general lesson for language-model use: confident language is not evidence.
The practical consequence is not that every answer is useless. It is that important factual claims need a verification method appropriate to the task.
Know information it does not have
A system cannot reliably analyse an unseen private document, an unavailable database or a live event it has not retrieved. It may still produce a plausible answer based on patterns, which is exactly why users must distinguish access from capability.
If the task depends on a specific record, make that record available through an authorised method or consult it directly.
Resolve every ambiguity correctly
Human language contains underspecified references, conflicting instructions and vague objectives. SI can ask questions or choose an interpretation, but it cannot guarantee that the chosen interpretation matches the user’s hidden intention.
Good users surface ambiguity early. When two meanings would lead to different actions, clarification is more valuable than confident completion.
Take responsibility for a decision
SI can compare options, calculate consequences and surface assumptions. It does not remove human responsibility for goals, values, professional duties or organisational authority.
Important decisions should preserve the human decision-maker and the reasons for the choice. This is especially important where the consequences affect other people.
Prove that learning occurred
An SI tutor can explain a concept or solve a problem, but the resulting response does not demonstrate that the student can perform the task independently.
Learning requires transfer. Use fresh questions, retrieval practice or unaided explanation to test the learner’s own capability.
Guarantee that an external action succeeded
A generated sentence saying “the file was updated” is not proof unless an actual tool call occurred and the result can be confirmed. The same applies to messages, calendar events, database updates and other external changes.
The destination record is stronger evidence than a conversational claim about the destination record.
Capability, Access, Permission and Verification Are Four Different Things
These four concepts should be kept separate because many SI mistakes come from blending them together.
- Capability: the system knows how to perform a type of task.
- Access: the information or external system is actually available to the task.
- Permission: the user or organisation has authorised the relevant read or write action.
- Verification: there is evidence that the result is correct or the action succeeded.
A system may have capability without access, access without permission, permission without successful execution or successful execution without a sufficiently checked result. Mature SI use tracks all four.
Knowledge Freshness: Why Time Matters
Some questions are relatively stable. The definition of a mathematical term may not change frequently. Other questions—prices, schedules, laws, software versions, company leadership and current events—can change quickly.
For changing information, the workflow should use current sources when available. OpenAI’s current help documentation notes that language models have knowledge limits and that search tools can improve access to up-to-date information.
A useful answer should make freshness visible. State when the source was published or accessed when that matters. Do not present old evidence as if it were a current measurement.
Hallucinations: A Practical Definition
A hallucination is an output that presents unsupported or inaccurate information as if it were established. The problem can include invented citations, false dates, fabricated quotes or details that were simply missing from the source.
Hallucinations are especially dangerous when the invented detail is plausible. A wrong room number can look ordinary. A fake academic citation can look professionally formatted. Plausibility delays detection.
The repair is evidence tracing. Ask which claims matter, identify the source capable of supporting each claim and remove or qualify claims that cannot be established.
Reasoning: Strong Assistance, Not Guaranteed Correctness
SI can organise complex reasoning, compare alternatives and follow multi-step instructions. These capabilities can be genuinely useful. However, reasoning outputs can contain hidden assumptions, missed constraints or invalid intermediate steps.
For mathematics, check the operation. For logic, test the conclusion against premises. For planning, inspect dependencies and constraints. For research, verify the evidence. A long chain of reasoning is not automatically a correct chain of reasoning.
Calculations: Use the Right Tool for the Right Layer
Simple arithmetic should still be checked. Where deterministic calculation tools are available, use them for exact computation and use SI for explanation or interpretation.
The more important issue is often not arithmetic but model choice. If nine of twelve registered students attended, 75% is the correct attendance rate relative to registrations. But if the question asks about expected attendance after excused absences, the denominator may need a different definition.
The user remains responsible for deciding what the numbers mean.
Files: Naming a File Is Not the Same as Reading It
Users often assume that if they mention a filename, the SI system can inspect it. That depends on whether the file is uploaded, connected or otherwise available.
For file-based work, confirm the source identity and relevant section. A useful workflow can cite page numbers, headings, ranges or other locators when the file format permits it.
If a file cannot be accessed, the correct response is to request or locate the file rather than inventing an analysis based on its name.
Search: Retrieval Does Not Eliminate Judgment
Search expands the system’s access to current and niche information. It does not guarantee that the first result is authoritative or that a source is being interpreted correctly.
Evaluate author, date, methodology, relevance and authority. Prefer original or official sources when the question concerns an organisation’s own rules or data. Use secondary sources to add context, not to overwrite primary evidence without reason.
Privacy and Confidentiality
A capable system can still be inappropriate for a particular document. Before sharing information, consider whether you are authorised to use it with the chosen service and whether the information contains personal, confidential or regulated material.
Use invented examples for practice whenever possible. In professional settings, follow organisational policies, contractual obligations and applicable law.
Bias and Simplification
Language models learn patterns from large bodies of data and can reproduce oversimplification or bias. They may also present one perspective as universal when the underlying issue is contested or culturally dependent.
For important topics, ask which perspective, population and assumptions the answer represents. Compare relevant sources. Do not treat neutrality of tone as proof of completeness.
Images: Visual Plausibility Is Not Visual Proof
Generated images can be compelling, but they should not be used as evidence that an event happened. A synthetic photograph can depict a realistic scene that never existed.
For educational diagrams, inspect labels, counts and relationships. For charts, use data-driven plotting tools when exact numerical representation matters.
Coding: A Working Example Is Not a Secure System
Generated code can accelerate prototyping, but production software has requirements beyond functionality: security, error handling, maintainability, performance, permissions and deployment practices.
Write tests before or alongside implementation. Include boundary cases. Review dependencies. Treat generated code as code that must earn trust through the same engineering discipline as human-written code.
Agents: Greater Autonomy Creates Greater Control Requirements
An agent can choose actions over several steps. This is useful when the task path cannot be completely predetermined. It also increases the number of ways a process can fail.
Use agents when the environment provides enough feedback for the system to judge progress and when tools have appropriate permissions. Keep stop conditions and human checkpoints for consequential actions.
Do not measure sophistication by autonomy alone. A predefined workflow can be the better system when the task is stable and predictable.
A Worked Capability Test
Use this fictional task: “Prepare a reminder from the following note: The science club meets Thursday at 3.30 pm for forty minutes. Mei will bring two demonstrations. The room has not been confirmed.”
Capability test 1: ask SI to create the reminder. Check whether it preserves Thursday, 3.30 pm, forty minutes and Mei’s responsibility.
Capability test 2: ask where the meeting will be held. A good answer should state that the room is not confirmed, not invent one.
Capability test 3: ask it to send the reminder. If no messaging tool or permission exists, it should not claim that the message was sent.
The same conversation demonstrates three different boundaries: language capability, missing information and unavailable external action.
A Worked Research Test
Question: “What is the current guidance from an organisation?” The test requires live or current retrieval if the guidance may have changed.
Ask SI to find the official source. Open the source. Locate the relevant passage. Record the date and scope. Then ask for a summary limited to what the source actually states.
Next, ask what the source does not answer. This reveals whether the system can preserve uncertainty instead of turning the source into a complete explanation of every related question.
A Worked Learning Test
Give a student an equation such as 5x + 4 = 29. The student should attempt it first. If they stop at 5x = 25, ask SI for a hint rather than the answer.
After the explanation, use a fresh question such as 3x + 7 = 22. Independent success on the new question is stronger evidence of learning than agreement with the original explanation.
A Worked Tool-Permission Test
Imagine an SI system can read a calendar and create events. Ask it to propose three available times without making changes. A correct workflow uses read access and returns suggestions.
Then ask it to book a time. That is a different action. It should require the appropriate permission and confirmation according to the workflow. After creation, verify the actual calendar event.
The “Can / Cannot / Requires” Framework
- Can: tasks the system can perform under the current conditions.
- Cannot: tasks outside its actual access, capability or reliable operating envelope.
- Requires: tasks that become possible only with additional evidence, tools, permissions, expertise or verification.
This framework is more useful than a binary yes/no list because many SI capabilities are conditional. “Can analyse my PDF” becomes “requires the PDF to be available and important claims to be checked.”
When to Use a Human Expert
Use qualified human expertise when the task requires professional judgment, accountability or domain knowledge beyond what you can independently verify. SI can help organise questions and prepare material for that expert.
This is not a failure of the tool. It is good task routing. Strong users know when the next component in the system should be another person.
When to Use a Deterministic Tool
Use a deterministic tool when exact reproducibility matters and the problem is well specified. Calculators, formulas, scripts and databases often provide stronger guarantees for specific operations than free-form generation.
SI can still help write the formula, explain the result or integrate it into a broader workflow. The components should be chosen according to their strengths.
How to Evaluate a New SI Capability Claim
When a product announcement says a system can perform a new task, translate the claim into a test. What input does the capability need? What output should it produce? What counts as failure? What external access is required?
Run the test on safe representative cases. Include a normal case, a missing-information case and a boundary case. Record what actually happens.
Do not assume one impressive demonstration represents every domain. Operating envelopes matter.
A Receiver-Centred Capability Test
The output is useful only if the receiver can act on it. A manager needs a decision-ready brief. A student needs an explanation that supports independent learning. A software component needs predictable structured data.
Ask whether the result gives the receiver enough correct information without hiding uncertainty. If the next person must reconstruct important context, the task is not fully complete.
Observable Closure: Know When Capability Testing Is Finished
A capability test should end with a clear result: works under these conditions, fails under these conditions, or requires additional information or tooling. Endless prompting does not improve the test.
Document the boundary. Knowing when a tool cannot be trusted is itself useful knowledge.
Frequently Asked Questions
Can Super Intelligence replace search engines?
Sometimes it can integrate search into a more conversational workflow, but search remains a distinct retrieval function. For current information, inspect the sources and dates rather than assuming generated recall is current.
Can SI replace a calculator?
It can often perform arithmetic, but deterministic calculation tools are better suited to exact repeated computation. Use SI for explanation and workflow support while checking important numbers.
Can SI replace teachers?
SI can support explanation, practice and feedback. Education also involves curriculum judgment, safeguarding, motivation, social interaction and professional responsibility. Use SI as part of a learning system rather than assuming generation equals teaching.
Can SI replace programmers?
SI can generate and explain code, but software engineering includes specification, testing, architecture, security, maintenance and deployment. Human technical judgment remains important.
Can SI replace human decision-making?
It can support decisions by organising information and alternatives. Human goals, values, accountability and authority remain central, especially for consequential choices.
Can SI know when it is wrong?
It can sometimes identify inconsistencies or critique its own output, but self-critique is not independent proof. Important claims should be checked through evidence or external validation.
Can SI learn from my current conversation?
It can use information present in the current context, subject to the product’s design and limits. Do not confuse temporary context with permanent model training or a complete long-term project record.
What should I learn next?
Continue with How to Build Your First Super Intelligence Learning Routine, then move into Stage 2 with How to Write Better Instructions for Super Intelligence and How Prompting Super Intelligence Really Works.
A Capability Audit You Can Run on Any SI System
Instead of asking whether a system is powerful in the abstract, create a capability audit. Choose a task category, define the expected output, identify what information and tools are required, and run several representative tests. Include at least one case where the correct result is to refuse, clarify or admit missing information.
A good audit separates capability from reliability. A system may demonstrate that it can summarise a source, but the audit also asks how often it omits protected details, whether it recognises missing information and how much human checking is needed before the summary can be used.
Use the same acceptance criteria across comparable tests. If you change the source difficulty, output format and evaluation standard at the same time, the result becomes harder to interpret. Capability audits are useful because they turn vague impressions into observable behaviour.
Audit dimension 1 — Accuracy
Does the output preserve facts, names, dates, quantities and relationships? For a source-grounded task, compare the response with the actual source. For a calculation, reproduce the arithmetic. For code, run tests.
Audit dimension 2 — Completeness
Does the system include the information required for the receiver to act? Completeness does not mean including everything. It means preserving the subset that the task specification says is necessary.
Audit dimension 3 — Uncertainty handling
What happens when information is missing or conflicting? A strong system may ask for clarification or label the uncertainty. A weak system may fill the gap with a plausible invention.
Audit dimension 4 — Tool transparency
When a tool is involved, can you identify what source was searched, which file was read or whether an external action succeeded? Tool use should create more evidence, not less visibility.
Audit dimension 5 — Recovery
When the first answer fails, can the workflow be repaired without rebuilding everything? A recoverable system makes errors local enough to diagnose and correct.
A Capability Map for Students
Students often encounter SI through homework help, explanation, summarisation and practice generation. The most useful student capability is not “get the answer”. It is “receive assistance that increases independent understanding without hiding what the learner can actually do.”
SI can explain a difficult paragraph, generate vocabulary examples, create practice questions, provide feedback on a draft and compare solution methods. It can also make mistakes in answer keys or give explanations that are too advanced for the learner.
A student should therefore combine SI capability with independent checkpoints: attempt before asking, explain the method afterward and use fresh practice to test transfer. Teachers and schools may also have rules about permitted use in assessed work, and those rules should be followed.
A Capability Map for Teachers
Teachers can use SI to brainstorm lesson structures, produce examples, adapt reading levels, create drafts of practice material and organise feedback. These capabilities can reduce preparation friction when the teacher already has a clear learning objective.
What SI cannot do is replace professional knowledge of the class, safeguarding responsibilities or curriculum judgment. Generated material may contain subtle errors or inappropriate difficulty. Answer keys require checking. Learner data should be handled according to applicable policies and permissions.
The highest-value use is often controlled preparation: SI creates a draft, the teacher checks accuracy and suitability, and the final material reflects professional judgment.
A Capability Map for Writers and Editors
Writers can use SI for outlining, restructuring, headline exploration, editing, comparison and research assistance. Editors can ask it to identify repetition, unclear transitions or inconsistent terminology.
What SI cannot guarantee is originality, factual accuracy or preservation of voice. A rewrite may flatten distinctive language. A research paragraph may introduce unsupported claims. A style imitation request may also create ethical or copyright concerns depending on the task.
Use SI to widen options and improve structure while keeping authorship decisions, sourcing and final voice under human control.
A Capability Map for Researchers
Researchers can use SI to help formulate questions, identify search terms, organise literature, compare sources, create code for analysis and explore hypotheses. Retrieval and document tools can make large bodies of material easier to navigate.
What SI cannot guarantee is methodological validity. It may misunderstand a paper, overlook a limitation or propose a statistically inappropriate method. Generated citations can be false if they are not grounded in actual retrieval.
Research workflows should preserve source identity, methods, dates and uncertainty. Hypotheses generated by SI remain hypotheses until tested through an appropriate research method.
A Capability Map for Managers
Managers can use SI for briefing, scenario exploration, comparison frameworks, meeting synthesis and preparation of decision materials. The system can help identify missing information and make assumptions explicit.
What it cannot do is own the organisational decision or the consequences of that decision. Goals and trade-offs remain human. A recommendation may also depend on data that the model cannot access or context that has not been supplied.
A strong management workflow therefore separates preparation, analysis and human decision. The final record should state why the choice was made and what evidence could trigger review.
A Capability Map for Programmers
Programmers can use SI for code generation, debugging, explanation, test creation, refactoring and documentation. These capabilities can increase development speed and make unfamiliar code easier to understand.
What SI cannot guarantee is security, correctness or maintainability. Generated code may use outdated APIs, ignore edge cases or introduce dependencies that are unsuitable for the project.
Use tests, static analysis, code review and appropriate development practices. A useful model response is an engineering input, not a substitute for the engineering process.
A Capability Map for Business Operations
Operations teams can use SI to classify requests, draft replies, extract fields, produce reports and support workflow routing. These tasks can be highly repeatable and therefore attractive candidates for automation.
The main limitation is consequence at scale. One incorrect classification in a manual workflow can be noticed; thousands of automated misclassifications can spread quickly. Automation therefore needs test sets, exception handling, monitoring and human escalation where appropriate.
Start with reversible preparation work and measure the error pattern before expanding external write actions.
The Importance of Negative Capability
A mature SI system should sometimes say that it cannot establish the answer. This is a form of useful negative capability: recognising the boundary instead of manufacturing certainty.
Examples include a missing denominator, an unavailable document, conflicting authoritative sources, a current fact that has not been retrieved or an external action that lacks permission.
Users should reward this behaviour rather than forcing completion. “I do not have enough information” can be the most accurate answer available.
The Importance of Refusal and Constraint
Some limits are not technical weakness. They are safeguards or policy constraints. A system may refuse a harmful, unsafe or unauthorised request even if it could theoretically generate related information.
From a workflow perspective, refusal is a state that should be handled. The user can narrow the task, use a safer method or seek an appropriate authorised route. Do not design processes that depend on bypassing legitimate controls.
Confidence Calibration
One of the most important user skills is calibrating confidence. The strength of the conclusion should match the strength of the evidence. A verified official source can support a stronger statement than an unconfirmed recollection.
Ask SI to label uncertainty when useful, but do not treat numerical confidence generated in prose as scientifically calibrated unless the system and task provide a validated basis for that number.
Use qualitative language carefully: confirmed by source, supported by available evidence, plausible but unverified, or unknown. This makes the evidence state visible to the receiver.
Why Fluent Language Can Hide Capability Boundaries
Language models are designed to continue patterns coherently. That makes them useful communicators, but the same fluency can make gaps less visible. A response may smoothly move from sourced fact to inference without announcing the transition.
Users should add structural boundaries. Separate “from the source”, “interpretation”, “suggestion” and “information needed”. This formatting makes hidden epistemic shifts easier to inspect.
The goal is not to distrust every sentence. It is to make the status of important sentences visible.
Why Multi-Step Tasks Need Intermediate Checks
As tasks become longer, one early error can propagate. A wrong date can enter a schedule, a report and an email. A wrong unit can enter a chart and a recommendation.
Place checks before expensive downstream steps. Verify source extraction before calculation. Verify calculation before visualisation. Verify the final draft before external action.
This pattern is one of the main differences between casual SI use and dependable workflow design.
Capability Drift Over Time
Systems change. Models are updated, interfaces gain new features, tools are added or removed and provider policies change. A capability test from months ago may no longer describe the current system exactly.
For important workflows, keep a small regression set and rerun it after material changes. Document the current tool or configuration when reproducibility matters.
This protects against both improvement and regression. A new system may solve an old failure, or it may create a new one.
A Capability Boundary Exercise
Choose one task you believe SI performs well. Write three versions: an ordinary case, a difficult case and a case that should stop because required information is missing.
Run all three with the same acceptance criteria. Record where the system succeeds, where it needs repair and where it correctly refuses or asks for information.
Your result is a small operating envelope. You now know more than “the system is good at this”. You know the conditions under which the claim is supported.
A Permission Boundary Exercise
Choose one connected application and list what the SI system can read, draft, create, update and delete. Then mark what the user has actually authorised for the workflow.
Any capability outside the authorised set should be treated as unavailable for the task, even if the connector technically permits it. This is how workflow authority remains human-readable.
Add confirmation requirements for consequential actions. A tool stack becomes safer when permissions are designed around the job rather than around maximum access.
A Verification Boundary Exercise
Take one generated factual answer and classify every important claim by verification method. Some claims may be checked against a supplied document, others against a current official source and others through calculation.
If a claim has no reasonable verification path, ask whether it belongs in the final output. Unsupported completeness is often worse than explicit uncertainty.
A Receiver Boundary Exercise
Give the same verified information to three receivers: a beginner student, a specialist colleague and a software system. Ask what each needs to use the information correctly.
The student may need explanation. The specialist may need source detail. The software system may need structured fields. Capability includes adapting output to the receiver without changing the underlying facts.
Capability Claims and Marketing Language
Product descriptions often compress many conditions into a short claim such as “analyse your data” or “automate your workflow”. Translate these claims into operational questions before relying on them.
Which data formats? How much data? Which actions? What permissions? Which failure cases? What is the evidence of success? What must still be reviewed by a person?
This approach respects genuine progress without turning marketing language into untested assumptions.
A Final Capability Examination
Select a task that uses at least two SI capabilities—for example, search plus summarisation or file reading plus calculation. Define the source, expected output, verification and stop condition.
Run the task. Verify each major step. Introduce one missing-information case. Introduce one conflicting-information case. Observe whether the workflow remains understandable.
Then write a one-paragraph capability statement: what the system can do under the tested conditions, what it cannot establish and what additional tools, evidence or permissions would be required for the next level.
That statement is more valuable than a universal claim. It is grounded in observed behaviour and can be updated as the system changes.
Capability Must Be Matched to Risk
A capability is more useful when the amount of supervision matches the cost of error. A private brainstorm can tolerate speculative suggestions because the output is not yet acting on the world. A public factual article requires stronger source checks. A workflow that changes records, money, schedules or access rights deserves even stronger controls.
NIST describes its AI Risk Management Framework as a voluntary resource for incorporating trustworthiness considerations into the design, development, use and evaluation of AI systems. The individual-user version of that principle is simple: increase the quality of evidence, review and approval as consequence rises.
This does not mean treating every SI interaction as high risk. Proportionality matters. Overchecking trivial tasks wastes attention. Underchecking consequential tasks creates avoidable exposure. A mature user learns to distinguish the two.
Human-Centred Use Is a Capability Requirement
UNESCO’s AI competency framework for students includes a human-centred mindset, ethics, AI techniques and applications, and AI system design. That broader framing matters because practical capability is not only about what the system can generate. It is also about how people use the system and whether the use strengthens or weakens human learning, agency and responsibility.
In education, a system that produces every answer perfectly can still be used badly if it removes the learner’s opportunity to practise. In management, a system that produces a recommendation can still be used badly if the recommendation quietly replaces an accountable human decision. In creative work, a system that produces many options can still be used badly if the creator stops making meaningful choices.
The correct capability question therefore includes the human objective. What can the tool do that helps the person perform the real job better? Which parts should remain human because they are the learning target, value judgment or responsibility?
Capability Maintenance After Publication or Deployment
A capability test should be repeated when the environment changes. A new model version, different source collection, new connector or altered permission can change the behaviour of the same workflow. Keep a small set of benchmark tasks containing normal cases and historical failure cases.
Rerun them after material changes. If the system improves, you may be able to simplify some controls. If an old failure returns, restore the missing check. Do not assume that a workflow stays reliable forever simply because it once passed a test.
Maintenance also includes source freshness. A current-information workflow should not keep using an old official page merely because the page was authoritative when the workflow was first designed. The source layer needs maintenance just as the model layer does.
Capability Retirement
Some capabilities become unnecessary. A tool may be replaced by a more reliable deterministic process. A connector may retain access long after a workflow stops using it. An old prompt may duplicate a stronger current workflow.
Retire unnecessary components deliberately. Archive the old method when useful for history, remove permissions that are no longer needed and keep the smallest active system that still meets the task. Reducing complexity is part of capability management.
This matters because every retained component adds something to maintain, understand and potentially misconfigure. A lean system with clear roles is often easier to trust than a large stack of overlapping capabilities.
The Final Capability Standard
Before you describe an SI system as capable of a task, be able to answer seven questions: What is the task? What information does it receive? Which tools does it use? What permissions does it have? What output should it produce? How will important claims or actions be verified? What should happen when the task cannot be completed safely or correctly?
If those questions have clear answers, you have an operational capability statement. If they do not, the claim is still too vague. Narrow the task until the operating envelope becomes understandable.
This is the standard that protects the rest of the SI curriculum. Future systems may become more capable, faster and more autonomous. The user’s durable advantage is the ability to evaluate those capabilities without confusing fluency, access, authority and evidence.
A Capability Boundary Worksheet
Use this worksheet whenever a new SI feature appears. Begin with one concrete task rather than the product description. Write the intended input, expected output, the information source, the tools required, the permission level and the independent check.
Then test three conditions. First, the normal case: the required information is present and the task is clear. Second, the missing-information case: remove one fact needed for completion. Third, the boundary case: increase ambiguity, scale or consequence without changing the underlying task.
A strong capability has observable behaviour in all three conditions. It succeeds when the job is supported, asks or stops when essential information is missing and exposes its limits when the task moves outside the tested envelope. A weak evaluation only records the impressive normal case.
- Task: What exactly should exist when the work is complete?
- Input: What information or file is required?
- Tool: What external capability, if any, performs part of the job?
- Permission: What can the system read, draft or change?
- Normal case: What should success look like?
- Missing-information case: What should the system refuse to guess?
- Boundary case: What condition is likely to stress the method?
- Verification: What evidence outside generated wording shows the result is correct?
- Receiver: Who or what uses the output next?
- Closure: What tells the workflow to stop?
False Capability Signals
The answer is long
Length can create an impression of knowledge without increasing support. A short, sourced answer can be stronger than a long unsourced essay. Evaluate whether the answer addresses the task and whether the important claims can be checked.
The answer contains technical vocabulary
Technical language can be accurate, but it can also hide weak reasoning. Ask what each term means in the current task and whether the underlying relationship is demonstrated.
The system sounds certain
Confidence of tone is not confidence calibrated to evidence. A system may express a weak claim fluently. Preserve uncertainty when the source or task is uncertain.
A tool is connected
Connection does not prove successful use. Check whether the tool actually ran, whether it returned the expected object and whether the downstream workflow used the result correctly.
One demonstration worked
A successful example demonstrates that example. Transfer requires fresh cases, including missing and boundary conditions. Capability should be scoped to the evidence collected.
Capability Changes When Context Changes
The same SI system can appear dramatically more capable when it receives better context. A vague request such as “analyse this project” may produce generic advice. Supplying the objective, current state, source documents, constraints and open questions can transform the quality of the response.
This does not mean more context is always better. Irrelevant, outdated or contradictory information can reduce reliability. The skill is selecting the context that changes the answer while keeping source identity and version clear.
A useful practice is to run the same task with three context levels: minimal, sufficient and cluttered. Compare which details improve the result and which details create confusion. This builds context judgment rather than a habit of pasting everything available.
Capability Changes When Tools Change
A language-only system and a tool-augmented system may share the same conversational interface while having different operational abilities. Search can add current retrieval. Code execution can add deterministic computation. File access can add project-specific evidence. Application connectors can add external actions.
Because the interface looks similar, users may forget that tool results need their own validation. A search result has source quality. Code can throw errors. A connector can lack permission. The model’s response after a tool call should not erase the status of the tool call itself.
When comparing systems, record the full stack rather than only the model name. Capability is produced by the combination of model, context, tools, permissions and workflow design.
Capability Changes When the Consequence Changes
A method adequate for brainstorming may be inadequate for public factual publication. The difference is not necessarily the model’s raw capability; it is the level of evidence and control demanded by the consequence.
Scale review proportionately. A private idea list can tolerate speculative items that are clearly labelled. A student answer key should be checked. A customer-facing policy statement should preserve official wording and approvals. Code changing production data needs tests, permissions and rollback.
This is why asking whether SI is “reliable” in the abstract is less useful than asking whether a defined workflow is reliable enough for a defined task under defined controls.
A Receiver-Centred Capability Test
The receiver provides another way to test capability. Ask whether the person or system receiving the output can perform the next action correctly. A summary that omits the deadline is not capable enough for a reader who must submit something on time, even if the prose is elegant.
For students, the receiver is often the learner’s future independent performance. An explanation is useful only if it helps the learner solve a comparable problem. For managers, the receiver needs decision-ready evidence and unresolved risks. For software, the receiver may need strict structured data.
Capability should therefore be measured at the handoff, not only at generation. The downstream job reveals whether the output actually carried the required meaning.
A Maintenance Rule for Capability Claims
Tool capabilities change. Providers update models, interfaces, access rules and integrations. Treat capability statements that depend on current product behaviour as dated and revisable.
Keep durable statements at the level of principles: current data requires current evidence; access differs from permission; generation differs from execution; important outputs require verification. These remain useful even when a specific button or model changes.
When updating an article or workflow, change the product-dependent facts without destroying the stable learning architecture. This keeps the SI curriculum current without rebuilding every concept whenever one tool changes.
The Mature Answer Is Usually Conditional
The most accurate answer to “What can Super Intelligence do?” is rarely a dramatic yes or no. It is a conditional statement about task, information, tools, permissions, evidence and consequence.
Learn to ask what the system actually has, what the receiver needs and what would demonstrate correctness. That habit protects you from both fear and hype.
Use the complete SI learning hub to continue the curriculum. The goal is not to memorise a permanent capability list. It is to become able to evaluate new capabilities as they appear.
Continue the deeper path through How Super Intelligence Works, then connect it with core SI skills. These pages are part of the same Super Intelligence knowledge graph.
Continue through the SI knowledge web with How to Write Better Instructions for Super Intelligence. For the complete map, return to the Super Intelligence master guide.
Continue through the SI knowledge web with How to Write Better Instructions for Super Intelligence. For the complete map, return to the Super Intelligence master guide.
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.
Deep SI connections: Capability limits matter most when they change how you work. Connect this page to core SI skills, the SI tool mental model, and the Super Intelligence master guide.