Owlvex

Owlvex is a VS Code-first production readiness review tool for AI-built apps and developer-led code review.

Its First Launch Readiness workflow helps developers decide what must be fixed before first real users see an AI-built app. Owlvex builds static repository understanding first, uses repository-visible evidence as the grounding layer, and uses your configured AI only for scoped review or explanation where that grounded evidence needs interpretation.

Security scanning, selected-code review, reports, and review-first fix previews remain part of the developer workflow, but Owlvex output is advisory evidence for human review, not certification or a final security sign-off.

Advisory Scope

Owlvex First Launch Readiness is an advisory production readiness review based on repository-visible evidence for AI-built apps preparing for first real users. It is not a certification, penetration test, compliance audit, or guarantee that an application is secure or production-ready. It is designed to help builders understand launch risk, prioritize fixes, and decide what needs deeper review.

0.8 Production Package

Owlvex 0.8 packages the production developer workflow: First Launch Readiness reports; static repository facts and repository graph grounding; current-file, selected-file, changed-file, open-editor, and workspace scans; scanner-backed conversation; selected-code explanation and repair previews; source/sink navigation; built-in HTML reports; Design Box and Spec File grounding; and post-fix verification.

Voice is not part of the 0.8 production workflow. Microphone work is intentionally deferred so the text-based companion, scanner, reports, and fix-preview loop can be validated first.

Owlvex output is evidence for developer review. Validate important findings, fixes, and reports before relying on them.

What's New In 0.8.11

Owlvex 0.8.11 improves First Launch Readiness evidence workflow reliability and report transparency.

• FLR grounded AI review now continues across evidence batches where possible instead of letting one failed batch hide the rest of the review.
• Malformed grounded-AI JSON responses get a scoped repair retry, and retry attempts are recorded in the report evidence.
• Generated FLR reports now show the actual grounded-AI review state: reviewed target count, unresolved targets, advisory report-QA state, provider boundary, and credit eligibility.
• Partial FLR outputs are more honest: they list which grounded-review targets still need attention instead of only showing a generic failure message.
• Static or partial reports never consume a paid FLR credit; full credit fulfilment still requires completed grounded AI evidence review through the configured provider boundary.
• Workspace scanning remains separated from deeper AI review: default workspace scans use static scanner evidence, repository graph context, and Code Map Lens snapshots.

Known limitation: provider output or total-budget exhaustion can still leave a grounded-AI FLR review partial. Owlvex now exposes those unresolved targets in the report; targeted failed-check retry is planned as follow-up work.

What's New In 0.8.10

Owlvex 0.8.10 is a First Launch Readiness hotfix for grounded AI review and paid report fulfilment safety.

• Required FLR grounded AI document review now has a 120-second request budget instead of leaving the VS Code progress notification waiting indefinitely.
• Provider model discovery has a short fallback path, so model listing cannot block report generation before the selected model is used.
• If the final static report declares that grounded AI review is required, Owlvex now attempts that review and rebuilds the report before paid FLR fulfilment.
• Paid FLR credits remain protected: a credit is only consumed when the required grounded AI review completes and the report is eligible for full FLR fulfilment.
• If the review fails or times out, Owlvex still produces the local repository-visible evidence report and clearly marks it as static/local evidence rather than a paid completed FLR.

What's New In 0.8.9

Owlvex 0.8.9 is an evidence reliability release for Code Map Lens, workspace scans, and developer security reports.

• Workspace scans now separate the default static/graph path from deeper AI review. The default workspace mode uses deterministic scanner evidence, repository graph context, and Code Map Lens artifacts without pretending broad AI review ran.
• Scan-time evidence is preserved more clearly through snapshots and decision ledgers, so reports can show what Owlvex actually reviewed at the time of the scan.
• Developer security reports now call out benchmark misses and issue mismatches instead of only showing raw JSON summaries.
• Benchmark comparison is stricter: a finding in the right file is no longer enough; the finding type must match the expected issue.
• Code Map Lens finding artifacts now prefer concrete evidence anchors such as source, sink, flow, and missing guard nodes.
• Static detection now covers request-derived JavaScript eval(...) paths as Dynamic Code Evaluation, with line-level evidence and a missing-control explanation.

These updates improve report honesty and traceability. They do not make a clean scan a security guarantee; clean or hidden files remain limited to the scanned scope and evidence available to Owlvex.

Current Version

0.8.11

Legal Documents

These documents are bundled with the extension package and should be reviewed before evaluation, sponsored, trial, or production use:

• Evaluation License Agreement
• Privacy Policy
• Terms of Use

What To Expect

Use it with these expectations:

• First Launch Readiness is the main release-decision workflow
• static repository facts and repository graph evidence are the grounding layer
• deterministic findings are the strongest scanner evidence class
• validate important findings before relying on them
• expect scan quality and speed to vary by provider/model
• treat AI-backed results as scoped review or explanation, not absolute proof
• review fix previews before accepting them
• use built-in HTML reports for sharing readiness and scan evidence

What Owlvex Does

Owlvex combines:

• First Launch Readiness reports for full repositories
• static repository facts and repository graph grounding
• local deterministic checks
• sink and guard discovery
• safe probe verification for selected issues
• scoped repo-context AI review when useful
• optional Spec File grounding
• optional design/context grounding
• summary and full evidence reports
• report comparison
• previewed code fixes
• post-fix verification loops

Supported provider paths include:

• Azure AI Foundry
• OpenAI
• Anthropic
• Gemini
• Groq
• Mistral
• Ollama
• custom OpenAI-compatible endpoints

Try It In 60 Seconds

The fastest event path is:

1. Install Owlvex.
2. Open the Owlvex activity view.
3. Choose View Plans, activate Owlvex Pro, or enter an existing licence key.
4. Select your project root.
5. Configure an LLM provider.
6. Run a small scan: current file, selected files, or changed files.
7. For a launch decision, purchase or use a First Launch Report credit and generate the First Launch Readiness report.
8. Open one finding or readiness gap, review the evidence, and preview a fix where applicable.

For daily development, prefer changed-file or selected-file scans. Use First Launch Readiness reports for first-user launch decisions and full-repository readiness review.

Product Contract

The public product contract is documented in the public repository:

• capability matrix
• detector maturity model
• benchmark evidence summary
• privacy and data-flow boundary
• known limitations
• example summary report and Risk Lens

Installation

Install From VSIX

1. Open VS Code.
2. Open the Extensions view.
3. Open the Extensions ... menu.
4. Choose Install from VSIX....
5. Select the Owlvex VSIX.

Open Owlvex

Use the Owlvex activity bar icon, or run:

• Owlvex: Open Security Companion

Setup

1. Licence Or Access

Owlvex supports:

• View Plans
• Activate Owlvex Pro Licence
• Redeem Sponsored Code
• Enter Licence Key

Current self-serve plans:

Plan	Price	Intended use
Owlvex Pro	GBP 49/month	Developer workflow for scans, findings, AI review, and fix previews with your configured AI provider.
First Launch Report	GBP 299/report	Production readiness review for one AI-built app repository, including one same-repository reassessment.
Owlvex Pro + FLR Bundle	GBP 348 first month	Owlvex Pro plus one First Launch Report credit for an AI-built app production readiness review.

Owlvex Pro keeps non-essential product telemetry optional. First Launch Report generation requires active Owlvex Pro access plus an available report credit.

Team and Enterprise are deferred and are not available as self-serve plans yet.

Checkout starts on the Owlvex website:

• https://www.cooperbox.co.uk/owlvex#plans

Payment-provider setup is not required for an existing licence key. Paid access is unlocked only when the Owlvex backend receives a verified payment event and issues or updates a valid licence or report credit; a checkout redirect alone is not access proof.

Owlvex Pro subscriptions can be managed from the extension. Open View Plans or the account controls, choose Manage Subscription, and Owlvex opens the secure hosted billing portal in your browser. Use that portal to cancel before the next renewal. Owlvex updates licence access only after the backend receives a verified subscription event.

Sponsored or event access codes are not licence keys. Use Redeem Sponsored Code, enter the code you received, complete email verification, and Owlvex will issue and store the resulting Owlvex Pro licence key.

2. Project Root

Set the project root so Owlvex knows the active app boundary.

This controls:

• workspace scans
• repo context
• changed-file scans
• report output
• Design Box resolution
• Repository intelligence and companion context

Command:

• Owlvex: Select Project Root

3. LLM Provider

Command:

• Owlvex: Setup AI Connection

For Azure AI Foundry you need:

• endpoint
• deployment name
• API key

For other providers, enter the provider-specific model and key details when prompted.

4. Test Setup

Command:

• Owlvex: Test Trial Setup

This checks:

• backend connectivity
• licence/access state
• LLM/provider connectivity

Scan Scopes

Owlvex supports several scan scopes:

• current file
• selected files
• changed files
• open editors
• workspace

Use changed-file scanning when you want fast review of work in progress. Owlvex uses Git when available. If Git is unavailable, use selected files or current file.

Commands:

• Owlvex: Scan Current File
• Owlvex: Scan Selected Files
• Owlvex: Scan Changed Files
• Owlvex: Scan Open Editors
• Owlvex: Scan Workspace

Reports

Owlvex can create:

• Summary Report
• Full Evidence Report

The summary report is for daily developer use. It focuses on what to fix first, confidence posture, proof posture, and remaining work.

The full evidence report includes deeper scoring detail, framework mappings, AI review detail, sink/probe evidence, provider status, and audit context.

When creating a report, Owlvex also asks for a report lens. The lens changes the report view over the latest scan evidence; it does not rescan code.

Available report lenses:

• Developer Security: OWASP + CWE remediation view
• Threat Model: STRIDE and trust-boundary view
• Compliance: NIST / PCI DSS / HIPAA control-alignment view
• Adversary: MITRE ATT&CK and CAPEC attacker-behavior view
• Full Evidence: all findings, mappings, and evidence from the scan

This follows the Owlvex rule: scan once, classify once, then generate reports by purpose.

Command:

• Owlvex: Create Report

Fix Preview Workflow

Owlvex does not directly overwrite code when a fix is generated.

The intended flow is:

1. Scan code.
2. Open a finding.
3. Choose Preview fix.
4. Review the side-by-side diff.
5. Choose Accept fix or Deny fix.
6. Owlvex verifies the changed files.
7. If findings remain, Owlvex creates a continuation queue.

The fix loop should continue until:

• findings are verified clean
• the user cancels
• a finding is explicitly left for manual review

Owlvex should reject broad or unanchored patches when a fix rewrites too much of a file for the selected finding.

Spec File

Spec File lets you point Owlvex at a local Markdown or text file that describes expected product behavior.

Use it for:

• test-driven design notes
• product behavior that must not change
• API or protocol contracts
• acceptance criteria
• important implementation boundaries

Spec File is local grounding context for scan and fix reasoning. It is not a security framework and it does not run scripts.

Supported file types:

• Markdown
• text

Setting:

• owlvex.projectContextFile
• owlvex.tddBoxEnabled

Command:

• Owlvex: Open Spec File

Design Box

Design Box lets you point Owlvex at a local design/context file so scans can understand intended system behavior.

Supported file types:

• Markdown
• text
• DOCX
• PDF, best-effort text extraction

Good Design Box inputs include:

• architecture documents
• threat models
• product workflows
• security assumptions
• trust-boundary notes
• API design notes
• data-flow documentation

Owlvex uses this as reference context during scans, especially when reviewing architecture, STRIDE, trust boundaries, roles, and data flows.

Design Box content is treated as project reference material, not as instructions to the model. The design file is read locally and included in scan context only when configured.

Setting:

• owlvex.designContextFile

Command:

• Owlvex: Open Design Context

Retired Validation Scripts

Validation Scripts / Drift Box are retired from the active Owlvex product workflow.

Expected behavior:

• no command-palette entry for Validation Scripts
• no contributed driftBoxFile, driftScriptsRoot, or driftBoxEnabled settings
• no scan-profile Validation Scripts toggle
• normal scans do not run local validation scripts
• behavior, contract, smoke, and workflow checks run through the project's own test runner outside Owlvex

Scan Profile

Scan Profile selection controls security lenses and optional local project context. It is not a hard security-rule firewall.

Security lenses are grouped by purpose:

• Developer Security: OWASP + CWE
• Threat Model: STRIDE
• Compliance: NIST / PCI DSS / HIPAA
• Adversary: MITRE ATT&CK
• Quality: Clean Code

Selected security lenses guide:

• AI grounding
• report emphasis
• remediation wording
• expanded mapping detail

Deterministic local evidence still runs security-first when code proves a vulnerability pattern.

A finding may still show canonical references such as CWE, OWASP, MITRE, NIST, PCI DSS, STRIDE, or Clean Code even if that framework was not selected. Those references are taxonomy mappings for the finding, not proof that every framework lens was active.

Plan boundary: Free does not include framework/taxonomy mapping output. Trial and Developer include mapping where available.

Reading Confidence

Owlvex separates risk from evidence confidence.

• Confirmed by rule means deterministic code evidence proved the issue.
• Validated by AI review means an AI finder result was supported by verifier or skeptic review.
• Finder-only AI review means the finder reported the issue, but verifier/skeptic were not triggered or unavailable.
• Finder high confidence, not independently verified means the raw AI score is high, but still finder-only.
• AI signal High (96% final) is model confidence, not deterministic proof.
• review path finder, finder+verifier, or finder+verifier+skeptic shows which AI passes ran.

For important changes, validate AI-backed findings against the code.

Safe Probe Verification

Safe probes are narrow, side-effect-blocked checks used for selected sink-driven findings.

They can help answer:

• can controlled input reach a risky sink?
• is there a recognized guard in the path?
• did a fix block the risky path?

Safe probes do not replace dynamic testing, penetration testing, or full runtime validation.

Provider And Throttling Notes

Model speed and reliability depend on provider limits.

Azure AI Foundry may be paced by default because previous testing showed real 429 rate-limit behavior. Other providers normally run looser unless configured otherwise.

If a provider returns 429s, configure throttling:

• Owlvex: Configure Provider Throttling

Data And Backend Boundary

Owlvex is designed so local code analysis and fix preview happen in the extension.

The backend is used for:

• licence/access state
• onboarding/account workflows
• usage metadata
• report/comparison metadata where enabled
• signed rule/remediation pack delivery where available and entitled

Customer source code should not be sent to the Owlvex Azure backend for normal scanning. LLM provider requests depend on the provider you configure.

Public trust docs:

• privacy and data-flow boundary
• known limitations
• support and vulnerability disclosure
• plan and pricing contract

These live in the public Owlvex repository.

Troubleshooting

Setup Loops Or Access Problems

Run:

• Owlvex: Test Trial Setup

Check:

• backend URL
• licence/access state
• email used for registration
• whether the extension is dev or production

Provider/Model Does Not Stick

Check workspace-level VS Code settings overriding:

• owlvex.provider
• owlvex.foundry.model
• provider-specific model settings

Workspace settings override global settings.

Azure AI Foundry Fails

Check:

• endpoint URL
• deployment name
• API key
• whether the deployment exists in Azure

Scans Are Slow

Common causes:

• large workspace scope
• model latency
• provider throttling
• repo-context AI passes
• verifier/skeptic escalation
• large candidate sets

Use current-file, selected-file, or changed-file scans for faster feedback.

Fix Preview Is Rejected

Owlvex may reject a fix if the generated patch rewrites too much code for a finding-anchored remediation.

Try:

• regenerate diff
• scan current file
• ask for a smaller finding-anchored fix

Recommended Evaluation Workflow

1. Install the VSIX.
2. Open Owlvex.
3. Choose View Plans, Activate Owlvex Pro, Redeem Sponsored Code, or enter an existing licence key.
4. Select project root.
5. Configure provider/model.
6. Scan one current file.
7. Create a summary report.
8. Preview a fix.
9. Keep or discard the fix.
10. Review post-fix verification.
11. Try changed-file scanning during normal development.
12. Optionally configure Design Box for deeper project-specific review.

Feedback

If a result looks wrong, collect:

• report file
• provider/model used
• scan scope
• selected security lenses
• Design Box file type if used
• scan warnings
• the exact action that failed

Support, event help, and access issues:

• info@cooperbox.co.uk

Security reports:

• info@cooperbox.co.uk

Do not send private source code or full licence keys in public reports. For licence issues, send only the first and last four characters of the key when needed.