Open Questions

Every project accumulates decisions it has deferred and documents that have drifted from the code. This page is the register. Nothing here is a complaint; it is a work queue, in rough order of what it blocks.

Decisions only the founders can make

These five are from the platform roadmap. Work is blocked or wasted until they are answered. The first of them is now answered — and the answer opened a further set, recorded in the section after this one.

1. Is Demostatics moving money, or instructing someone who does? — answered

Answered 2026-08-01, by founder decision. Demostatics will operate as an investment company running four lines of business at once: data and intelligence, investment advisory, discretionary management and proprietary trading. It will advise clients, manage client capital, and trade its own book, while continuing to sell the data underlying all three. Lines 2, 3 and 4 are Planned — there is no implementation of any kind in any repository. See Business Model.

Superseded: the recommendation previously on record here was never to take custody, to integrate a licensed broker or payment service provider and store only references, and to keep any money schema out of the repository until a partner was under contract. The never-take-custody part is overridden by founder decision. Whether the firm ends up holding client assets itself or holding only a mandate over assets at an independent custodian is a separate question, and still an open one — see Regulatory Posture.

What survives the supersession: the reason for keeping money schema out of the repository was never that custody is wrong. It was that a half-designed money schema is a liability the day it merges rather than the day it is used. That reasoning still holds. The money layer should be designed against a real licence and a real custodian, not against a guess at what either will require.

Unblocks: the final phase of the roadmap is no longer conditional. Phase 9 (money movement) becomes mandatory, and a timer whose action is “execute” rather than “notify” is back on the table.

Now blocks on licensing instead of engineering. Nothing in the money layer can be designed against a real counterparty until there is a jurisdiction, a regulator and a permission, and that is the longest-lead-time item on the roadmap — months to years, and no amount of engineering shortens it. Nothing on this page is legal advice; every regulatory item here needs qualified counsel.

2. Who owns the worker backend, and will it emit numerics?

It exists in no repository and is the hard dependency for charts, thresholds and conditional alerts. One conversation replaces months of workaround.

Blocks: everything that makes this a data product. See Worker Tier.

3. One identity authority — Laravel or the stream backend?

Recommendation on record: Laravel owns users, roles, bans and verification, and mints a short-lived signed ticket the stream backend verifies offline via JWKS. Anything else means a revoked device keeps its data stream.

Blocks: any shared session between the phone and the desktop.

4. What can a free or lapsed user actually see?

An app that is a pure paywall over server data risks App Store rejection under guideline 4.2, and looks broken to a first-time visitor. Forum, polls and editorial are the natural free surface.

Blocks: the entitlement model, and store submission.

5. Turkish now or later?

Roughly 155 user-facing strings today. Retrofitting internationalization after the next phases costs three to four times as much.

Blocks: nothing today, and progressively more every month.

Decisions the founders and counsel must make together

The 2026-08-01 positioning decision closed one question and opened these. None of them can be answered from inside the codebase, and none of them should be answered without qualified counsel in the relevant jurisdiction. They are written as questions because that is what they are — nothing here is a recommendation, a specific licence, a threshold or a timeline, and nothing here is legal advice. Regulatory Posture carries the longer form of each.

6. Which jurisdiction, and which regulator?

Where is the firm incorporated, where is it managed from, and where do the clients live? Serving clients in a jurisdiction generally brings a firm under its rules regardless of where it is registered, and each of the four lines may fall to a different supervisor. If Türkiye turns out to be the base, the capital markets regulator is the SPK (Sermaye Piyasası Kurulu) — but the jurisdiction is undecided, and that sentence is a question for counsel, not something to build against.

Blocks: every other question in this section, the licence application, and therefore Phase 9. It is the longest lead time in the business and it has not been started.

7. One entity or several — and does the platform sit inside the regulated one?

Can advisory, discretionary management and proprietary trading share a single legal entity, and where they can, should they? The version of this question that matters most to engineering: does the data platform belong inside the regulated entity, or in a separate company that licenses data to it and to everyone else?

Blocks: who employs the engineers, which repository is subject to regulatory inspection, and whether the platform’s access controls are internal policy or a condition of a licence. It also decides whether line 1 can keep shipping on its own timetable.

8. Does the prop desk trade before, with, or after subscribers see a figure?

The same pipeline now feeds paying subscribers and the firm’s own book. “Did you trade ahead of your customers” cannot be answered with policy — it has to be answerable from publication timestamps and the firm’s own order timestamps, under a rule the system enforces rather than one the firm promises. Subscribers first, simultaneous release, tiered timing and firm first are genuinely different products; the four are set out on Business Model. This one is for the founders first and counsel second.

Blocks: the design of the publication path. Whichever rule is chosen, the internal consumer and the external one have to be sequenced by the system, which makes it a schema and scheduling decision rather than a document.

9. How are orders allocated between the firm’s book and managed accounts?

When the firm and the clients whose money it manages want the same instrument, whose order goes first and at what price? Regulators generally require this to be structurally prevented rather than disclosed, which in engineering terms means deterministic, logged order sequencing with an audit trail behind it.

Blocks: any order-management component, and line 3 in practice. There is nothing to build on: no repository contains an order, a position, a portfolio or a custodian integration of any kind.

10. Who owns compliance, and is it a named role?

Every question above produces obligations that need somebody accountable for them — who signs off on public content, who maintains record-keeping, who runs onboarding checks if they apply, who answers a regulator. There is no compliance function today, no policies and no counsel engaged.

Blocks: the licence application, if counsel confirms a named function is required; and in the meantime every sign-off that currently falls to engineering by default.

11. Do the forum and the editorial layer become regulated communications?

Demostatics runs a public forum, and the documentation commits technical staff to replying in it. Once the firm is licensed, a staff member answering “should I buy this” in public may count as regulated communication. The moderation model has no compliance dimension today and no named approver for public content.

Blocks: nothing this week, and the entire public surface on the day a licence is granted. See Moderation.

The structural problem

There are two API contracts and one of them is not implemented. demostatics-web serves /api/v1 with opaque Sanctum tokens over REST; the desktop client targets /v1 with signed JWTs over WebSocket, QUIC and gRPC, served only by a mock inside its own repository. They disagree on path prefix, token type, refresh, entitlement model, transport, billing, classification and value type.

This is the platform’s single most consequential open engineering problem, and it has its own page: The Two Contracts.

Cost to settle: one week of nobody writing code, as roadmap Phase 1. Every later phase assumes it.

Contradictions inside the codebase

Each of these is a place where two parts of the project disagree about the same fact. They are listed so nobody has to rediscover them.

#	Contradiction	Where
1	The mobile README’s architecture diagram shows the desktop client consuming /api/v1. It does not — its own roadmap says the opposite, and the diagram has already been corrected once	demostatics-mobile_application/README.md
2	The roadmap’s comparison table says Sanctum tokens have “no expiry”; the same file’s “Done” list, and config/sanctum.php, say they expire at 30 days. The table is stale — “no refresh” is still true	demostatics-mobile_application/docs/roadmap.md
3	Both routes/api.php and docs/api-v1.md claim the API access tiers mirror the web routes exactly. The geo cascade and the subcategory lookup are public on the API while their web twins sit behind auth and verification	demostatics-web
4	The moderate token ability’s own docblock says it is “held only by tokens whose owner has the role”, but it is granted to every interactive token regardless of role	demostatics-web/app/Support/TokenAbility.php
5	Sanctum’s abilities and ability middleware are registered, and ingest:write is documented as protecting a worker-only endpoint — but no route uses either middleware and no such endpoint exists	demostatics-web
6	The desktop’s documented dev accounts (pro@demostatics.com and siblings) are not the ones its code accepts (pro@example.com and siblings), so every quickstart command in the README fails to log in	demostatics-pc_application
7	expires_at is specified on both auth responses by the contract, and is emitted by neither the reference server nor parsed by the client. It exists only in prose	demostatics-pc_application
8	”Signed JWT” is the contract’s central decision. There is no signature verification anywhere in the repository — the only token is an unsigned dev token that the mock validates by base64-decoding it	demostatics-pc_application
9	POST /v1/ai/chat and the gRPC Backfill method are implemented in code and documented in ARCHITECTURE.md, but absent from API_CONTRACT.md	demostatics-pc_application
10	Three classification models are documented: Laravel’s seven fixed columns, the desktop’s taxonomy, and the five-dimension model the taxonomy replaced — of which only a dimension: String field name and some test fixtures survive in the desktop code	Platform-wide
11	The README documents rate limits on post and comment creation. No such middleware exists; web content creation is unthrottled	demostatics-web
12	The pitch deck describes the technology only as “self-operating computational systems”, omitting every concrete dependency the founding document commits to — C/C++ workers, ML/LLMs, satellites, mapping APIs, Laravel	Founding documents
13	The English specification names the backend a “worker-based task processing system”; the Turkish one names the same component a “General Purpose Task Processing System”	Founding documents

Dead and orphaned code

Not urgent, but each is a trap for the next person reading the repository.

• The tasks table. A full job-scheduling schema — task_id, job_type, parameters, priority, dependencies, deadline, retry_count, status, result_location — sitting in the display tier with neither a producer nor a consumer. Worker-coordination schema in the wrong repository.
• App\Models\Ban::bannedBy() joins a banned_by column that no migration creates, so calling it fails. Nothing anywhere records who placed a ban.
• POST /users/{id}/reports is a registered route whose controller method is empty, carrying a TODO to email a moderator.
• app/Enums/JobDefinition.php matches against enum cases that are not declared, and JobConfig.php is dead scaffolding. Nothing calls either; both would fatal if anything did.
• StorePostRequest has an empty rules array and is referenced by no controller.
• questions — 66 seeded classification prompts across sociology, economy, politics, ecology, security, demographics and transportation, read by nothing.
• On the mobile side: four API client functions with no user interface, an unreferenced WEB_ORIGIN export, and an unimported global.css.

Behaviour worth knowing before you build on it

• Reads mutate rows. Fetching a post or a poll increments its view counter, and the increment touches updated_at. So updated_at does not mean “last edited” — do not key a cache on it expecting that.
• A ban deletes all of a user’s tokens on their first request afterwards. Nothing references those token rows today, so this is not a bug — but it is a constraint on the future device-link and push-token tables, whose foreign keys must be designed to be revoked rather than nulled.
• The geo cascade degrades to empty, never to an error. “No regions exist” and “the geo store is down” are indistinguishable except through GET /api/v1/health.
• The desktop’s Forums pane makes no network calls at all. It is a local shell.
• The schema cannot answer “what did we know, and when”. reports carries one published_at; database_items carries one measured_at. Neither table has a source, a method, a method version, an ingested-at distinct from the measurement, or any revision history — a corrected value simply overwrites the value somebody acted on, leaving no trace of either. That was a display detail while the platform only displayed things. Now that advisory calls, managed portfolios and the firm’s own trading book run off the same figures, it is a record-keeping obligation the platform cannot currently meet: a number used in a decision has to be reconstructible years later. It is a column set to add before the Phase 2 tables exist and a backfill of everything ever published afterwards. See Regulatory Posture.

Unexamined business assumptions

These are not engineering problems, but they are the ones most likely to matter.

• No pricing exists. No price points, no currency, no tier names, not even how many tiers there are.
• No market sizing, no competitor named, no positioning claim appears in any document.
• Satellite capability is unsubstantiated. No operator, imagery vendor, ground station or data agreement is named, and no cost is estimated. The figure captioned “General Satellite Communication” in the founding document is a generic textbook diagram of satellite eavesdropping, not Demostatics architecture.
• Data acquisition has no legal or cost story. Google Maps, Yandex and Baidu are paid commercial APIs; news networks and social media platforms are licence- and terms-constrained. The business model section discusses revenue and never cost of goods.
• No legal entity, privacy policy, data-protection position, retention policy, SLA or support commitment is stated anywhere, despite a product that ingests news and social data and sells to institutions. This was a gap. Under the investment-company positioning it is a blocker: there is no entity to hold a licence, sign with a custodian, employ a compliance function or stand as the data controller, and a firm that advises clients and manages their capital acquires client-data and retention obligations on top of the ones the data business already has. Counsel is required to say what they are — see Regulatory Posture.
• Localization gap. The market is framed as global and the deck is in English, while every product screenshot is entirely in Turkish. No internationalization plan exists.

Next

• The Two Contracts — the structural problem in detail
• Business Model — the four lines, and what the decision changed
• Regulatory Posture — the licensing and conflicts questions
• Roadmap — the order these get resolved in
• Deployment Readiness — what blocks going live