Skip to content

Interactive UI

LizardPope1101 edited this page Aug 6, 2026 · 1 revision

Interactive UI

The complete interactive interface is a firm OSINT Forge v1.0 release requirement.

If you can read, you can run OSINT Forge.

Delivery rule

The interface will be delivered as one cohesive v1.0 implementation. Internal dependency-ordered checkpoints are allowed for engineering and QA, but there will be no public v0.9.1–v0.9.9 ladder of partial UI releases and no claim of completion until the entire acceptance contract passes.

Entry points

osint                    → guided interactive interface
osint case ...           → advanced case CLI
osint run ...            → advanced direct-run CLI
osint batch ...          → advanced batch CLI and automation
osint forge ...          → advanced lifecycle CLI

The advanced CLI remains a first-class interface for experienced operators, scripting, automation, and AQAD. The guided interface is additive and must never remove, hide, or break explicit commands.

Both front ends call the same application services and investigation engine. The UI must not become a separate case or execution implementation.

Complete operator journey

The guided interface must support:

  1. Create or open a case.
  2. Seed it with known information.
  3. Review and edit the starting information.
  4. Start the investigation.
  5. Run the recursive discovery engine.
  6. Monitor progress and resolve ambiguous matches.
  7. Review findings and their evidence.
  8. Generate the final report.
  9. Pause, save, resume, stop, recover, or exit at appropriate points.

Case creation and seeding

The interface asks one understandable question at a time and validates immediately. It supports every registered target type, including names, email addresses, usernames, phone numbers, addresses, domains, IP addresses, images, and files.

Users can add, review, edit, remove, deduplicate, and bulk-import starting information without editing JSON, YAML, or text files. Purpose and authorization scope are visible and editable.

Investigation control

Before execution, the interface explains the plan in plain language and presents conservative bounded defaults. It must expose truthful engine state for:

  • Recursive queue progress
  • Depth, request, time, and other safety budgets
  • Approvals and stopping rules
  • Pause, resume, cooperative cancellation, and stop
  • Interrupted-run recovery
  • Plugin availability, compatibility, and failure handling

The UI must not label a saved preference as a real pause, or a configured budget as enforced, until the engine contract actually provides that behavior.

Ambiguity and findings

Potential identity matches stay quarantined until reviewed. The operator can accept, reject, or defer each candidate with visible evidence and understandable consequences.

Findings views distinguish source evidence, confidence, verification status, contradiction, temporal status, and unresolved ambiguity. Confidence never substitutes for evidence, and tool absence is not represented as failed verification.

Reporting

Users can browse findings and generate the supported final report formats from the interface. Shareable/redacted output retains the existing safety contract and still requires human review before distribution.

Navigation and accessibility

Every appropriate screen provides clear Back, Save, and Exit behavior. The interface safely handles invalid input, EOF, interruption, recovery, narrow terminals, keyboard-only operation, no-color environments, and plain-text output.

A first-time user must be able to complete the canonical workflow without reading external documentation or knowing OSINT terminology in advance.

Extensibility

Menus are driven by feature, target, and plugin registries rather than hard-coded per-plugin pathways. Ordinary additions should require registration metadata, a validator, plain-language labels/prompts, capability declarations, and tests—not surgery across unrelated menu files.

Fundamentally new engine workflows may require new screens, but they must plug into the same navigation, state, and application-service framework.

v1.0 acceptance gate

v1.0 is not complete until:

  • The full canonical operator journey works through the guided interface
  • Recursive controls and ambiguity workflows are backed by real engine contracts
  • Every menu path has deterministic automated coverage
  • Existing advanced CLI behavior and automation remain compatible
  • Clean-Debian installation and real plugin/network boundary tests pass
  • Long-running pause, resume, cancellation, recovery, rate-limit, and network-failure behavior are validated
  • A no-documentation first-run human trial succeeds

Governing references

Clone this wiki locally