The OSINT Vault · Internal Document

Master Brief v2

Revised September 12, 2026 — not deployed, document only

You are working on The OSINT Vault at https://theosintvault.io.

Read this entire instruction before changing anything.

PROJECT FACTS

The OSINT Vault is an independent OSINT product suite created by Nicole Hurey.

Nicole designed and built all seven original tools:

  1. Omertà
  2. The OSINT Grid
  3. Multi-Search Launcher
  4. Google Dork Generator
  5. OSINT Bookmarklet Library
  6. OSINT Vault Note Organizer
  7. Intelligence Report Composer

The website also contains guides, assessments, blog posts, curated external resources, and a broader tools directory. Those resources support the product suite. They are not the primary product.

The seven original tools must never look like third-party links collected into a directory.

CURRENT STATE (shipped and verified, September 2026)

The following work is complete. Do not redo it. Do not revert it. Build on top of it.

  1. Canonical URL structure. Every page has one clean extensionless canonical URL. All .html variants 301 redirect. Old aliases (/vault-grid, /osint-quiz) 301 to their current pages.
  2. Unknown routes return a real 404 page. The homepage is never served for a missing route.
  3. Sitemap regenerated from canonical routes.
  4. Every page carries a self-referencing canonical tag.
  5. Bookmarklet Library security overhaul. All bookmarklets render extracted content through DOM methods and textContent. No document.write. Output windows open with noopener. localStorage access is wrapped in try/catch. Hostile-content handling is verified.
  6. OSINT Grid data loading uses an absolute data path. It resolves from every route.
  7. Homepage hero: shield crest, wordmark, tagline, attribution line, creed line, capability ticker, and three equal-weight entry points (The Library, Omertà, The OSINT Grid).
  8. All seven original tools carry the VAULT badge in their homepage sections.
  9. Training content (Beginner Kit, OSINT Quiz) sits in its own Training Ground section, separate from tool sections.
  10. “Last Updated” stamps read September 11, 2026 across all pages.

OPEN DECISIONS (resolve before assigning work)

  1. Amplitude analytics is currently loaded in omerta.html. Nicole must decide: keep, replace with a self-hosted option, or remove. Do not assume.
  2. The capability ticker shows live numbers (698 platforms, 4,594 records). These are currently hardcoded from real data. Decide whether to generate them from source data at build time or leave manual with a review date.

PRIMARY OBJECTIVE

Improve the website until it feels like a mature investigative product suite created by one expert builder.

The finished site must communicate five facts immediately:

  1. Nicole Hurey built the seven original tools.
  2. The tools support a connected investigation workflow.
  3. Omertà and the OSINT Grid are the two flagship systems.
  4. The tools prioritize local browser processing and investigator control.
  5. The site helps investigators move from a lead to a documented result.

Do not turn the site into a generic startup landing page.

Do not imitate a venture-backed SaaS website.

Do not replace the current visual identity.

Do not add a reduced search experience to the homepage.

Do not show partial Omertà or Grid results outside the full tools.

LOCKED DECISIONS (Nicole has already ruled on these)

  1. The homepage presents three equal entry points. Omertà is one of three, not the sole hero action. Do not restore a single-tool hero.
  2. Ambient brand animation is approved on the homepage hero: the blueprint grid drift, the radar sweep, and the periodic copper sheen on the wordmark. These stay. The “no decorative animation” rule below applies everywhere else.
  3. The floating contact bar stays.
  4. Copy reads “Built by an investigator. Used by investigators.” Do not replace with social-platform name-dropping.

CORE WORKING RULES

  1. Inspect the complete repository before editing.
  2. Identify the current framework, routing system, data files, shared components, styles, scripts, and deployment assumptions.
  3. Use the existing architecture unless there is a documented technical reason to change it.
  4. Do not rewrite working tools for aesthetic reasons.
  5. Do not remove working features.
  6. Do not change investigation logic without documenting the exact reason.
  7. Do not introduce new dependencies when the current stack can perform the job.
  8. Do not introduce accounts, new analytics, tracking, or server storage. (Existing Amplitude is covered by Open Decision 1.)
  9. Do not transmit investigation data to external services.
  10. Do not insert mock data, placeholder statistics, fake testimonials, fake clients, or fabricated performance claims.
  11. Do not claim that something was tested unless it was actually tested.
  12. Do not describe a client-side loading state as a failure before testing the rendered application.
  13. Preserve backward compatibility for saved data and exports where practical.
  14. Record every changed route, data format, and export format.
  15. Complete one coherent implementation. Do not leave abandoned alternatives in the codebase.
  16. Verify against the rendered page in a real browser before reporting done. A clean console is not proof. A text extractor is not proof.

WRITING RULES

All public copy must sound human, direct, technically informed, and specific.

Do not use em dashes.

Do not use en dashes as substitutes for em dashes.

Use periods, commas, colons, semicolons, and parentheses.

Do not use generic AI marketing language.

Avoid these words and phrases unless the surrounding facts require them:

Do not use formulaic marketing patterns.

Avoid:

Use concrete language.

Bad:

“Unlock powerful intelligence with a seamless investigation experience.”

Good:

“Search public sources, record what you checked, and export the findings.”

Bad:

“Omertà delivers unparalleled identity intelligence across hundreds of platforms.”

Good:

“Omertà checks public sources for usernames, emails, names, phone numbers, domains, and IP addresses.”

Bad:

“Take your investigations to the next level.”

Good:

“Open the source, review the match, and record the evidence.”

Do not call a result verified unless the interface explains what was verified.

Do not call a failed lookup a proven negative.

Do not imply that public availability automatically makes collection or use lawful.

Do not use “anonymous” when the feature only suppresses a referrer.

Do not use “no data leaves your machine” unless network behavior confirms that statement for the specific action.

VOICE

Write as a working investigator explaining a tool to another investigator.

Use:

The copy may have personality, but it must not perform expertise. It must show expertise through details.

VISUAL IDENTITY

Preserve:

Improve the existing system. Do not replace it with gradients on body text, glass effects, generic cards, glowing purple elements, stock illustrations, or bright SaaS colors.

Animation is permitted for:

Respect reduced-motion preferences everywhere, including the ambient set.

Do not add decorative animation outside the approved set without Nicole’s sign-off.

Make every interactive element usable with a keyboard.

Provide visible focus states.

Check text contrast against WCAG AA.

Increase the readability of small gray uppercase labels. Short operational labels may remain uppercase. Multi-line explanatory text should use normal capitalization when all caps makes it harder to read. Minimum readable size for operational micro-labels is 12px at adequate contrast.

HOMEPAGE REQUIREMENTS

Do not restore the former hero search.

The homepage must route visitors to a full tool. It must not imitate a tool with reduced results.

Preserve the current hero composition (see Current State item 7 and Locked Decision 1).

Immediately after the hero, the suite introduction reads:

SEVEN TOOLS. ONE INVESTIGATION WORKFLOW.

Present the tools in this order:

  1. Discover with Omertà
  2. Verify with the OSINT Grid
  3. Expand with Multi-Search
  4. Refine with the Dork Generator
  5. Capture with the Bookmarklet Library
  6. Organize with the Note Organizer
  7. Report with the Report Composer

Each item must state:

Label every original tool with a compact original-tool badge (the existing VAULT badge).

Use this supporting attribution once, in the suite introduction:

Designed and built by Nicole Hurey

Do not use an exact source count in permanent marketing copy unless the value is generated from the current Grid data (see Open Decision 2).

SITE ORGANIZATION

Separate original products from supporting content.

Primary navigation:

INVESTIGATE

DOCUMENT

LEARN

RESOURCES

ABOUT

Keep Omertà and the Grid prominent.

Treat guides, external resources, and blog posts as supporting material.

TOOL PAGE LAYOUT

The global header on tool pages must be more compact than the homepage header.

The first usable control should appear within the initial desktop viewport on common laptop displays.

Each tool page should contain:

  1. Compact Vault navigation
  2. Tool name
  3. One-sentence function
  4. Clear privacy or network behavior
  5. Primary input or control
  6. Current state
  7. Results or output
  8. Methodology
  9. Limitations
  10. Related workflow step
  11. Update information
  12. Problem-reporting link

Do not repeat the same long marketing introduction above and below the tool.

Keep instructional copy close to the control it explains.

OMERTÀ REQUIREMENTS

Preserve the full Omertà application.

Do not create a partial Omertà search on the homepage.

If a future homepage input is added, it may only collect an identifier and transfer the user into the complete Omertà interface. It must not return reduced results.

Support a full-query handoff through a safe method such as URL parameters or local browser state. (URL parameter handoff already exists: /omerta?q=identifier prefills and starts the scan.)

Do not automatically expose sensitive queries in URLs without considering browser history, logs, referrers, and screen sharing. Document the tradeoff where the feature is described.

Review Omertà’s result language.

Use distinct states:

A matching username must not be described as identity proof.

Replace “proven negatives” with:

UNCONFIRMED AND UNSUCCESSFUL CHECKS

Use this explanation:

These results help define the search boundary, but they do not prove that an account or record does not exist. A check may be inconclusive because of privacy settings, platform changes, access restrictions, rate limits, or unavailable public data.

For each result, show when available:

Create a methodology page explaining:

Review Bulk mode separately.

Add a concise lawful-use acknowledgment for bulk searches.

Do not introduce excessive legal interruptions for ordinary individual searches.

OSINT GRID REQUIREMENTS

The Grid is functional. Do not treat its initial non-JavaScript fallback as the final application state.

Preserve the current visual identity and status card.

Use the current Grid data as the source of truth for:

Do not maintain the same count manually in multiple files.

Add or preserve source fields for:

Add shareable filters where practical.

Example:

/osint-grid?state=FL&type=property&access=free

Add:

Do not claim that every external source is operational because the Grid application is operational.

Separate:

MULTI-SEARCH REQUIREMENTS

Preserve:

Replace “Stealth Mode” with “Suppress Referrer” unless the implementation does more than referrer suppression.

Use this explanation:

Suppresses this page as the referring URL when the destination supports it. This does not hide your IP address, browser fingerprint, or activity from the destination platform.

Before launching, show:

After launching, show:

Safe Mode should be the default unless the current user has deliberately changed it.

Allow the session manifest to be exported or transferred to the Note Organizer and Report Composer.

GOOGLE DORK GENERATOR REQUIREMENTS

Preserve the current builder, presets, operator stacking, history, session export, and batch functions.

Audit each operator against current search-engine behavior.

Assign one status:

Show the last test date.

Do not present every operator as equally reliable.

Validate:

Preview every batch query before opening tabs.

Place responsible-use guidance beside sensitive presets such as:

Do not add warnings that overwhelm ordinary lawful use.

BOOKMARKLET LIBRARY REQUIREMENTS

Security hardening is already shipped (see Current State item 5). Maintain it.

Treat pages being investigated as hostile input.

Do not insert extracted page values into HTML strings.

Do not use document.write with unescaped extracted values.

Render extracted output through DOM methods and textContent.

Isolate output windows from the inspected page where possible.

Handle:

NEXT STEP for this tool (not yet done): consolidate every bookmarklet definition into one structured source (a single JS data module). Use that source for:

Today the same code exists in multiple places per card. The consolidation removes that class of bug permanently.

Define the risk rubric.

Document whether each bookmarklet:

Automate a syntax test for every bookmarklet.

Run security tests with hostile page content.

NOTE ORGANIZER REQUIREMENTS

Preserve local processing and current export features.

Every extracted item should retain provenance when technically possible:

Separate:

Explain what deterministic processing means.

Do not imply that a classification is correct because the parser produced it.

Label extracted information as requiring investigator review.

Document support for:

Do not list a file type as supported unless it is tested.

When sending content to Report Composer, preserve structured fields and provenance. Do not flatten the case into plain text unless the user chooses that option.

REPORT COMPOSER REQUIREMENTS

Preserve existing PDF, DOCX, Markdown, and print workflows.

Test each export format.

Structure findings into:

Support evidence fields:

Support report fields:

Do not force every field into simple reports.

Use progressive disclosure so basic reports remain fast to create.

Test exports with:

SKILLS QUIZ AND CLI TEST REQUIREMENTS

Every question must include after submission:

Review questions for multiple technically valid answers.

For shell and command-line questions, distinguish between:

Use “certificate of completion” unless the assessment meets a documented certification standard.

Create a larger question bank and select questions by category.

Do not expose all answers in predictable client-side markup if the certificate is intended to carry meaningful value.

CONTENT AND SEO REQUIREMENTS

Canonical routes, redirects, real 404, canonical tags, and sitemap are shipped (see Current State items 1 through 4). Maintain them as pages change.

Audit on each release:

Prevent hidden error messages, empty search states, and raw code fragments from becoming primary indexed text.

Organize guide content by intent:

Do not create several pages that repeat the same copy under different titles.

For every external tool listing, support:

Do not compete on the number of listed tools alone.

Compete on accuracy, context, maintenance, and investigative use.

TRUST AND POLICY PAGES

Create or improve:

Keep the language readable.

Do not write legal policy as marketing copy.

Do not make unsupported claims about legal compliance.

For every original tool, provide a plain-language data statement:

PERFORMANCE REQUIREMENTS

Measure before optimizing.

Check:

Do not remove functionality solely to improve a score.

For large datasets:

ACCESSIBILITY REQUIREMENTS

Test:

Do not rely on color alone for source or result status.

TESTING REQUIREMENTS

Create a repeatable test plan.

At minimum, test:

Capture screenshots at common desktop and mobile dimensions.

Do not mark a test passed based only on the absence of a console error.

DELIVERABLES

Work executes in two briefs, not one.

BRIEF A (run first): correctness, security, and claims. P0 and P1 items only:

BRIEF B (run after A): product evolution. P2 and P3 items:

Complete the work in this order.

PHASE 1: INVENTORY

Produce:

Do not edit production code during this phase.

PHASE 2: PLAN

Produce a prioritized plan with:

Use these priorities:

PHASE 3: IMPLEMENTATION

Implement approved work in small, coherent groups.

Hard cap: no more than 5 item groups per implementation cycle. Estimate everything else and report the estimate. Do not start a group you cannot finish and test in the same cycle.

After each group:

PHASE 4: FINAL QA

Produce:

PHASE 5: HANDOFF

Produce a final summary containing: