DEV Community: Axon OSINT

Our React App Worked Perfectly—Until Someone Closed Their Laptop

Axon OSINT — Mon, 26 Oct 2026 21:07:45 +0000

What sleep/wake bugs taught us about Supabase, network recovery, and building reliable SaaS applications.

Imagine spending weeks building a React application.

Authentication works. Database queries work. Real-time updates work. Your dashboard loads quickly, and your end-to-end tests are passing.

You deploy it.

Everything looks great.

Then someone closes their laptop.

They return an hour later, open the lid, and continue working.

The application is still there. They're still logged in. The buttons are visible.

But something is wrong.

A request never finishes. A loading indicator keeps spinning. A piece of information disappears from the screen.

Refreshing the page fixes everything.

Sound familiar?

This became one of the most interesting reliability challenges we encountered while building Axon OSINT, a SaaS platform for digital investigations.

And the lesson was bigger than any particular library:

A web application that works after a fresh page load is not necessarily an application that survives real life.

1. The Bug That Didn't Look Like a Bug

One of the frustrating things about sleep/wake failures is that the application often doesn't crash.

There's no dramatic error screen.

No obvious exception.

No broken deployment.

Instead, the failure can be subtle.

A dashboard displays information from an earlier session. A request stays pending. An action appears to be running, but nothing happens.

During our work on Axon OSINT, we encountered variations of these problems across multiple areas, including investigation workspaces, account settings, and billing workflows.

The recurring pattern was particularly interesting.

A fresh reload could restore normal behavior.

But the application was supposed to keep working without asking users to refresh their browsers every time they returned to their desks.

That raised a question:

What exactly changes when a laptop sleeps, if the React application itself is still mounted?

2. Your JavaScript State Can Survive Longer Than Your Network State

When a browser tab goes into the background or a computer sleeps, several things can change.

JavaScript timers may be delayed.

Network connections may be interrupted.

Authentication credentials may approach expiration.

Real-time connections may disconnect.

An asynchronous operation that was started earlier may not complete when expected.

Meanwhile, React component state can remain in memory.

So after the user returns, the interface may still look exactly as it did before.

This creates a dangerous mismatch:

The UI remembers a healthy application, while the network may no longer be healthy.

Consider a basic loading pattern:

async function loadData() {
  setLoading(true);

  const { data, error } = await supabase
    .from("items")
    .select("*");

  if (error) {
    throw error;
  }

  setItems(data);
  setLoading(false);
}

This code has an immediate problem: if the operation throws, setLoading(false) is never reached.

We can improve that:

async function loadData() {
  setLoading(true);

  try {
    const { data, error } = await supabase
      .from("items")
      .select("*");

    if (error) throw error;

    setItems(data);
  } catch (error) {
    showError(error);
  } finally {
    setLoading(false);
  }
}

Better.

But there's still a problem.

What if the promise never settles within a reasonable amount of time?

The finally block won't execute until the awaited operation settles.

A loading indicator can remain visible indefinitely if nothing imposes a deadline.

This became one of our most important rules:

Every critical network action needs a predictable way to finish.

3. We Stopped Treating the SDK as the Only Transport

Axon OSINT uses React, TypeScript, Supabase, and Zustand.

Supabase provides a convenient SDK for database operations, authentication, and other backend functionality.

Under normal conditions, the SDK is exactly what we want.

But our post-wake engineering standard addresses a specific failure mode: after sleep or tab suspension, some SDK-dependent operations may stall even while the application still appears usable.

Our response was not to abandon Supabase.

Instead, we separated two concerns:

What operation does the application need to perform?
Which transport can safely perform it right now?

For critical operations, our architecture can use the SDK with a bounded timeout and an alternative direct HTTP route when appropriate.

Supabase exposes REST and RPC endpoints, so not every operation has to depend on the same client-side execution path.

A simplified read strategy looks like this:

User requests data
        |
        v
Is the SDK marked degraded?
        |
   +----+----+
   |         |
  Yes        No
   |         |
   v         v
Direct    Try SDK with
HTTP      a timeout
             |
        +----+----+
        |         |
      Success    Failure
        |         |
        v         v
      Return    Direct HTTP
      data      fallback

The distinction matters.

If we already know that the SDK has become unreliable in the current browser session, repeating the same problematic path can waste time.

Instead, eligible reads can use the alternative route immediately.

This is a resilience pattern, not a universal recommendation to bypass every SDK whenever something goes wrong.

The fallback still needs correct authentication, authorization, error handling, and data validation.

4. A Timeout Is a Deadline, Not a Recovery Strategy

A timeout is useful because it prevents the UI from waiting forever.

But a timeout alone doesn't solve the underlying problem.

Here's a simplified helper:

function withTimeout<T>(
  operation: PromiseLike<T>,
  timeoutMs: number
): Promise<T> {
  return Promise.race([
    Promise.resolve(operation),
    new Promise<never>((_, reject) => {
      setTimeout(() => {
        reject(new Error("Operation timed out"));
      }, timeoutMs);
    }),
  ]);
}

This illustration puts a deadline on waiting.

However, it doesn't actually cancel the underlying network request.

That's an important difference.

Promise.race() can stop your code from awaiting an operation, while the original request may still be running.

For cancellable direct HTTP requests, AbortController is a better tool for enforcing network deadlines.

For example:

async function fetchWithDeadline(
  url: string,
  init: RequestInit,
  timeoutMs = 8000
) {
  const controller = new AbortController();

  const timeout = setTimeout(() => {
    controller.abort();
  }, timeoutMs);

  try {
    const response = await fetch(url, {
      ...init,
      signal: controller.signal,
    });

    if (!response.ok) {
      throw new Error(`HTTP ${response.status}`);
    }

    return response;
  } finally {
    clearTimeout(timeout);
  }
}

The important design decision isn't whether to use 8, 10, or 15 seconds.

It's that the operation has an explicit boundary.

After that boundary, the application must make a decision.

Retry safely?

Use a different transport?

Display an error?

Preserve previously loaded data?

It cannot simply remain stuck.

One crucial caveat: a timed-out write may have succeeded on the server.

Blindly retrying a payment, record creation, or other non-idempotent action can introduce duplicate operations.

Writes need stronger safeguards, such as idempotency keys, reconciliation, or a status check before retrying.

5. We Introduced a Session-Level Degraded Mode

One useful decision in our architecture was to remember when a critical SDK operation had timed out.

Rather than repeatedly trying the same failing path, we introduced a session-level degraded state.

The concept is straightforward:

type SdkHealth = {
  degraded: boolean;
  reason?: string;
};

When a critical operation encounters a qualifying failure, the application can mark the SDK as degraded for the current browser session.

Then subsequent eligible actions can avoid unnecessary waits.

This isn't about declaring the entire backend offline.

The backend might be completely healthy.

The problem may exist in a particular browser-side request path.

It's an important distinction:

An unhealthy client connection does not necessarily mean an unhealthy server.

Our architecture deliberately keeps this degraded state until a hard page reload, rather than repeatedly switching back and forth using an automatic timer.

Why?

Because oscillating between healthy and degraded modes can create another category of problems.

One request works. Another hangs. The system retries. Then the user clicks again.

Suddenly one intermittent failure has become a cascade of activity.

Stability sometimes means choosing a conservative path and sticking to it for the session.

6. Authentication Recovery Must Not Depend on the Broken Path

There is another subtle failure mode.

Imagine you've detected an SDK problem and decided to use direct HTTP.

Before the fallback request, you try to retrieve the access token using another asynchronous SDK call.

What happens if that call depends on the same degraded client behavior?

Your fallback can hang too.

This is why our internal post-wake standard calls for using the application's already-maintained authentication state when appropriate.

In Axon OSINT, Zustand stores session information used by critical recovery flows.

The general principle is:

SDK request becomes unreliable
           |
           v
Use a verified, existing session token
           |
           v
Make the authorized fallback request
           |
           v
Handle success, expiration, or failure

This does not mean ignoring authentication expiration or inventing a token.

A cached token must still be valid for the request, and the server must enforce authorization on every path.

If no valid token is available, the application should follow a controlled authentication recovery flow.

A fallback is not a security bypass.

Resilience and authorization must work together.

7. Recovering Every Component at Once Can Make Things Worse

At first, it might seem that the solution to wake-related bugs is simple:

Whenever the browser tab becomes visible, refetch everything.

Unfortunately, this can introduce an entirely new problem.

Imagine your application has:

An investigations list.
A graph workspace.
A notification panel.
Account settings.
A billing summary.
Several background queries.

If every component independently reacts to a focus or visibilitychange event, returning to the tab can trigger many simultaneous requests.

Some may overlap.

Others may compete for state updates.

A few might fail while the others recover.

We've had to consider this problem in Axon OSINT as well.

Our recovery architecture tracks wake cycles and avoids treating every focus event as a completely new recovery operation.

It also distinguishes between ordinary tab focus and a situation that actually requires recovery.

The key lesson:

Recover the application, not every component independently.

One coordinated recovery process is easier to reason about than a dozen unrelated event listeners.

8. The UI Must Be Honest About What It Knows

Here's a particularly dangerous response to network failure:

try {
  return await loadSubscription();
} catch {
  return null;
}

At first glance, it looks harmless.

But what does null mean?

Does the user have no subscription?

Or did the network fail?

Those are completely different states.

If the application treats a transport failure as an absence of business data, it may hide information that still exists on the server.

The same issue applies to returning an empty array when a request fails.

An empty list might mean there are no investigations.

Or it might mean the application couldn't load them.

A reliable interface should distinguish these cases.

For example:

type LoadResult<T> =
  | { status: "success"; data: T }
  | { status: "stale"; data: T }
  | { status: "error"; message: string };

Now the application can display previously confirmed information without pretending that a failed network request returned an empty result.

But cached information must be clearly understood as potentially outdated.

And sensitive actions should still require fresh, authorized server confirmation.

This distinction became especially important for workflows involving account status, permissions, and billing.

A network error is not a business decision.

9. We Learned That Background Writes Need Their Own Rules

Our investigation workspace includes graph-based interactions.

Users may move entities around, organize relationships, and update layouts.

Some of these operations generate background writes.

Imagine moving dozens of nodes, then returning from sleep while the application attempts to persist every position at once.

A naive implementation might look like:

await Promise.all(
  nodes.map((node) => savePosition(node))
);

For a large graph, this can create a burst of network requests.

If the network is degraded, the application may produce multiple timeouts and errors, even though saving node positions is not the user's most important task.

Our engineering guidelines therefore distinguish between critical actions and non-critical persistence.

For position updates and similar background operations, we favor concepts such as:

Queuing.
Deduplication.
Debouncing.
Bounded concurrency.
Summarized failures.

The user should be able to continue interacting with the graph without a non-critical persistence problem freezing the entire interface.

But the application must also avoid pretending that unsaved changes were successfully persisted.

The right trade-off depends on the operation.

A graph position and a financial transaction should never share the same retry policy.

10. The Tests That Matter Happen After the Happy Path

A typical frontend test might do this:

Open the page
Click a button
Verify the result
Done

That's useful.

But it doesn't cover the conditions that exposed our reliability problems.

Our sleep/wake test scenarios also consider situations such as:

Open the application
Authenticate
Open an investigation
Put the laptop to sleep
Wake it
Try to create an entity
Switch between graph and table
Verify the UI reaches a terminal state

Other scenarios cover network interruption, security settings, account sessions, and post-wake actions.

The desired result isn't always that every request succeeds.

Sometimes the network genuinely isn't available.

What matters is that the application behaves predictably.

No infinite loading.

No blank screen.

No uncontrolled request storm.

No misleading empty data.

No duplicate writes caused by unsafe retries.

And no action that leaves the user wondering whether it happened.

That final point matters more than it might sound.

For users, uncertainty about whether an action succeeded can be worse than a clear error message.

11. Our Reliability Checklist Changed

After working through these issues, we began asking different questions during development.

Not just:

"Does this action work?"

But:

Does it work after the browser has been suspended?

What happens if the SDK request stalls?

Can the user recover without refreshing the entire page?

Will a timeout leave an action stuck in loading state?

Could retrying this operation create duplicate data?

Does an empty response mean no records exist, or that something failed?

Will multiple components initiate recovery simultaneously?

Does the fallback preserve the same authorization boundaries?

These questions are now part of how we approach critical workflows.

And there is an important qualification: architecture standards don't automatically eliminate every regression.

New features can still introduce bugs if they don't follow the same rules.

Reliability is a property that has to be maintained, not a checkbox that can be completed once.

The Most Important Lesson

When we started building Axon OSINT, our attention was naturally focused on features.

Investigations. Entities. Relationships. Collaboration. Billing. AI-assisted workflows.

All of those are important.

But real users don't always interact with applications under ideal conditions.

They close their laptops.

They switch between tabs.

Their internet connection drops.

Their session changes while the application is in the background.

They return to something they started earlier and expect to continue.

That is normal behavior.

And a well-designed SaaS application must treat it as normal.

The real test of a web application isn't only whether it works when everything goes right. It's whether it remains understandable, secure, and recoverable when something goes wrong.

That's one of the biggest engineering lessons we've learned while building Axon OSINT.

And we're still learning.

Let's Discuss

Have you experienced bugs that only appear after laptop sleep, browser suspension, or network reconnection?

How do you handle stalled requests, background recovery, and duplicate-action prevention in your React applications?

I'd love to hear what has worked for you.

We're building Axon OSINT, a platform for digital investigations, OSINT research, and collaborative evidence analysis.

This article is part of our **Building Axon OSINT* engineering series. The code snippets are simplified educational illustrations, not verbatim production code.*

We Built an AI Screenshot-to-Report System. The Hard Part Was Knowing When Not to Trust the AI.

Axon OSINT — Fri, 23 Oct 2026 17:37:29 +0000

How we're building a fraud-reporting experience with React, TypeScript, Supabase, and Gemini — and why human review matters more than a perfect-looking AI demo.

Imagine receiving this message:

"Your package couldn't be delivered. Pay €2.95 to arrange another delivery."

There's a link underneath it.

You don't recognize the sender. The website looks legitimate, but something feels wrong.

Now imagine opening a fraud-reporting website and seeing a form asking you to identify the incident category, communication channel, suspicious domain, financial impact, relevant evidence, and contact details.

For a developer, these fields probably make sense.

For someone who is worried about losing money, they might not.

That difference became an important part of what we're building at Axon OSINT.

We wanted people to report suspicious activity without first having to understand the vocabulary of fraud investigations.

And we started with something almost everyone knows how to create:

A screenshot.

But we discovered that converting a screenshot into structured information is only one part of the problem.

The more important question is what happens when the AI makes a mistake.

1. The Problem Isn't Just Extracting Text

Let's start with a simple example.

A screenshot of a suspicious message may contain several different kinds of information:

The original message.
A phone number or username.
A website address.
A payment amount.
The name of a company someone is impersonating.
A date or timestamp.

Those details are not interchangeable.

Consider the difference between these two statements:

Observed fact:

"The screenshot contains a link to parcel-check.example."

Interpretation:

"The link belongs to a fraudulent delivery service."

The first statement describes something visible in the image.

The second makes a judgment about what it means.

That distinction is critical.

An AI system might correctly extract a URL while being wrong about the intentions of the sender. It might also misunderstand part of a message, confuse two numbers, or suggest the wrong incident category.

In an ordinary productivity application, a slightly incorrect summary can be inconvenient.

In a fraud report, an incorrect phone number or website address can make the information significantly less useful.

So we designed the screenshot feature around a simple principle:

AI should help organize what the user provides, not decide what happened on the user's behalf.

2. Our Architecture: A Draft Before a Report

Our frontend uses React and TypeScript. Supabase handles parts of the backend, and Gemini is used for optional screenshot analysis.

The simplified flow looks like this:

User chooses screenshot upload
              |
              v
     File and age checks
              |
              v
   Screenshot analysis request
              |
              v
          Gemini
    Structured extraction
              |
              v
     Normalize the result
              |
              v
    Editable incident draft
              |
              v
     User reviews details
              |
              v
   Consent and submission
              |
              v
    Report confirmation
              |
              v
 Restricted report processing

One of the most important decisions in this flow is that the AI result does not automatically become a submitted incident.

It becomes a draft.

The user can review the extracted information, correct errors, add missing details, and decide whether to submit the report.

This keeps two very different operations separate:

Assistance: helping someone prepare information.

Submission: recording information that the person has reviewed and chosen to provide.

That separation also makes the system easier to reason about from a security and privacy perspective.

3. A Screenshot Isn't Trusted Input

The first boundary is surprisingly ordinary: file validation.

Our screenshot analysis endpoint accepts JPEG, PNG, and WebP images, with a 5 MB limit.

We validate the file type and size before sending it for analysis.

Why does this matter?

Because an upload feature is not just an image picker. It is a boundary between data supplied by an unknown user and a service that consumes external resources.

We also have to remember that everything inside the screenshot is untrusted.

A suspicious message might contain a URL, a payment instruction, or text claiming to come from a trusted organization.

We don't want the analysis process to treat those instructions as commands.

For example, if the screenshot says:

"Visit this website immediately to verify your identity."

The AI's job is to extract that message, not follow its instructions.

Our extraction prompt explicitly tells the model to work only with visible information, not invent missing values, and not open or check links.

This is an important architectural boundary.

Analyzing a suspicious link is not the same as visiting it.

For a reporting workflow, those should be separate capabilities with separate controls.

4. Structured Output Is Useful. It Isn't Proof of Accuracy.

Instead of asking Gemini to return an essay, we request structured information.

The response can include:

Field	Purpose
`message_text`	Original message from the screenshot
`platform_used`	Where the message appeared
`suggested_scenario`	Possible incident category
`entities`	URLs, phone numbers, accounts, and other identifiers
`description`	Suggested explanation
`confidence`	Confidence category
`warnings`	Information the user should verify

This structure makes it possible to map the extracted result into fields in the React form.

It also makes handling missing or uncertain information more predictable.

But a JSON response is not automatically a correct response.

A model can return perfectly valid JSON containing incorrect information.

That's why we distinguish between structural validity and factual accuracy.

A valid schema tells us the result is in the expected format. It doesn't tell us that the model understood the screenshot correctly.

What happens when confidence is low?

Our analysis layer supports three confidence categories:

high
medium
low

When the result has low confidence, the system falls back to a generic incident category rather than presenting a specific classification as reliable.

It also asks the user to verify the extracted details.

Here's a simplified TypeScript example illustrating the principle. It is not a copy of our production implementation.

type Confidence = "high" | "medium" | "low";

type Extraction = {
  confidence: Confidence;
  message_text: string | null;
  suggested_scenario: string;
  entities: Array<{
    type: string;
    value: string;
  }>;
};

function createEditableDraft(result: Extraction) {
  return {
    message: result.message_text,

    scenario:
      result.confidence === "low"
        ? "other_fraud_message"
        : result.suggested_scenario,

    identifiers: result.entities.map(({ type, value }) => ({
      type,
      value,
    })),

    requiresUserReview: true,
  };
}

Notice the last field.

requiresUserReview: true

It doesn't become false when confidence is high.

That's intentional.

A confidence label is useful information, but it should not remove the user's ability to inspect and correct the result.

5. Never Rewrite the Evidence to Make It Look Cleaner

One of the most interesting challenges in this kind of application is the difference between translating an explanation and changing the original evidence.

Suppose a suspicious message contains:

Send 250 EUR to this account.
Contact @payment_support_247.

The user might be completing the report in German, French, Ukrainian, or English.

We want the interface and generated explanations to use the selected language.

But the original message and identifiers must retain their original meaning and characters.

Imagine an automatic translation changing a username, modifying a website address, or replacing a financial identifier.

Even a tiny modification could undermine a later comparison.

Our extraction instructions therefore distinguish between:

Human-readable explanation: may be generated in the user's selected language.

Original message and identifiers: should be preserved as they appear.

The same principle applies to URLs, domains, phone numbers, and usernames.

Sometimes, what appears to be a typo is the most important detail in the entire report.

For example:

trusted-service.example
trusted-servlce.example

These strings look similar, but they are not identical.

Automatically "correcting" one into the other would destroy information that might matter.

This led us to a broader design principle:

Normalize data for comparison without silently rewriting the original observation.

That distinction is useful far beyond fraud reporting — especially in logging, compliance, investigations, and document-processing systems.

6. We Added a Path That Doesn't Require AI

It's tempting to make AI the center of every modern application.

We deliberately avoided making it mandatory.

Our reporting interface provides three entry points:

Manual entry. The user describes the incident and enters the information themselves.

Screenshot assistance. The user uploads an image, and the system prepares an editable draft.

Voice assistance. The user records or uploads audio, and the system helps turn their explanation into a draft.

These are different ways to reach the same goal.

Not everyone is comfortable uploading screenshots. Some users prefer typing. Others find it easier to explain what happened verbally.

And some people simply don't want their material processed by an external AI provider.

For that reason, the interface explains that optional screenshot and voice tools send the selected material to Google Gemini for draft extraction before the final report is submitted.

Users who want to avoid that AI processing can choose manual entry.

There is also an important distinction between screenshots and voice recordings.

A submitted screenshot can be retained as report evidence in restricted storage. The voice recording, by contrast, is used to prepare the draft and is not stored as an evidence recording in this workflow.

These differences matter.

A privacy notice shouldn't be a decorative element that appears after the important decisions have already been made.

People need to understand what happens to their information at the point where they choose to provide it.

7. The Unexpected UX Problem: The Screenshot Is on the Wrong Device

Another practical problem has very little to do with machine learning.

Imagine someone reading a fraud-reporting form on a laptop.

The suspicious message is on their phone.

How should they upload it?

A developer might download the screenshot from cloud storage, email it to themselves, or use a nearby-device sharing feature.

But requiring those extra steps creates friction.

So we built a QR-based upload flow.

The computer displays a QR code. The user scans it with their phone and uploads the screenshot from there.

The desktop then receives the analysis result and continues the report.

The user doesn't need to manually transfer the image to their computer first.

There are several interesting engineering considerations behind this relatively simple interaction.

Temporary sessions

The upload flow uses a time-limited session rather than a permanently reusable upload address.

The interface shows the remaining time and handles expiration.

Asynchronous state

The desktop doesn't assume the upload happens immediately.

The client tracks states such as:

creating
qr_ready
waiting_for_upload
analyzing
analyzed
expired
failed

These states let us communicate what is happening without leaving the user guessing.

Failure recovery

The user can retry or choose another reporting method if the session expires or the analysis fails.

This is a small feature, but it taught us an important lesson:

Reducing friction in a real user's workflow can be just as valuable as improving the AI model itself.

The best model doesn't help if the user can't conveniently provide the input.

8. Privacy Isn't a Checkbox at the End

Fraud reports may contain sensitive personal information.

They can include messages, payment details, contact information, and descriptions of potentially harmful events.

That creates responsibilities beyond ordinary form validation.

In Axon OSINT, submitted incident information is not intended to become a public social feed or a searchable collection of personal reports.

The reporting workflow uses restricted storage and backend access controls. Access to sensitive information depends on authorization and applicable access rules, not simply on whether someone has created an account.

This separation becomes especially important when information from different reports is compared.

Imagine three reports mentioning the same suspicious domain.

That repetition may be useful.

But it doesn't mean everyone searching for the domain should be able to read those three reports.

We separate the idea of a matching warning signal from access to the underlying statements and evidence.

Our public checking feature can return limited information about matches in previously reported data without opening those personal statements to the person performing the search.

And even when several reports contain the same number or website, that does not automatically prove a crime or identify the person responsible.

A repeated identifier is a signal worth examining, not a verdict.

For applications handling sensitive user submissions, this separation between source records and limited public results is an important design pattern.

9. The Submission Boundary Is Deliberately Separate

Another detail we care about is confirmation.

The system supports people submitting reports without first creating a full user account.

An email confirmation flow helps establish that a report was submitted using the stated address.

The backend also validates required acknowledgements, consent information, and report details during submission.

This matters because the application should not treat an AI-generated draft, a user-submitted report, and a confirmed report as identical.

They represent different levels of user action and confirmation.

The distinction is also relevant to downstream analysis.

For example, the documented cross-incident pattern-processing path requires the appropriate consent and confirmed report status.

This doesn't eliminate the need for careful access control or data validation.

But it reduces the risk of treating every unverified input as equally authoritative.

Good data processing starts with knowing where the data came from and what has actually been confirmed.

10. What We'd Tell Developers Building Something Similar

Several principles from this work apply to other applications using AI to turn unstructured content into structured records.

Keep extraction separate from action

A model can suggest information without being allowed to submit, publish, or act on it.

This is particularly important when errors could affect another person.

Preserve the original input

A clean summary is convenient. The original words and identifiers may be essential.

Don't make it impossible to recover what the user actually provided.

Treat confidence as a warning, not a guarantee

Confidence should influence how the result is presented, not replace verification.

A high-confidence mistake is still a mistake.

Design for failure before celebrating success

What happens if the upload fails? The AI returns incomplete information? The QR session expires?

A graceful manual fallback is part of the feature, not an afterthought.

Explain third-party processing before it happens

If user-provided content will be sent to an AI provider, make that clear before the user chooses the feature.

Privacy should be understandable, not merely technically documented.

Separate useful signals from sensitive records

Some information can help identify repeated patterns without exposing the people who provided it.

Design those boundaries explicitly.

11. The Questions We're Still Working On

Building this kind of system doesn't mean all the difficult questions are solved.

We continue to think about issues such as:

How can we better communicate uncertainty without overwhelming nontechnical users?
How should an interface highlight fields that deserve additional review?
How can we make screenshot-assisted reporting easier for people with limited digital experience?
How should systems prevent repeated but misleading reports from creating excessive confidence in a suspicious indicator?
How can cross-incident analysis remain useful while respecting privacy and authorization boundaries?

These are product questions, security questions, and engineering questions at the same time.

And they deserve more attention than simply choosing a new model.

The Most Important Part of Our AI Feature Is Still the Human

We started with a seemingly straightforward idea:

Take a screenshot. Extract the relevant information. Help the user complete a report.

But the deeper we got into the workflow, the clearer the priorities became.

It wasn't enough to make AI capable of reading a suspicious message.

We also needed to make the result understandable, editable, and appropriately restricted.

The system needed a way to express uncertainty.

It needed a fallback when automatic processing failed.

And it needed a clear boundary between an AI suggestion and an action taken by the user.

We are building this as part of Axon OSINT, a platform focused on digital investigations, open-source intelligence, and responsible fraud reporting.

For developers, the most useful takeaway is one that applies well beyond our project:

Don't measure an AI-assisted workflow only by how impressive its output looks. Measure it by how safely and clearly it behaves when the output is wrong.

That's where an interesting demo begins to become a dependable product.

Discussion: If you're building an application that turns screenshots, documents, or audio into structured data, how do you handle uncertainty and human review? Which mistakes are unacceptable in your domain?

Project context: Axon OSINT · Public fraud-reporting workflow