Technology
Inference is the unit of the product
Arthex produces one brief per company per reporting event. Everything on this page — the scheduling, the storage, the extraction schema — exists to make that single output correct, checkable and repeatable.
The hard part was never collecting the documents. It is reading a full filing and an hour of prepared remarks and analyst questions closely enough to say what actually changed, and then being able to show the line it came from. That reading is done by a model, which makes inference the atomic unit of the product: one covered name, one quarter, one pass of analysis.
The architecture described below is our target state on AWS. AWS Amplify, which serves this site, is live today. The remaining services are planned, and they are marked as such throughout rather than blurred.
Read the whole document
Earnings analysis is a comparison problem. The sentence that matters is usually the one that differs from last quarter, so the model is given complete documents and the prior-period record rather than retrieved fragments.
Emit structure before prose
The first output of an analysis run is designed to be a typed record of results, expectations and guidance ranges — not a paragraph. Writing happens afterwards, from validated structure.
Cite, or do not publish
Provenance is designed in as a first-class field: a value that cannot be tied back to its source is intended to be dropped rather than softened into hedged prose.
Let the calendar do the triggering
Work should start when new evidence exists — on a reporting event — not on an arbitrary schedule. The earnings calendar is the clock the pipeline is designed around.
Document analysis
Long-context reading of filings and transcripts
A single name in a single quarter means a filing, an earnings release, a call split between drafted remarks and unscripted questions, and whatever the same management team said three months earlier.
Retrieval alone struggles with this material, because similarity search finds what is present and cannot see what has gone missing — and in earnings work, a target that quietly stops being repeated is often the finding. Arthex is designed to put the whole set in front of the model at once, so the analysis is comparative from the first token instead of reassembled from fragments afterwards. Long-context analysis on Amazon Bedrock is the planned engine for this stage, and it is the main reason the product is designed around Bedrock rather than around a search index.
Whole documents, not fragments
Filings are read with their structure intact — segment tables, footnotes and risk language stay attached to the numbers they qualify. Context that is chunked away tends to be exactly the context that changes an interpretation.
Prepared remarks and Q&A are different evidence
Prepared remarks are drafted, reviewed and deliberate. Q&A is where hedging appears, where a target goes unreaffirmed, and where a caveat gets added under pressure. The two are treated as separate classes of evidence.
Quarter over quarter by construction
Each run is anchored against the same company's prior documents. Continuity is not bolted on later — it is the frame the analysis starts in.
Absences count
A metric dropped from the release, a segment no longer broken out, a full-year figure that goes unmentioned: because the comparison is against the previous document rather than a generic index, removals can surface as findings rather than silence.
Structured extraction
Surprise and guidance deltas, as data rather than commentary
The model's first job is designed to be extraction, not writing.
For each reporting event the pipeline is intended to emit a typed record: every headline metric with its reported value and the expectation it is measured against, every guidance range as it stood before and as it stands now, and the direction and magnitude of each change. That record is validated against a schema before anything downstream touches it — units normalised, periods explicitly labelled, reported and adjusted figures kept apart rather than silently mixed, and any value the model cannot source left null rather than guessed. Only once the structure holds does a second pass turn it into the brief a reader sees.
Reported against expectation
Each result is captured with the expectation it is judged against, so a surprise is a computed delta on the record rather than an adjective in a sentence.
Guidance before and after
Guidance is stored as a range with a period attached, in both its prior and current form. Raises, cuts, narrowed ranges, reaffirmations and withdrawn guidance are all representable — including the case where a previously issued figure simply is not mentioned again.
Emphasis, not only numbers
What management chose to lead with, repeat, reframe or stop discussing is extracted alongside the figures, recorded as observations tied to specific passages rather than inference floating free of the transcript.
Schema validation before publication
A run that fails validation is designed to be a failed run. Malformed periods, unit mismatches and unsourced values should stop the record rather than degrade quietly into prose that reads plausible and is wrong.
One record, many surfaces
The validated record is intended to be the shared source for the chart, the earnings overview and the written analysis, so every view of a quarter renders the same underlying data.
Citation and traceability
A figure that cannot be traced should not ship
A research tool that cannot show its working is a liability, not an accelerator.
So provenance is being built as a first-class field rather than reconstructed at the end. The intent is that every extracted value records the document, the section and the span it came from, and that an assertion with no traceable source does not reach a brief. A shorter brief is a better outcome than an unverifiable one. This is a design rule for the Bedrock-based pipeline described above, not a description of something already running.
Span-level provenance
The intent is that a citation resolves to a passage, not to a document. Pointing at a hundred-page filing is not a citation; pointing at the sentence containing the revised range is.
Source documents retained, not just parsed
The planned S3 corpus is designed to keep original filings and transcripts, so a citation resolves against exactly the text that was analysed — including where a document is later amended and both versions matter.
Unsupported claims are dropped
Statements that survive drafting but cannot be tied to a source span should be removed before publication rather than softened with hedging language.
Analysis, not advice
Arthex describes what was reported, what changed, what was said and how the market responded. It does not issue recommendations, execute trades or manage money. The judgement stays with the investor; the reading is what we take off their desk.
Ingestion
The earnings calendar is the scheduler
Nothing in Arthex is designed to run on a cron of convenience. Work is triggered by the reporting calendar for the names on a watchlist, because that is when new evidence comes into existence.
In the planned design, Amazon EventBridge opens a window around each expected report date and AWS Lambda does the fetching: the release and filing first, the transcript when it publishes — frequently hours behind the numbers — with pricing and volume collected around the print. Documents would land in Amazon S3 as a per-name history; validated results in Amazon RDS alongside watchlists and accounts. Runs are designed to be idempotent and keyed to the reporting event, so a late transcript, a corrected filing or a re-run updates one brief instead of producing a second, competing one.
Event-driven, not polled
Scheduling is designed to follow the calendar of expected reports per name, so ingestion concentrates where the evidence is instead of sweeping the market continuously.
Late and amended documents are the normal case
Transcripts arrive after releases, and filings get amended. Analysis is keyed to the reporting event, so new material re-triggers work for that event and supersedes the prior result rather than duplicating it.
A per-name corpus, not a pile of files
Documents are stored per company with history intact. That history is what makes quarter-over-quarter comparison cheap and what keeps old citations resolvable.
Market response captured around the print
Price and volume in the sessions surrounding a release belong to the same event record, so the reaction sits with the result rather than in a separate tool.
Backfill uses the same path
Adding a name to a watchlist should replay its prior reporting events through the identical pipeline. History and live coverage produced by one code path can be trusted equally.
Target architecture on AWS
Where each part is planned to run
Arthex is designed for AWS end to end. We would rather set that design out plainly than imply more of it is running than actually is.
Amazon Bedrock — core inference (planned)
The engine the product is designed around: long-context analysis of filings and transcripts, extraction of surprise and guidance deltas, and generation of the brief. Model selection is intended to sit behind one interface per stage, so extraction and drafting can use different models without rewriting the pipeline around either.
Amazon S3 — filing and transcript corpus (planned)
Source documents stored per name with full history. This is what citations are intended to resolve against, and what would make each quarter comparable to the one before it rather than analysed in isolation.
AWS Lambda and Amazon EventBridge — ingestion (planned)
Calendar-driven scheduling and fetch. Because load arrives in four concentrated windows a year, serverless execution should keep the quiet weeks inexpensive and let a heavy reporting day fan out in parallel rather than queue.
Amazon RDS — structured results and accounts (planned)
Validated results, extracted deltas, watchlists and account data — the relational core the dashboard would read from, and the join between a user's coverage and the analysis produced for it.
AWS Amplify — front end (live today)
arthex.io is hosted on AWS Amplify now. It is the one component of this architecture already in production, and the reason the rest of the stack is being planned on AWS rather than assembled elsewhere and migrated later.
Cost and scale
Built around the shape of earnings season
Demand for this product is not smooth, and pretending otherwise would produce the wrong architecture.
Four times a year most of a watchlist reports inside a few crowded weeks, and between those windows there is very little new to read. That shape drives the engineering as much as the analysis does. Cost is expected to be dominated by inference per name per quarter — a unit that can be measured directly, and one that maps cleanly onto how Arthex is priced. Tiers are planned around that same unit, and specific prices are not published yet.
Cost follows coverage
The dominant cost is inference for one name in one quarter, which is the same thing the customer buys. Unit economics and the pricing unit are deliberately the same shape.
Peaky by nature, elastic by design
Reporting seasons produce order-of-magnitude swings in load. Event-driven, serverless ingestion is chosen to absorb the peak without provisioning for it year-round.
Right-sized model per stage
Extraction, comparison and drafting have different accuracy and length demands. Splitting them into separate calls lets each stage use the smallest adequate model instead of paying for one heavyweight pass over everything.
Analysis is done once per event
A completed brief is stored against its reporting event and served from there, so readers of the same quarter are not re-running the same inference. Marginal cost stays tied to coverage rather than to traffic.
Build status
What exists, and what is planned
Being plain about the state of the build is more useful than blurring it.
The research workspace is built — charts, earnings overview, market overview, volume tracking, watchlists and market data. This site is live on AWS Amplify. The analysis pipeline that writes the brief is in active build, and moving it onto Amazon Bedrock, with the corpus on Amazon S3 and calendar-driven ingestion on AWS Lambda and Amazon EventBridge, is what the target architecture above describes.
Arthex is pre-launch. The product is in active build, early access is granted by request, and no tier is purchasable yet.
Built
The research workspace: price and earnings analysis, earnings overview with surprises and guidance changes, market overview, volume tracking, watchlists, real-time market data, and dark and light themes.
Live on AWS
AWS Amplify hosts arthex.io today, serving a statically exported Next.js application.
Planned on AWS
Amazon Bedrock for core inference, Amazon S3 for the filing and transcript corpus, AWS Lambda with Amazon EventBridge for calendar-driven ingestion, and Amazon RDS for structured results, watchlists and accounts.
Who builds it
DevDash Labs, an applied AI research and development company founded in 2020 and focused on AI since 2022, powered by world-class Nepali talent with global ambitions. Its mission is to ignite the AI revolution within organizations.