Market research with source review

SigBlaze connects market research to the decisions it is meant to inform. An agency strategist or product marketer can define a question, collect sources, inspect claims, review insights, and turn approved intelligence into positioning, campaign direction, battlecards or reports. Monitoring brings later changes back into the same workspace.

The delivered artifact is a working local application and a product website, supported by a V2 product definition, architecture, data model and software tests. The screens here come from its fictional demo workspace. They demonstrate the interaction model; they do not establish customer adoption or the accuracy of live market research.

SigBlaze began as the LIT research project: an industry research → insights → insight-led creative workflow for the LIT School × AI Learn Circle GTM hackathon. The first experiment joined research, evidence, synthesis and creative hooks in one loop. It became the starting point for SigBlaze rather than a separate portfolio project. Precise hackathon dates, team credits and submission outcomes remain unconfirmed.

The later V2 scope reframes that challenge as reusable evidence-to-action intelligence for agencies and B2B teams. Instead of stopping at a polished ad idea, the system needs to explain what the idea rests on and preserve that reasoning for the next question. September’s V2 definition and October’s monitoring implementation describe this evolution, not a verified end-to-end project timeline.

The PRD identifies fragmented research across browser tabs, AI conversations, review sites, spreadsheets and documents. Its central hypothesis is that teams repeatedly rediscover information, lose attribution and miss changes. This is a documented product hypothesis, not a finding from interviews conducted for this case.

A reviewer needs to inspect the sources behind claims, insights, and recommendations. They also need access to contradictory reviews and a clear explanation when the system lacks evidence for an answer.

The initial audience in the product definition is boutique B2B agencies, fractional CMOs and GTM consultants, and SaaS founders or product marketers doing recurring competitor research. These are intended audiences, rather than personas validated by participant studies.

For an agency strategist, the job is: when I prepare a client recommendation, help me connect it to inspectable sources so I can explain and revise it. For a product marketer: when a competitor changes pricing or positioning, help me understand the difference and decide whether our battlecard needs updating. Workspace separation, freshness, contradiction visibility and review history support these jobs.

The prioritisation document makes the first vertical slice explicit: workspace → research goal → plan → sources → claims → contradictions → insights → action → review/export. This gives each screen a reason to exist and keeps creative generation downstream of the evidence.

Monitoring and briefs were initially later-stage scope. The current source and interface now include them, along with a graph and automations. They remain part of one integrated evidence system. Email alerts, uploaded-document retrieval and richer exports should not be inferred from the presence of a roadmap or marketing page.

A useful MVP hypothesis is that a target user can inspect the evidence behind a recommendation and reuse it for a second decision. The next validation should measure that task, source trust and review effort. No measured time saving or conversion improvement is available.

Current desk research helps situate the product. These tools already solve important parts of the job; the opportunity below is a product hypothesis, not a claim that SigBlaze outperforms them.

The available artifacts show a legacy campaign-oriented concept, a broader V2 product definition, domain and provider contracts, staged services, and a working interface. They support a progression from output generation toward persistent intelligence. Original wireframes, workshop notes and dated design iterations were not available.

I reconstructed the flows and decision comparisons from the implementation I inspected. I drew the diagrams for this case study; they are not historical research artifacts. I used them to examine what a reviewer can inspect and approve at each stage.

The app separates the work a person does, the records that work produces, and workspace configuration. Ask is the entry point; research and monitoring build evidence; reviewed intelligence moves into actions. The graph exposes relationships across these surfaces.

A fictional analytics team researches competitors, inspects a disputed onboarding promise and reviews a pricing change. Each stage below shows a captured screen, the user’s objective, the system’s job and a recovery path.

The implementation is a Next.js modular monolith with API services, a store abstraction and replaceable model/retrieval adapters. Real mode uses Supabase; the observed local demo uses an in-memory store. Research pins context, plans bounded tasks, retrieves and deduplicates sources, extracts claims, checks contradictions and synthesises insights.

Model tasks have typed inputs and schema-validated outputs. An allowed-reference manifest rejects IDs the model was never given. Source-span validation checks that a quoted passage appears in the stored material. Ask reads stored evidence and has an explicit insufficient-evidence path. These checks constrain failure; they do not make every cited claim true.

Models handle planning, extraction, interpretation and drafting. Software handles ownership, source deduplication, reference validation, claim-status policy, snapshot comparison, review gates and exports. This division is more useful here than claiming an autonomous agent swarm. Adapters for Gemini, Anthropic and OpenAI-compatible models exist; configured live provider success was not established in this review.

Research stages record state and support retry/cancel. The inspected start-run path executes the service rather than proving an independently deployed job queue. Scheduling likewise needs an external cron trigger and deployment secrets. Provider absence and partial retrieval are product states, not successes to simulate.

The app uses Nivoraq-derived tokens, Inter for the interface and JetBrains Mono for utility data. Monochrome panels and an orange accent keep attention on the research. Labels distinguish support, confidence, importance and review status; colour is reinforced with text and icons.

Preferences include light, dark and system modes, preset palettes and a custom-theme system with contrast-aware derivation. That implementation is distinct from this portfolio’s appearance controls, which remain intact.

Live research is disabled in the observed setup until retrieval and model providers are configured. Seeded data makes the interface reviewable, but cannot validate live extraction quality, citation correctness, cost or latency. Scripted demo monitoring demonstrates transitions rather than continuous observation of real companies.

One concrete gap appears in the captured battlecard: it links an approved insight but displays zero direct sources. The service includes lineage persistence and the linked insight has evidence, but the rendered seed does not complete the promised chain in that view. That mismatch should be resolved and tested before presenting the workflow as fully validated.

Reviewers need to verify source-backed claims. I would test whether users understand the confidence and freshness labels. The source includes authentication, role checks, and RLS migrations. I have not verified deployed tenant isolation through the local memory demo or injected-fake tests.

The early documents and current interface differ in scope. That is a documentation-maintenance problem to revisit: feature status should have one current source. Increasing the number of surfaces also risks burying the primary research-to-review path. A target-user study should test navigation before the product expands further.

The tangible outcome is a working local workspace where a reviewer can move between a research run, its claims and sources, a signal’s before/after evidence, an insight and an action. A marketing website communicates the same product definition. This is implementation evidence, not a business-impact claim.

For this case-study review, 106 existing software tests passed across five selected suites covering domain rules, the research pipeline, monitoring, workflows and configurable providers. Captured screens establish demo rendering and navigation. No usability participants, customer adoption, award, launch outcome or measured commercial improvement is claimed.

The local product website positions SigBlaze as private alpha and presents research, monitoring, signals, briefs and Ask as connected surfaces. Its interface imagery is labelled synthetic. That public positioning is not proof of a production launch or active users.

I would ask target users to trace an action to its source, interpret a contested claim, and recover from missing evidence. I would observe where they get stuck and whether they can explain the source support.

Next, evaluate a bounded set of live research questions for citation validity, exact source spans, unsupported-answer refusal, outdated evidence, contradictions, cost and latency. Then test real-store tenant isolation and scheduled checks in a dedicated deployment. These are proposed validation steps.

Only after those results should the roadmap expand to uploaded documents, alerts, richer exports or white-labelled reports. The code’s workflow builder offers another path to reuse, but more automation should preserve review gates and evidence lineage.

I would focus the next design review on source retention, uncertainty labels, approval permissions, and recovery after failed research. A reviewer needs to inspect and challenge an answer before using it.

I would revisit the breadth of navigation and the distinction between confidence, importance and factual support. I would also seek stronger evidence for the audience assumptions before extending the creative workflow. This reflection explains the current product through a design lens; exact individual build ownership and collaborator attribution still require confirmation.