If you are building something new, you are probably moving fast. You are coding, testing, fixing, talking to users, and trying to stay ahead. Patents can feel like one more thing pulling you away from real work. But when you do decide to protect what you built, one question shows up fast: should your patent use working examples, prophetic examples, or both?
This matters more than most founders think. The examples in your patent can shape how clear, strong, and useful your filing becomes. They can help explain what you built in a way that is easy to follow. They can also help show how your idea can be used in the real world. Done well, examples make your patent easier to understand and harder to attack.
And done badly, examples can create confusion you do not need.
That is why this guide exists.
We are going to walk through what working examples are, what prophetic examples are, how they differ, when to use each one, what mistakes to avoid, and how startup founders should think about examples when filing early but still filing smart.
If you want to protect what you are building without getting stuck in slow, old-school patent work, PowerPatent can help you move with speed and confidence. You can see how it works here: https://powerpatent.com/how-it-works
Why this question matters so much
Many founders think the hard part of a patent is the claim language. Claims do matter. They are the legal boundary around your invention. But claims do not stand on their own. They are supported by the rest of the application. That support comes from the written description, the drawings, and the examples.
Examples are where your patent starts to feel real.
A good example helps explain how the invention works, what steps happen, what parts are used, what data goes in, what comes out, and what changes from one version to another. It gives the reader something they can picture. It turns abstract ideas into a concrete story.
That matters because most inventions, especially in software and deep tech, are not simple. A founder may know exactly how the system works. The engineer may see the whole flow in their head. But the patent examiner, investor, or future judge does not live in your head. They only see what is written down.
Examples help close that gap.
They also matter because startups rarely have everything fully finished when they file. That creates tension. You want to file early because timing matters. But you also want your patent to reflect something real and useful, not just a vague dream. So you need to know how to write examples that protect what is already built and what is likely coming next.
This is where working examples and prophetic examples come in.
Understanding the difference helps you file without waiting too long and without saying the wrong thing.
What is a working example
A working example is exactly what it sounds like. It describes something that has actually been done.
That can mean you built the system and tested it. It can mean you ran the method in a lab. It can mean you trained the model, deployed the pipeline, or used the hardware in a real setup. The key point is that the example is based on work that really happened.
A working example usually comes from facts you already know.
You know what parts were used. You know the order of steps. You know what settings worked. You know what inputs were tested. You know what output came back. You may even know what failed before the final version worked.
That real-world grounding can be valuable because it gives the patent a strong sense of credibility and detail. It shows that the invention is not just a rough thought. It shows that at least one version was actually made or carried out.
For a startup founder, a working example may come from many places. It may come from your product code. It may come from a prototype demo. It may come from a benchmark run. It may come from a real customer workflow. It may come from an experiment your team ran in development. It may even come from a manual version of a process that you later automated.
A working example does not need to be fancy. It does not need to be perfect. It does not need to be a polished product at scale. It just needs to be real.
That last part is important. Many founders think, “We only have an early version, so it is not enough.” In many cases, it is enough. Early working examples can still be very useful if they clearly show how the invention works.
What is a prophetic example
A prophetic example describes something that has not yet been done, but is expected to work based on what the inventor knows.
The word “prophetic” sounds dramatic, but it really means forward-looking. It is a way to explain how the invention can be practiced even if that exact version has not been built or tested yet.
A prophetic example often uses future-style language. It may describe how a system can be configured, how a method may be performed, how a model may be trained, or how a device can be assembled and used.
This does not mean the example is fake. It does not mean the inventor is making things up. A proper prophetic example is grounded in real technical understanding. It is based on what a skilled person would reasonably expect to work from the disclosure.
That is why prophetic examples can be powerful, especially for startups.
Startups move fast. Your first version may already work, but your roadmap likely includes improved versions, more use cases, better model flows, broader hardware choices, and new deployment paths. If your patent only talks about what is already built today, you may miss the chance to protect where your invention is clearly heading.
A prophetic example lets you describe that future implementation in a way that expands support for your claims.
For instance, maybe today your system uses one ranking model and one specific data source. But you know the same core invention can work with other model types and other input streams. A prophetic example can help explain those versions even before they go live.
That can be very smart.
But it must be done carefully. A prophetic example should never pretend to be a completed experiment if it is not. It should never blur the line between what happened and what is merely expected. The value of a prophetic example comes from being honest, technically grounded, and clearly framed.
The simple difference
Here is the easiest way to think about it.
A working example says, in substance, “We did this.”
A prophetic example says, in substance, “This can be done this way.”
That is the core difference.
One is based on actual performance. The other is based on expected performance.
One points backward to completed work. The other points forward to a planned or likely implementation.
Neither is automatically better in every case. Each serves a purpose. The right choice depends on what stage your invention is in, how much data you have, what breadth you want, and how carefully the application is being drafted.
In many strong patents, both types appear together.
Why founders often get confused
Founders often hear a few broad ideas that sound simple but are not.
They hear that patents should describe something real. That is true. Then they hear that patents can cover future versions too. That is also true. Then they hear that too much speculation is risky. Also true. Then they hear that filing early matters most. Still true.
These ideas can sound like they pull in different directions.
So the founder asks: should I wait until I have more proof, or file now? Should I write only what I tested, or include what I know is coming next? Should I use measured results, or avoid them? Should I show one implementation, or many?
These are good questions.
The answer is usually not one extreme or the other. It is not “only include tested data” and it is not “describe every dream on the roadmap.” The better answer is to build a patent that clearly anchors itself in real invention work while also covering reasonable variations and next-step implementations.
That takes judgment.
It also takes drafting skill.
This is one reason founders like working with a system that blends smart software with real patent attorney oversight. You do not want to guess your way through an issue like this. PowerPatent helps founders move faster while still getting real expert review, which is exactly what matters when you are trying to protect something complex without making slow and costly mistakes. You can learn more here: https://powerpatent.com/how-it-works
Why examples matter in patent drafting
Before deciding what type of example to use, it helps to understand why examples exist at all.
Examples are not there just to make the application longer. They are not filler. They serve real functions.
First, they help explain the invention clearly. Clear explanation matters because a patent must teach the invention in a meaningful way. The patent should make it possible for the invention to be understood and practiced.
Second, examples help support claim breadth. If you want broad claims, you usually need broad and solid support in the specification. Examples can help show that the invention is not limited to one narrow setup.
Third, examples can make the invention feel concrete. This helps when dealing with examiners. It can also matter later if the patent is ever challenged.
Fourth, examples help expose the true inventive point. When you describe how the system actually works in context, the novel part often becomes clearer. That can lead to better claims.
Fifth, examples can help you tell the story of your invention across multiple versions. That is very useful for startups because the invention often evolves quickly.
So examples are not just decoration. They are structure. They are support. They are strategic.
Working examples feel strong because they are grounded
There is a reason many people instinctively trust working examples more.
They come from real effort. They reflect what the inventors actually built or performed. That gives them weight.
A working example can make the patent feel more stable because it shows that the inventors are not just hoping the invention works. They already know that at least one version works. That can make the disclosure more persuasive.
For software inventions, working examples can come from architecture that already exists in code. They can describe a data flow the team is using today. They can explain how the system handles inputs, makes decisions, stores outputs, or improves performance. They can reference real system states, real parameter choices, or real integration paths.
For AI inventions, working examples can describe a real training flow, a real inference pipeline, a real prompt-handling scheme, a real ranking process, or a real evaluation loop. They can explain what data classes were used, what features were extracted, what signals were weighted, and how the output affected downstream behavior.
For hardware or biotech, working examples can describe real assemblies, real materials, real experiments, or real operating conditions.
All of that detail helps.
And founders often have more working examples than they realize. You do not need a journal paper and ten months of testing. Even a real prototype flow can become a strong working example if it is described well.
Prophetic examples feel broad because they reach forward
Prophetic examples are useful for a different reason. They help you avoid freezing your patent at a single moment in time.
That matters because inventions do not stand still. The first release is rarely the last release. Your core idea may stay the same while implementation details change fast.
A prophetic example lets you describe additional ways the invention can be carried out without waiting until each one is fully built.
This can matter in several common startup situations.
Maybe your current system runs on one stack, but the same invention can run on another stack too.
Maybe your current model uses one type of signal, but you know the logic works with more signal types.
Maybe your current process is semi-manual, but full automation is coming.
Maybe your current deployment is on-device, but cloud execution is also possible.
Maybe your first product serves one user group, but the same core system can be applied in another field.
A prophetic example can help put those versions into the patent now.
That is valuable because patent timing matters. Waiting can be costly. Public launches, investor pitches, code sharing, demos, papers, and customer discussions can all create timing pressure. If you wait for every version to be fully done, you may lose priority or miss the chance to capture key variants.
So prophetic examples can be practical, not just theoretical.
They let you protect the road ahead.
Neither type is magic
It is important not to romanticize either one.
A working example is not automatically strong just because it happened in real life. If it is poorly explained, too narrow, or disconnected from the real inventive point, it may not help much.
A prophetic example is not automatically weak just because it is forward-looking. If it is clearly written, technically sound, and tied to the invention, it can add real value.
The real question is not which label sounds better.
The real question is whether the example helps support the invention you want to claim.
That is what matters.
When working examples are especially useful
There are times when working examples are especially powerful.
One common case is when your invention could sound abstract without them. A real implementation can make the idea much easier to understand. This is often true in software, AI, and systems patents. The invention may involve logic, models, workflows, and control steps that are hard to grasp from pure theory. A working example gives the reader something solid.
Another case is when the invention depends on specific behavior or interaction between parts. A working example can show that interaction clearly. It can show sequence, causation, conditions, and results.
Working examples are also useful when the invention solves a real technical problem in a specific way. If your patent is about improving speed, reducing compute waste, lowering false positives, improving memory use, or making a system more reliable, a working example can help explain the mechanism behind that improvement.
They are helpful when your team already has meaningful technical detail available. If you already know how your system is built and used, there is no reason to hide that. Often the best patent drafting starts with mining what already exists in the product and engineering flow.
Working examples can also be helpful when you want to show credibility to future readers. A patent examiner may not explicitly reward you for saying something was tested, but a detailed real-world example can still make the application more persuasive and easier to follow.
When prophetic examples are especially useful
Prophetic examples shine when you are filing before all variants are complete.
That is very common.
A founder may have one version running today, but the invention is larger than that first version. There may be multiple planned implementations that share the same inventive core.
A prophetic example helps capture those without waiting.
This is especially useful when your invention has a platform nature. In other words, the same core idea can apply across several use cases, data sources, workflows, or deployment types. You may not have built every branch of that platform yet, but you can still explain how they would work.
Prophetic examples are also useful when a narrow working example might otherwise make the application feel more limited than it should be. A startup does not want to accidentally describe its invention so narrowly that future versions fall outside the support.
They can also help when early filing is important for business reasons. Maybe you are about to launch. Maybe you are fundraising. Maybe customers are already seeing the tech. Maybe competitors are moving fast. In those moments, waiting for more completed experiments may be the wrong move. A prophetic example can help broaden the filing while staying honest.
This is one of the great balancing acts in startup patent strategy: file early enough to protect momentum, but draft well enough to protect more than just version one.
The danger of using only working examples
Working examples are great, but they can create a trap if used alone and too literally.
The trap is narrowness.
Founders often describe exactly what they built, step by step, because that feels safe. And it is safe in one sense. It is real. It is accurate. But it can also accidentally make the invention sound tied to one specific implementation.
That is risky.
Suppose your team built a system that ranks incoming support tickets using a mix of message content, user history, and recent product telemetry. If the patent only describes the exact ranking pipeline now in production, using your current model family, your current thresholds, and your current queue logic, then the application may not fully support broader claim language later.
But the real invention might not be that exact pipeline. The real invention might be the larger idea of dynamically ranking and routing issue resolution tasks based on combined behavioral and technical context. That broader idea could be implemented in many ways.
If your patent only sounds like one frozen version, you may regret it later.
This is why working examples should often be paired with broader description and, where appropriate, prophetic examples.
The danger of using only prophetic examples
Prophetic examples create the opposite trap.
The trap is overreach without grounding.
If the application is full of future-sounding implementations but light on concrete technical detail, the invention may feel vague. It may sound like a plan rather than a real teaching. That can weaken the patent.
This is especially dangerous when founders get too excited about breadth and start describing many possible variants without fully explaining how the core invention works. The result can be a long application with lots of scenarios but not enough real structure.
Another danger is tone. A prophetic example should not read like a made-up success story. If it implies that testing happened when it did not, that creates problems. Even if there is no bad intent, loose wording can create confusion.
There is also a practical issue. Founders can fall in love with roadmap ideas that are still very rough. Not every future version deserves space in the application. Some are too speculative. Some are disconnected from the true invention. Some are just ordinary next steps. Adding all of them can muddy the disclosure.
So while prophetic examples are useful, they work best when they are anchored to a clearly described invention and used with discipline.
The best answer is often both
In many strong patent applications, the best answer is not choosing one over the other. It is using both.
A working example shows what was actually done.
A prophetic example shows what else can reasonably be done using the same inventive concept.
Together, they create a fuller picture.
The working example grounds the application. The prophetic example expands it.
The working example gives credibility and clarity. The prophetic example gives reach.
The working example reflects the current build. The prophetic example protects the next move.
This combination is often ideal for startups because it matches how startups actually operate. You already have something real. You also know where it is going. The patent should reflect both.
But the two should be handled carefully. They should be clearly framed. They should support the same inventive core. They should not contradict each other. And they should be drafted in a way that keeps the broader patent strategy in view.
How to decide what to include
When deciding what examples to use, do not start by asking, “What type sounds stronger?”
Start by asking, “What am I really trying to protect?”
That question changes everything.
If your invention is already working in one meaningful form, then you likely want at least one working example that shows the invention in action.
If your invention clearly extends into other likely forms that share the same key idea, then you may want prophetic examples that cover those forms too.
If your current implementation is only a proof of concept and your broader product direction is already clear, then the patent may need both a specific example and a broader forward-looking frame.
If your team is still early and the exact implementation is changing every week, then you may need to focus on the stable inventive point rather than any one temporary build detail.
That is the real lens: what part of the invention is stable, novel, and worth protecting?
Once you know that, your examples become easier to shape.
Ask yourself what the inventive core really is
This is the single most useful exercise.
Forget the labels for a minute.
Ask: what is the core idea that makes this invention different?
Not the whole product. Not the company vision. Not the sales pitch. The actual technical idea.
Maybe it is a way of selecting data before training to reduce drift.
Maybe it is a way of coordinating edge and cloud inference to cut latency.
Maybe it is a method of generating structured prompts from user behavior context.
Maybe it is a control system that adapts based on sensor disagreement.
Maybe it is a workflow that uses model confidence and business rules together in a new way.
Once you identify that core, you can build examples around it.
The working example should show that core operating in a real setup.
The prophetic example should show how that same core can appear in other setups.
If an example does not help reveal or support the core, it may not belong.
This keeps the patent focused and strategic.
Do not confuse “real” with “narrow”
This mistake happens all the time.
A founder wants to be accurate, so they describe exactly what the engineers built. That part is good. But then they stop there. They assume accuracy requires extreme specificity.
It does not.
You can be accurate and still write in a way that captures variations.
For example, your real system may use a transformer model, a rules layer, and a scoring step. The application can describe that real implementation truthfully. But it can also explain that other model architectures, rule sources, weighting schemes, or scoring outputs may be used.
That is not being vague. That is being smart.
The goal is not to hide the real implementation. The goal is to describe it without accidentally trapping the patent inside it.
This is one reason patent drafting is not the same as writing technical documentation. Internal documentation can be narrow and exact because its job is to describe the current build. Patent drafting needs to describe the current build and support reasonable scope around it.
Do not confuse “future” with “unsupported”
There is a mirror-image mistake on the other side.
Some founders think that if a version has not been fully built, it should never appear in the application. That is too strict.
Patent applications can absolutely describe future implementations, as long as the disclosure provides real teaching and the example is not pretending to report finished results.
The key is support.
A prophetic example should not be random. It should flow naturally from the invention. A skilled person should be able to see how it would work based on what the application teaches.
If the future version is a reasonable extension of the disclosed invention, it may be very worth including.
This is especially true when you know competitors could implement the same core idea in slightly different ways. If your application only captures what your team happened to build first, you may leave room for others to work around it.
How wording changes the feel of an example
A lot depends on language.
Working examples usually use wording that reflects completed activity. The drafting may describe what was done, what components were used, how the system was configured, and what happened.
Prophetic examples usually use wording that reflects expected or illustrative activity. The drafting may describe how a system can be arranged, how a method may be performed, what inputs may be used, or what result is expected to occur.
That difference matters.
Not because one is more elegant, but because clarity matters. You do not want a reader wondering whether you actually tested something when you did not. You also do not want a real implementation watered down so much that it sounds hypothetical when it was not.
Good drafting keeps these lines clear.
This is not about being stiff. It is about being precise in a useful way.
A startup example: software workflow
Let’s make this practical.
Imagine your startup built a system that reviews incoming contract language and flags risky terms. The system does more than keyword search. It breaks clauses into structured parts, compares them against company policy, checks the transaction type, and then proposes edits based on both legal risk and business priority.
A working example might describe how your current system receives a draft agreement, parses clauses into categories, maps them to a policy database, scores each issue, and generates a revision queue for the human reviewer. It may describe your current prompt flow or model pipeline. It may explain how the policy store is used and how edits are ranked.
That is useful because it shows a real implementation.
A prophetic example might describe a future version where the same logic is used during live negotiation, where the system monitors redlines in real time, re-scores risk as edits happen, and suggests alternate compromise language based on user role and deal stage.
That version may not be launched yet. But if it is a natural extension of the same inventive concept, including it may help broaden protection.
Now suppose you only include the first version. Your patent may end up feeling tied to batch review of draft agreements. Suppose you only include the second version. Your patent may feel too speculative and detached from a concrete implementation.
Together, they tell a stronger story.
Another startup example: AI inference control
Imagine a startup with a system that routes user requests between different AI models based on cost, latency, confidence, and user context. The goal is to get good answers while controlling spend.
A working example could describe the current live system. It receives a user query, scores it based on complexity and urgency, picks a first model, evaluates confidence, and escalates to a second model only if needed. It may describe confidence thresholds, caching behavior, logging, and user-specific routing logic.
A prophetic example could describe an expanded version in which the system also considers downstream action risk, such as whether the answer will trigger payment, change infrastructure settings, or update records. In that future version, the routing engine may choose models not just based on answer difficulty, but also based on the impact of a wrong answer.
That future version may not be built yet, but it fits the same core invention: adaptive model routing using operational context.
Including both helps protect the real current build and the likely next step.
Another example: hardware or physical system
Suppose a startup builds a wearable sensor patch that detects motion patterns and adjusts sampling rate to save battery while preserving signal quality.
A working example could describe a real prototype using specific sensors, a control microprocessor, a thresholding method, and a power-saving state machine. It could explain how the patch increases sampling during suspected motion events and reduces it during steady periods.
A prophetic example could describe how the same adaptive sampling logic can be extended to a multi-sensor mesh across a worksite, where individual units coordinate their sampling behavior based on shared event detection. That may not be built yet, but it may be a clear next application of the same control idea.
Again, the pairing matters.
What examiners and later readers care about
Patent examiners care about the words on the page. They are looking at what is claimed, what is disclosed, and what prior art exists.
They are not grading you on whether you used the phrase “working example” or “prophetic example.” What matters is substance.
Does the application clearly teach the invention?
Does it support the claim language?
Does it describe the invention in enough detail?
Does it distinguish over prior art?
Does it avoid obvious holes?
Examples can help with all of that.
Later readers may care too. A future investor doing diligence may read the patent. A partner may read it. An acquirer may read it. A competitor may study it. A court may one day examine it. In all of those settings, clarity and credibility matter.
A patent that contains grounded examples and thoughtful breadth often feels stronger than one that is either bare and abstract or overly rigid and narrow.
How much detail is enough
Founders often struggle with this. They either dump every internal detail into the draft or keep it so high level that it says almost nothing.
The right answer is enough detail to teach the invention well and support the claim scope you want.
That means the example should show the key components, key steps, and key relationships.
It should explain what happens, in what order if order matters, and why that setup matters.
It should include variations where useful.
It should avoid clutter from details that do not serve the inventive point.
If your invention is about a routing method, the example should make the routing method clear. If your invention is about a model training process, the example should make the training flow clear. If your invention is about hardware interaction, the example should make that interaction clear.
Do not drown the invention in trivia.
But do not starve it of structure either.
What makes a working example actually useful
A useful working example does more than say, “We built a system.”
It walks the reader through the invention in action.
It identifies the components or modules involved.
It explains the flow of information or material.
It shows the decision points or transformations.
It highlights what makes the approach different.
It may describe optional variants without losing the real example.
It helps the reader understand not just that something exists, but how it works.
For startups, the best source material often lives inside engineering notes, architecture diagrams, code comments, benchmark docs, product specs, internal demos, and founder explanations. The hard part is turning that raw material into a patent-ready narrative.
That translation matters.
This is where founders save a lot of time by using a modern system built for technical teams. PowerPatent helps you turn what you already know into a strong patent draft without forcing you into the slow and painful process that traditional firms often create. And because real attorneys review the work, you do not have to choose between speed and quality. See how it works here: https://powerpatent.com/how-it-works
What makes a prophetic example actually useful
A useful prophetic example is not wild. It is not a giant wishlist. It is not marketing copy.
It is a clear, technically grounded illustration of how the invention can be practiced in a version that has not yet been completed.
That means it should still include structure.
It should explain the setup.
It should explain the steps.
It should connect to the disclosed invention.
It should feel plausible to a technical reader.
It should expand protection in a deliberate way.
A bad prophetic example sounds like fantasy. A good prophetic example sounds like a thoughtful next implementation of a known technical concept.
That difference is everything.
The role of data and results
This is another area where founders get tripped up.
Do you need results in a working example?
Not always.
Results can be helpful, especially if the invention is about improving a measurable technical outcome. But not every patent needs a table of performance metrics. What matters most is that the example teaches how the invention works.
If you do include results, be accurate. Make sure they reflect real testing if they are presented as such.
For prophetic examples, be careful with results. You generally do not want to present predicted results as if they were measured outcomes. You can describe expected behavior or intended effects, but the wording should reflect that the example is illustrative and forward-looking.
This is one of those areas where subtle drafting choices matter a lot.
What about prototypes that partly work
This is common in startups and it raises a fair question.
Suppose you have a prototype that works in some respects but is still rough. Is that a working example?
Often, yes.
The point is not perfection. The point is whether the described implementation is something you actually carried out.
You may have run it manually. You may have used internal data only. You may have limited it to one environment. You may have only tested one path. That can still support a working example if described honestly.
In fact, early-stage working examples are often some of the most valuable because they are closest to the invention moment. They capture what the team actually discovered.
Do not wait for polish if the invention is already real enough to teach.
What about inventions that are mostly conceptual so far
This can happen too, especially in frontier fields.
Maybe the founders understand the architecture and logic deeply, but the full system is not yet implemented. In that case, prophetic examples may play a bigger role.
But even then, the application should strive for concrete teaching.
Can you describe modules?
Can you describe process flow?
Can you describe control logic?
Can you describe data transformations?
Can you describe hardware arrangement?
Can you describe training or inference paths?
The more real structure you provide, the stronger the disclosure tends to be.
Even when using prophetic examples, the application should not feel hand-wavy.
Startups should think in versions, not snapshots
This is a powerful mindset shift.
Do not think of your invention as one frozen product screenshot. Think of it as a family of versions built around a stable inventive core.
Version one may be your current working implementation.
Version two may be a broader deployment.
Version three may use different inputs.
Version four may automate what is now assisted.
Version five may move into a new use case.
A strong patent often captures that family.
Working examples are great for the version you have.
Prophetic examples are great for the versions you reasonably foresee.
When you think in versions, you naturally write a better application.
How to avoid the biggest drafting mistakes
The biggest mistake is mixing truth states. Do not write a future implementation in a way that sounds like it already happened. And do not describe a real implementation so vaguely that readers cannot tell it was ever built.
Another major mistake is stuffing examples with too many unimportant details. You want enough detail to support the invention, but not so much that the inventive point gets buried.
A third mistake is failing to tie examples back to the core idea. If examples feel like disconnected product stories, they do less work.
A fourth mistake is copying product language instead of invention language. Product language often focuses on user benefit. Patent language should explain technical operation.
A fifth mistake is filing too narrowly because the founders only described exactly what was in code that week. That can shrink your future protection.
A sixth mistake is filing too broadly without enough technical teaching. That can leave the patent exposed.
Most of these mistakes come from one problem: lack of structured patent thinking early in the process.
How founders can gather the right material
You do not need to write the final patent draft yourself, but you do need to surface the right inputs.
Start with the real implementation.
What does the system do?
What are the main parts?
What triggers the process?
What inputs come in?
What decisions get made?
What outputs go out?
What makes this better than the old way?
Then think about reasonable variants.
What other inputs could be used?
What other environments could this run in?
What different modules could perform the same function?
What steps could be reordered, repeated, or skipped?
What future product versions still rely on the same technical idea?
What neighboring use cases are already obvious to your team?
These questions help uncover both working and prophetic examples.
A good patent process should make it easy for founders and engineers to answer these in plain language. That is one reason PowerPatent is built the way it is. It helps technical teams capture what matters without forcing them into drawn-out email loops or vague legal intake forms. You get a smarter workflow and real attorney oversight at the same time. Learn more here: https://powerpatent.com/how-it-works
Should you label examples as working or prophetic
In many cases, yes, at least in substance.
The important thing is that the nature of the example is clear. Readers should understand whether the described implementation was actually performed or is being presented as an illustrative future embodiment.
This can be done through wording and structure.
Clarity helps avoid confusion later.
Some applications explicitly identify experimental or implemented examples and separately present illustrative examples. Others make the distinction through tense and phrasing. The exact style can vary, but the line should be visible.
Hidden ambiguity is not your friend.
How this affects claim strategy
Examples are not the claims. But they support the claims.
If your claims are broader than your working examples, prophetic examples may help support that broader scope.
If your claims are focused on a core method but your only example is one product workflow, you may need additional examples or broader description to avoid tying the claims too closely to that workflow.
If your claims include optional modules, alternate data sources, or multiple execution paths, examples can help show those are truly part of the invention.
This is why drafting examples in isolation is risky. They should be shaped with claim strategy in mind.
A good patent is not just a data dump. It is a coordinated disclosure.
For software founders, abstraction level matters a lot
Software founders often live in two languages at once.
One is implementation language. It is the language of code, APIs, services, data structures, and deployment.
The other is product language. It is the language of user flows, dashboards, automation, and value.
Patent drafting needs a third language. It is more technical than product language but more strategic than raw code language.
Examples need to live at the right level.
Too low, and the invention gets trapped in implementation details that change every sprint.
Too high, and the disclosure sounds abstract and empty.
Working examples help because they anchor the real flow.
Prophetic examples help because they lift the scope beyond that exact codebase.
The art is finding the layer where the true invention lives.
For AI founders, do not let the model swallow the invention
This is a very common problem.
A founder has built something impressive involving models, prompts, retrieval, ranking, agent flows, or training. But when it comes time to explain the invention, the whole story collapses into “we use an LLM.”
That is not enough.
The invention may be in the orchestration, the control logic, the state handling, the data selection, the feedback loop, the prompt construction, the task routing, the validation, the failover, or the system architecture around the model.
Examples should help surface that.
A working example might show the actual chain of operations in production.
A prophetic example might show how the same control logic applies across model families or deployment modes.
That is much more valuable than centering everything on one model choice that may be outdated in six months.
For deep tech founders, timing pressure is real
Deep tech teams often face a hard problem. The work is real and technical, but full validation can take time. Hardware cycles are long. Wet lab cycles are long. Field testing takes time. Yet filing delays can be dangerous.
This is where the working-versus-prophetic question becomes very practical.
You may have some real implemented pieces and some not-yet-completed extensions. That does not mean you should wait forever. It means the application should be built carefully to include grounded working material and well-supported forward-looking material.
A thoughtful mix can let you file on time without giving up scope.
How investors may think about this
Investors are not usually parsing the doctrinal difference between example types. But they do care whether your IP feels real and useful.
A patent that reads like it was built around a concrete technical invention can create confidence.
A patent that seems too hand-wavy may not.
A patent that only covers a narrow prototype may also feel weaker than one that captures the broader platform opportunity.
That does not mean you draft for investors. You draft for patent strength. But the same qualities that often make a patent stronger also tend to make it feel more credible in diligence.
How competitors may exploit weak examples
Competitors look for gaps.
If your examples only describe one narrow implementation, a competitor may try a small variation and argue it falls outside the disclosed scope.
If your application is too prophetic and vague, a competitor may challenge whether your patent really supports what you claim.
If your examples confuse what was done and what was imagined, that ambiguity may be used against you.
Strong examples do not guarantee victory in every future dispute. But they can reduce obvious attack points.
That matters.
A practical framework founders can use
Here is a simple way to think through it.
First, identify one real implementation that best shows the invention.
Second, identify the inventive point inside that implementation.
Third, identify two to five reasonable variants that use the same inventive point in different ways.
Fourth, decide which of those variants are already implemented and which are still forward-looking.
Fifth, make sure the application clearly teaches both the current version and the meaningful variants.
That is the heart of the exercise.
Notice what this framework does. It stops you from thinking in labels first. It starts with the invention, then maps the examples around it.
That is usually the better path.
The human truth behind all this
Founders are often afraid of saying the wrong thing in a patent.
That fear makes sense. Patent language can feel high stakes. Many teams either delay too long or over-delegate without understanding what is being filed.
But the working-versus-prophetic issue becomes much less scary when you treat it as a question of honest technical storytelling.
What did you actually build?
What do you know this invention can also do?
How can you describe both clearly?
That is the job.
Not magic. Not theater. Not legal fog.
Clear technical storytelling.
Why old-school patent processes often fail here
Traditional patent processes often break on this issue because they are too slow, too abstract, or too disconnected from the product team.
A founder gets sent a blank disclosure form. They answer in broad strokes. Weeks later, they get a draft full of generic language. The draft either misses key details from the real implementation or narrows the invention around one awkward version. Future variants get ignored or described badly. Review takes forever. Momentum dies.
This is exactly the kind of problem modern tooling should solve.
Founders need a faster, clearer way to turn real invention work into strong patent drafts. They need a process that captures the working details while also identifying the broader embodiments worth protecting. And they need real attorney review so the filing is not just quick, but actually solid.
That is where PowerPatent stands out. It is built for founders and engineers who want strong protection without the usual delay and confusion. You can see how it works here: https://powerpatent.com/how-it-works
Working examples can help reveal hidden inventions
There is another benefit to grounding part of the draft in real implementation: it often exposes inventions you did not even realize you had.
This happens a lot in startups.
A founder thinks the invention is the top-level product concept. But when they walk through a working example, it becomes clear that the real novelty sits in a deeper subsystem. Maybe it is the way state is preserved across sessions. Maybe it is the fallback logic. Maybe it is the data labeling pipeline. Maybe it is the conflict-resolution process. Maybe it is a synchronization method.
Working examples force specificity, and specificity often reveals the true invention.
That can lead to better patents and sometimes more than one patentable idea.
Prophetic examples can help future-proof the filing
At the same time, prophetic examples help you avoid overfitting the application to today’s build.
That future-proofing matters because companies change quickly.
The product team may switch model vendors. The engineering team may re-architect services. The deployment environment may shift. The customer segment may expand. The workflow may become more automated. The sensors may change. The hardware packaging may improve.
If the patent only describes today’s narrow setup, it may age badly.
Thoughtful prophetic examples can help the application age better by capturing alternate ways the same invention can be used.
That does not mean predicting everything. It means covering the reasonable path outward from the core.
What to do when your invention spans many embodiments
Some inventions naturally have many forms. A platform technology may support several products. A control method may apply across devices. A data-processing engine may work in several industries.
When this happens, examples become even more important.
A single working example may still be useful, but you may need more than one example overall to show the range of the invention.
Some may be working. Some may be prophetic.
The key is coherence. All examples should point back to the same inventive principle or closely related principles. Otherwise the application can feel scattered.
Breadth is good. Drift is not.
Why simplicity in writing matters
A patent application can be legally serious and still be easy to understand.
That matters when you are preparing source material and reviewing drafts. It also matters when the final application is read by humans who need to understand the invention.
Examples should not be buried under unnecessary complexity.
Simple writing does not mean simplistic thinking. It means clear thinking.
This is especially important for founders reviewing a draft. If you cannot understand the example section without rereading it five times, something is wrong. You should be able to see your invention in the text.
How to review a patent draft for example quality
When you review a draft, ask yourself a few very plain questions.
Can I tell which examples reflect things we really built?
Can I tell which examples are forward-looking?
Does the draft explain the invention in a way that matches how the system actually works?
Does it cover the obvious next versions we care about?
Does it focus on the right inventive point?
Could a competitor make a small change and escape what is described?
Would this still make sense if our stack changes next year?
Would a new engineer on our team understand the technical idea from this disclosure?
These questions are powerful because they cut through jargon.
Working examples are not just for labs
Sometimes founders hear “working example” and think of lab notebooks, formal studies, or scientific experiments. But the concept is much broader.
A working example can come from software running in a test environment.
It can come from a hardware prototype assembled in-house.
It can come from a manually assisted method your team used before full automation.
It can come from a customer pilot.
It can come from a closed beta.
It can come from an internal tool that proved the concept.
Do not assume your invention lacks working examples just because it is early-stage or software-heavy.
Prophetic examples are not just for guesswork
Likewise, prophetic examples are not a license to dream without limits.
The best prophetic examples are rooted in engineering judgment.
They often come from roadmap plans, alternate architectures, known substitutions, adjacent use cases, or scaling paths the inventors already understand.
They are future-facing, yes. But they are not detached from reality.
That distinction is important.
How to think about “best mode” in a practical sense
Even if you are not focused on legal doctrine, there is a practical lesson here: do not hide the good version.
If you know the best way you are currently carrying out the invention, that real version is often worth describing clearly. Founders sometimes worry that describing too much helps competitors. But a patent is a trade. You get exclusivity in exchange for disclosure.
Trying to be too vague can backfire.
This is another reason working examples often matter. They help show the real implementation path that makes the invention work.
At the same time, you do not need to stop there. You can disclose the real version and still describe other versions.
Should early-stage startups wait for more data
Usually, not by default.
Waiting can make sense in some narrow situations, but many startups wait for the wrong reasons. They assume a patent should only be filed once everything is polished and proven. That is often too late.
If the invention is already clear and there is enough substance to describe it well, filing earlier is often smarter.
In that setting, the balance between working and prophetic examples becomes your friend. Use the real material you have now. Add reasonable future embodiments where they support the broader invention. File with purpose.
Delay is not a strategy.
The role of attorney oversight
This topic is exactly why real attorney review matters.
You want someone who can help judge whether a forward-looking example is well supported, whether a working example is too narrow, whether the wording properly reflects what was done, and whether the examples align with the claim plan.
Pure software alone may miss nuance. Pure law-firm process may be too slow and disconnected. The best setup combines smart tooling with real expert review.
That is the model PowerPatent is built around. It helps you move fast, capture the right technical substance, and avoid common drafting mistakes that can weaken your filing later. See how it works here: https://powerpatent.com/how-it-works
So, what should you use
Now we can answer the title question directly.
What should you use: working examples or prophetic examples?
Use working examples when you have real implementations that show the invention clearly. They are powerful because they ground the application in what has actually been done.
Use prophetic examples when you need to capture reasonable forward-looking versions of the same invention, especially when filing early and protecting future scope matters.
Use both when you have a real current implementation and a clear path to additional embodiments that share the same inventive core.
That last answer is the one most startups should remember.
In many cases, the smartest patent filing does not choose between grounded detail and strategic breadth. It combines them.
A deeper rule: protect the invention, not just the prototype
This is the bigger principle underneath the whole discussion.
Your patent should protect the invention you created, not just the exact shape of today’s prototype.
At the same time, it should be anchored enough in real technical substance to be credible and useful.
Working examples help with the anchor.
Prophetic examples help with the reach.
When you use them well, you are not just describing a product. You are protecting the deeper technical idea across the forms it can take.
That is what strong patent strategy looks like for startups.
This is one of the most important mindset shifts a business can make when thinking about patents.
A prototype is a moment in time. An invention is the real engine underneath it.
That difference matters more than most founders realize.
Your prototype is often shaped by deadlines, team size, budget limits, available tools, and what you could ship fast. It may reflect the fastest path to launch, not the full shape of the idea. It may use one model because that was easiest to deploy. It may rely on one workflow because that is what the team had time to build. It may serve one narrow customer use case because that was the quickest way to get traction.
But the invention is usually bigger than that.
The invention is the smart part that makes the system work in a new and useful way. It is the logic, structure, method, control flow, or technical approach that creates the real advantage. That is what the patent should be built around.
If a business only protects the prototype, it can end up with patent coverage that is too small for the company it is trying to become.
Your first version is often shaped by speed, not strategy
Most startups do not build version one in a perfect way. They build it in the fastest useful way.
That is normal. In fact, it is usually the right product decision.
But it is not always the right patent frame.
A lot of early products are full of temporary choices. A founder may use one vendor because integration was fast. A team may hard-code a step that later becomes dynamic. A model may be selected because it was available, not because it was essential. A data source may be used simply because it was easy to access first.
If those short-term choices end up defining the patent story, the business may protect the wrong thing.
The smart move is to separate what is essential from what is temporary.
Ask what part of the system has to stay for the invention to still be the same invention. Then ask what parts are likely to change as the company grows. That split is where stronger patent strategy begins.
The market will not care how your prototype happened to be built
Competitors are not going to copy your invention in the exact same way just to be polite.
If your idea is valuable, others may copy the heart of it while changing the surface. They may swap out the model, re-order steps, use a different interface, change the data source, move processing to another layer, or package the same logic in a different workflow.
That is why businesses need to think beyond the visible product shell.
A weak filing often protects the exact outer form of the first release. A stronger filing protects the technical idea in a way that still matters when others try to repackage it.
This is not about making the patent vague. It is about making it commercially intelligent.
The goal is to protect what competitors would actually try to copy once they understand where the value sits.
Think like a business owner, not just a builder
Founders often describe an invention from the inside out. That makes sense because they built it.
But a strong patent strategy often requires the opposite view. It helps to look at the invention from the outside in.
Ask yourself what a rival would try to reproduce if they wanted the same business result.
Would they need the same control logic?
Would they need the same routing method?
Would they need the same feedback loop?
Would they need the same way of combining data sources?
Would they need the same sequence for deciding, filtering, scoring, or adapting?
Those questions move you away from “what did we code first” and toward “what actually creates defensible value.”
That is the layer where the invention usually lives.
Protect the business leverage point
Every strong invention has a leverage point. This is the place where a small technical choice creates a large business effect.
It may reduce cost in a way others cannot easily match. It may increase speed, improve quality, lower risk, increase reliability, or unlock scale. Sometimes it creates a better user experience. Sometimes it makes an entire workflow possible where it was not before.
That leverage point is where business strategy and patent strategy meet.
A smart company does not just patent features. It patents the mechanism that gives the company leverage.
This is why the best patent discussions are not only about engineering. They are also about what drives margin, product stickiness, speed to market, customer trust, and long-term advantage.
When you identify the leverage point, you are much less likely to file around a disposable prototype detail.
Build a “must-keep” map before drafting
One highly useful exercise for businesses is to make a simple “must-keep” map.
Before drafting, write down what parts of the current product could change without harming the invention, and what parts must remain for the invention to still deliver its core value.
This is not a legal memo. It is a business strategy tool.
When teams do this well, they often discover that the true invention is smaller and sharper than the whole product, but also broader and more powerful than the current build.
For example, the dashboard may change. The API layer may change. The vendor may change. The output format may change. But the adaptive decision engine underneath it all may be the real thing worth protecting.
That insight can save a company from wasting patent space on details that will not matter in a year.
Draft for the next two product cycles
One of the best practical rules for startups is this: do not draft only for today. Draft for today plus the next two product cycles.
That does not mean guessing wildly. It means thinking ahead in a disciplined way.
What are you almost certain to improve soon?
What manual step will become automated?
What narrow use case will become broader?
What single-model flow will become a multi-model flow?
What fixed rules will become dynamic?
What product-specific workflow will become a platform capability?
These questions are valuable because they are close enough to be real, but forward-looking enough to matter.
A patent that only captures the current snapshot may feel outdated very quickly. A patent that captures the present system and the obvious near-term evolution is often much more useful to the business.
Do not let internal shortcuts define external protection
Early-stage teams use shortcuts all the time. That is part of building.
A founder may manually clean data behind the scenes. A team member may review outputs before release. A process may depend on scripts that were never meant to last. A hardware setup may use a bench arrangement that would never appear in the final product.
Those shortcuts are fine inside the company.
But they should not control how the business defines the invention.
This is where many startups undersell themselves. They mistake the path they used to prove the idea for the idea itself.
The patent should not simply mirror the rough path of development. It should capture the durable technical concept that remains valuable even after those shortcuts disappear.
Tie patent scope to revenue paths
Here is a very strategic way to think about it.
Look at how the company expects to make money over the next few years. Then ask whether the patent story lines up with those revenue paths.
If the business plans to move from services into software, the patent should not be locked into a services-only framing.
If the company plans to expand from one industry into three adjacent ones, the patent should not read like it only belongs in the first industry.
If the current product is a wedge into a broader platform, the filing should not protect only the wedge.
This is one of the most practical tests of whether you are protecting the invention or just the prototype.
The patent should grow with the business, not fall behind it.
Turn product features into invention principles
A very actionable exercise for teams is to take each important product feature and ask, “What principle sits underneath this?”
This helps strip away surface details.
A product feature might be “smart routing.” The invention principle may be context-aware task assignment based on confidence and downstream risk.
A product feature might be “auto-generated edits.” The invention principle may be structured transformation of text using constraint-aware scoring and revision selection.
A product feature might be “battery-saving sensor mode.” The invention principle may be adaptive sampling triggered by event probability and state transition logic.
Once you name the principle, you can protect the deeper technical idea more clearly.
That is usually far more valuable than describing the feature the way it appears on a product page.
Run a “copycat test”
This is one of the most helpful business tests you can use.
Imagine a well-funded competitor saw your demo today and wanted to copy the core value within six months.
What would they change first to avoid looking identical?
They might change the interface. They might swap infrastructure. They might rename steps. They might use another model or component. They might wrap the same logic in a different user flow.
Now ask a harder question: after all those changes, would they still be using your core invention?
If the answer is yes, your patent should aim at that core.
This test is powerful because it forces you to think about real-world competitive behavior, not just internal product structure.
Protect the method, not just the packaging
Businesses often focus too much on packaging because packaging is visible.
The interface is visible. The workflow screen is visible. The hardware shell is visible. The output is visible.
But what creates real defensibility is often the method behind the packaging.
How are decisions made?
How is data selected or transformed?
How is state maintained?
How are exceptions handled?
How is the system controlled as conditions change?
How are outputs prioritized, verified, or adapted?
These method-level questions often reveal what is hardest for others to reproduce without using the same core approach.
That is where smart protection tends to live.
Make room for scale before you need it
A prototype usually solves a problem at a small scale. The invention may solve it at a much larger one.
That difference should appear in the patent thinking.
For example, a prototype may work with one customer, one dataset, one deployment mode, one model type, or one hardware configuration. But the real business value may come from using the same idea across many customers, many streams, many systems, or many operating conditions.
If the patent is written only around the small-scale version, it may miss the scale story.
Businesses should ask early how the invention behaves under growth. Does the same logic apply across higher volume, more users, more devices, more locations, more workflows, or more complex data? If yes, that future scale should influence how the invention is described.
Your prototype may change, but your moat should not
This is the heart of the strategy.
The product will change. The stack will change. The design will change. The roadmap will change.
Your moat should become stronger, not weaker.
A patent should help protect that moat. That only happens when the filing is aimed at the enduring source of advantage, not the temporary shape of the first release.
That is why businesses need to look past launch details and focus on what truly makes the company hard to copy.
The patent is not just a record of what you built. It is a tool for protecting the company you are becoming.
Action steps businesses can take right now
A practical way to apply this is to gather the product lead, technical founder, and one person who understands the business model well. Then talk through three questions.
First, what is the one technical thing we do that creates the most business value?
Second, if we rebuilt this company from scratch next year, what part of the current implementation would definitely survive?
Third, what changes are likely in the product, but should not reduce the value of our patent position?
The answers to those questions often reveal whether your current patent narrative is aimed at the real invention or just the current build.
That discussion can be more valuable than a long generic intake form because it connects patents to the actual future of the business.
The strongest filings protect where the company is headed
In the end, businesses win when they protect what matters across time.
A prototype is proof that something works.
An invention is the repeatable technical advantage that can power many versions of the business.
That is why the deeper rule matters so much. Do not stop at protecting the first thing that shipped. Protect the method, structure, and technical logic that make the business hard to replace.
When companies do this well, patents become more than paperwork. They become part of company strategy.
And that is when IP starts to do real work.
If you are unsure, here is the safest mindset
Be honest about what is real.
Be clear about what is illustrative.
Be specific about the inventive core.
Be broad about reasonable variations.
Be practical about timing.
That mindset will take you a long way.
Final thoughts
Founders do not need more patent confusion. They need a clear way to make smart decisions fast.
The choice between working examples and prophetic examples is not really about picking a winner. It is about knowing the role each one plays.
Working examples show the invention in real life. They give your filing substance, clarity, and grounding.
Prophetic examples show where the invention can go. They help preserve broader protection and reflect the reality that startups are always building the next version.
When used together, they can make your patent stronger, more flexible, and more aligned with how innovation actually happens.
So do not ask only, “What have we built?”
Also ask, “What is the core invention, and what other forms of it do we already understand well enough to teach?”
That is the better question.
And it leads to better patents.
If you are building something important and want to protect it without slowing your team down, PowerPatent is built for exactly that. It combines smart software with real patent attorney oversight, so you can move faster and file with more confidence. Explore it here: https://powerpatent.com/how-it-works
The strongest patents usually do two things at once. They tell the truth about what exists today, and they protect the versions that matter tomorrow.
That is how founders stay fast and stay protected.
Leave a Reply