# Signalpost company intelligence challenge

Challenge page: [builderr.ai/challenges/signalpost](https://builderr.ai/challenges/signalpost)  
Public sample: [builderr.ai/signalpost](https://builderr.ai/signalpost)

Build a research product for Norway-domiciled companies with publicly traded equity, whether listed in Norway or abroad. Builderr supplies the large, audited, frozen company universe and source rules. Universe discovery is not scored. Win by capturing broad evidence about those companies, keeping it accurate and current, and helping users ask cross-company questions and return to saved work.

**Sponsor:** [Liltved](https://www.linkedin.com/in/liltved/) — a Norwegian serial entrepreneur, CPO at Front End, and founder of JBox.

## Rewards

**Public reward headline: $2,500 in final rewards, plus another $100 every fortnight.**

- **$2,000 main challenge pool.** The final split will be published before entries open.
- **$500 JBox bonus pool.** This is available to final top-three results built using the [JBox](https://jboxai.com/) platform.
- **$100 every fortnight.** Every two weeks, one qualified agent receives the public-vote award. Only entries that pass the published qualification checks enter the vote; voting never changes the final score or ranking.
- **Hosting is covered.** Builderr hosts qualified agents for the competition voting and review period, so entrants do not pay the competition hosting cost.

## What to build

1. Search a listed equity by company name, ticker, ISIN, market, municipality, or industry.
2. Open a clear company page with issuer identity, status, facts, official filings, and links to the evidence.
3. Research issuer updates, filings, company announcements, and defined public signals with dates, sources, and a clear availability state.
4. Explain whether the company looks improving, weakening, or mixed as of the cutoff: what changed, why it matters, which evidence supports the view, and what conflicts with it. This is descriptive research, not a price prediction.
5. Let a user ask a natural-language question across companies, return the exact matching set, and explain the useful patterns with citations.
6. Save searches, pins, recent questions, and workspace state in the user's browser so the work remains after a reload.
7. Check for new filings or signals and show what changed, when it changed, and where the new value came from.

The research agent and update agent are part of the intended product: one explains a selected company's trajectory from cited evidence; the other checks for new filings or signals and records a reproducible diff. Every answer must stay within the cited data. Issuer-reported outlook and dated public buzz are core signal inputs, not vague sentiment. Label them, cite them, and keep them separate from verified facts.

## Start here

Run one end-to-end lookup first. Then add exact filters, a source-backed trajectory view, and a refresh diff. A small product that explains one company correctly is more useful than a large catalogue with unverified claims.

For the first prototype, target the locked Norwegian publicly traded company fixture. The lookup, profile, evidence-backed research answer, and update path are the bar. A company may be listed in Norway, the United States, Europe, or elsewhere, but it must have official evidence identifying Norway as the issuer country. Do not add private, unlisted, foreign-domiciled, or generic comparator entities to the public Norwegian index.

You do not need to build authentication, billing, or subscriptions. For the prototype, saved searches, pinned companies, recent questions, and workspace state should persist in local browser storage. Export should preserve the active query, selected columns, provenance, and extraction date. A production version can move the same saved workspace behind a login later.

## How it is checked

The evaluator will use the same locked company set, source archive, and dated test windows for every entry, with the qualification bar published before entries open.

| Area | Points | What is tested |
|---|---:|---|
| Information breadth and usefulness | 30 | Core financial depth plus additional useful information found across filings, company sources, news, social sources, and the wider public web |
| Accuracy and freshness | 30 | Correct facts and periods; claim-level sources; honest missing data; detected updates; reproducible history |
| Agentic research and screening | 25 | Natural-language cross-company questions; correct result sets; useful cited insights; saved searches, pins, history, and reusable exports |
| UX and ease of use | 15 | Finding a company, understanding the case, inspecting evidence, seeing changes, and returning to prior work |

Every entry must first clear the core financial-information baseline: company identity, reporting period, income statement, balance sheet, cash flow, debt/liquidity, margins, and core filings where available. Accuracy is also a gate. Material identity or financial errors, fabricated claims, or silent missing data make an entry ineligible to win.

After the baseline, breadth is competitive. Under the same company sample, cutoff, runtime, and cost budget, entries earn more for unique, relevant, correctly attributed findings—not for raw page or post count. Useful additions can include guidance, ownership, governance, operations, regulation, customers and suppliers, credible news, and relevant public posts on X or other social sources. Duplicate or immaterial mentions add no credit. Social posts provide context; they do not prove financial facts by themselves. The supplied company universe is an input, not a scoring category.

## Coding qualification gate

Code quality does not earn separate presentation points. It must clear these pass/fail checks before the product is scored:

1. **Runs from a clean checkout.** Provide one documented setup path and one command that starts the product. Pin dependencies and declare required models, APIs, network access, licences, expected runtime, and expected cost.
2. **Uses the supplied universe.** Load the published universe version and stable company IDs instead of hard-coding a demo list. Keep a legal company separate from its one or more traded instruments.
3. **Keeps result membership deterministic.** A natural-language screen must produce an inspectable structured query and the exact matching company IDs. A language model may explain the result, but it must not silently add or remove companies.
4. **Keeps claim-level evidence.** Every material output must retain company ID, claim/value, reporting period, source class, source URL or archived artifact ID, source date, retrieval time, cutoff, and availability state.
5. **Refreshes without overwriting history.** Store immutable source snapshots or an equivalent audit log. Re-running the same snapshot must be idempotent; a changed item must show old value, new value, source, effective date, and retrieval time.
6. **Handles source access safely.** Keep credentials server-side, validate source URLs and responses, block unrestricted server-side URL fetching, sanitize extracted content before rendering, and never execute retrieved page content as code.
7. **Stores prototype state safely.** Version the local-storage schema, recover from corrupt or old state, provide a clear-local-data action, and never store API keys, paid-source credentials, or restricted source documents in browser storage.
8. **Includes focused tests.** Cover exact query membership, ambiguous input, missing/conflicting/stale evidence, seeded refresh changes, persistence after reload, malformed local state, and rejected unsafe source URLs.

A setup or evaluator failure is blocked and rerun. A submission-specific failure after the documented setup is attempted is reported as such; it is not disguised as a factual score.

Entrants are not scored against whatever data happens to be reachable on their own machine during the run. Qualification and the main score use the same locked fixture, source archive, and dated holdout for every entry. The evaluator tests both the answer and its evidence: claim-level correctness, source date, why the trajectory call was made, conflicting signals, and the refresh diff.

The audit fixture at [builderr.ai/signalpost](https://builderr.ai/signalpost) contains 500 dated listed-equity records. The public index currently exposes 251 Norway-qualified profiles representing 248 distinct names. Foreign issuers listed in Oslo and non-Norwegian Euronext comparator records remain in the fixture for evaluator coverage but are explicitly excluded from the public index. Sole proprietorships and other unlisted registry entities are excluded. A missing filing is not treated as zero.

Use the [source map](https://builderr.ai/starter-briefs/signalpost-sources.md) to choose sources and label each field's availability, timestamp, and provenance. Financial filings should come from official issuer, exchange, regulator, or filing sources where available. Company announcements and investor updates are company-reported. Public news or market-interest signals must use the defined source classes and a dated retrieval; search snippets or social chatter are context, not proof. Do not turn an unavailable signal or filing into zero.

Sources behind a login, API key, or paywall are allowed when the access is lawful and the result remains auditable. Declare the provider, licence, cost, retrieval method, and limits. Give the evaluator access or a permitted archived evidence bundle. Never commit credentials. A source the evaluator cannot reproduce or inspect cannot earn evidence points.

## What a good research answer does

- Answers a fixed question about the selected company and reporting period.
- Separates reported facts from the agent's interpretation.
- Cites the exact source and date behind each important claim.
- Explains why the trajectory looks up, down, or mixed, including conflicting evidence.
- Makes the trajectory call as of the stated cutoff; it does not present a price target or investment advice.
- Says "not enough evidence" when the sources do not support a conclusion.

## Submission notes

Include the repository, a short run command, data sources and licenses, refresh behavior, and a note describing anything your product cannot verify. Include the command a reviewer should run and the URL or local route for the product. Do not commit credentials. The full challenge uses the same fixed inputs for every qualified entry.