From Systems to Products: What We Keep, What We Change, and Where This Is Going

The current problem is not that Blackdeck and ByteCosmos lack infrastructure or features. The problem is that the public value is not yet as clear as the machinery behind it.

So the next phase is not a rebuild. It is a recomposition of what already exists.

The important distinction is: what stays, what changes now, what comes later, and what the mature product should eventually become.

1. The common principle

Both products already have useful foundations. Those foundations should remain.

Blackdeck already has event ingestion, clustering, a multi-label taxonomy, impact pathways, direction and relative magnitude, evidence references, a map-first interface, and a daily change loop.

ByteCosmos already has canonical Upbit OHLCV, a public market overview, an isolated SQL research sandbox, point-in-time historical validation, buy and sell rule definitions, forward-return exploration, and saved research workspaces.

None of this should be thrown away.

The change is in what these systems are optimized to produce.

Today, both products are more mature internally than externally. The next phase is to turn their internal capabilities into public answers that are difficult to replace elsewhere.

2. Blackdeck

What stays

Blackdeck keeps event ingestion. GDELT and other public sources remain useful for discovering candidate events. Their role is to tell the system that something may have changed, not to prove business impact by themselves.

The multi-label taxonomy also stays. An event should not be forced into one exclusive category. The current object graph remains the right foundation:

Source event -> event type -> transmission mechanism -> exposure target -> effect dimension.

One event can have several labels and several impact pathways.

The impact pathway also stays:

Event -> mechanism -> supply-chain or commodity target -> effect direction.

The current relative magnitude score also stays, but with a narrower role. It is a screening priority, not a verified loss estimate. It helps answer which pathway deserves attention first. It must not be treated as a measured quantity such as barrels lost, days delayed, monetary loss, or expected return.

The map-first overview stays as navigation. It provides spatial context and a fast view of where meaningful changes are happening. But the map is not the final product.

What changes now

The center of gravity changes from classifying many events to following a smaller number of important event-to-impact chains deeply enough to show what actually changed afterward.

The broad long-term vision remains. What changes is the order in which it is built.

Instead of trying to solve global event -> every commodity -> every supply chain -> every company immediately, the practical path is:

Selected high-value route or infrastructure -> event -> observable operational metric -> change versus baseline -> follow-up evidence -> updated assessment.

This is not a reduction of the final vision. It is the first reliable slice of it.

What we do now: Blackdeck Phase B1

The first Blackdeck milestone should be one complete observable impact chain.

A realistic first domain is maritime chokepoints and major shipping routes. Candidates include the Red Sea / Suez route, the Strait of Hormuz, or the Panama Canal.

The goal is not to cover all of them immediately. The goal is to make one of them complete.

For one selected route, Blackdeck should be able to answer:

1. What event happened?
2. When was it first detected?
3. Which transmission mechanism is relevant?
4. Which operational metric can actually be observed?
5. How did that metric change against a fixed baseline?
6. What remains unverified?
7. What changed since the previous update?

The completion criterion is not a new page. It is this: a user can return to the same event a week later and see whether the original concern was confirmed, weakened, or contradicted by later evidence.

Blackdeck Phase B2: make events persistent

Blackdeck is currently optimized around a current screening window. That is useful for what is happening now, but weak for cumulative intelligence.

The next event model should preserve a stable identity and an update trail:

First detected -> initial interpretation -> new evidence -> changed assessment -> observed outcome -> current status.

An event should not disappear simply because it is no longer in the latest top window.

This persistence is required for user trust, historical comparison, search visibility, and later model calibration.

Blackdeck Phase B3: separate three kinds of numbers

Blackdeck should clearly separate observed quantity, conditional scenario, and causal attribution.

Observed quantity means something measured by an external source: vessel count, throughput, inventory, capacity, price, or reported delay.

Conditional scenario means a calculation based on explicit assumptions. For example: baseline capacity multiplied by an assumed disruption rate and an assumed duration.

Causal attribution means how much of the observed change was specifically caused by the event. Blackdeck should not claim this unless the evidence is sufficient.

This distinction allows the product to become more quantitative without creating fake precision.

What comes later for Blackdeck

Once the first observable impact chain works, Blackdeck expands horizontally.

The preferred sequence is:

One route -> several routes -> commodities attached to those routes -> industrial nodes -> selected company exposures.

Not: all events -> all companies at once.

Later stages can add more operational datasets, calibrated pathway coefficients, observed disruption duration, substitution capacity, inventory buffers, route alternatives, stronger company exposure models, and historical outcome labels.

The existing taxonomy becomes more valuable at that point because it is connected to real observations.

The final Blackdeck product

The mature Blackdeck should answer:

What changed in the world, what real-world system is exposed, how has that system actually changed, how confident are we, and what should be watched next?

The mature flow is:

Event discovery -> event normalization -> taxonomy graph -> impact pathway -> observed operational data -> scenario / attribution boundary -> historical update trail -> current risk state.

The map remains. The taxonomy remains. The score remains. But all three become support layers around an evidence history.

3. ByteCosmos

What stays

ByteCosmos keeps the Upbit KRW universe. Crypto-only remains the initial scope. There is no reason to add stocks yet.

Canonical OHLCV stays as the research foundation. It should become deeper and cleaner over time, but the architecture is correct.

The SQL Research Lab stays. It is the internal model-development environment. It already supports data cleaning, feature engineering, filtering, ranking, joins, buy conditions, sell conditions, and historical evaluation.

There is no reason to replace it with RStudio unless a specific research need cannot be expressed safely.

Point-in-time validation also stays. Historical signals should be reconstructed using only the data available at that point.

The public dashboard stays, but its role becomes context rather than differentiation.

What changes now

The biggest missing piece is the bridge between Research and the public product.

Today the flow is effectively:

Private research -> result stays private.

The target flow is:

Private research -> frozen strategy version -> validation -> approved production signal -> current matching assets -> public timestamped record -> subsequent outcome -> cumulative signal quality.

That bridge is the next core ByteCosmos product.

What we do now: ByteCosmos Phase C1

Stop expanding the Research editor for now.

The Research Lab is already expressive enough for the next stage. The priority should be using it, not adding more controls.

The next step is to define a very small number of research hypotheses. Examples are breakout plus volume expansion, and volatility compression followed by expansion.

These are hypotheses, not assumed profitable strategies.

Each model should freeze:

• SQL feature pipeline
• buy expression
• sell expression
• eligible market universe
• fee assumption
• slippage assumption
• holding rule
• stop and target rules
• validation boundary

Once frozen, the version cannot silently change. A change creates a new version.

ByteCosmos Phase C2: improve historical data quality

The current history is sufficient for product development but still shallow for robust market research.

The next data work should include deeper daily history where available, completed-candle validation, duplicate detection, missing-candle treatment, per-market available-history metadata, daily universe snapshots from now forward, and clear survivorship-bias disclosure.

The goal is not simply more rows. The goal is knowing exactly what sample each model was tested on.

ByteCosmos Phase C3: create the production signal record

This is the most important next ByteCosmos feature.

When an approved model identifies a current candidate, ByteCosmos should create an immutable signal record containing:

• signal ID
• model version
• asset
• signal time
• condition values
• reference price
• public timestamp

After publication, the system should track later outcomes such as +1, +3, +5, and +10 bars, drawdown, maximum favorable excursion, exit condition, and the realized observation under the model rules.

The signal record should not be rewritten after the outcome is known. Corrections should be explicit corrections, not silent replacements.

This accumulated forward record becomes the real long-term ByteCosmos asset.

ByteCosmos Phase C4: make Setups the public output of Research

The public Setups page should become the bridge from private research to public value.

It should show:

• currently active candidates
• which frozen model produced each candidate
• why the condition is active
• historical sample statistics
• execution assumptions
• signal timestamp
• post-publication tracking

The public user does not need the full SQL. The user needs the result, the rule definition, the evidence, and the limitations.

What comes later for ByteCosmos

After a few models accumulate real forward records, ByteCosmos can add walk-forward evaluation, sealed blind evaluation sets, historical universe reconstruction, model comparison, regime-specific performance, theme-level signal aggregation, and model retirement rules.

Only then should more complex model families be added.

Possible later extensions include intraday context, additional exchanges, portfolio allocation, short-side semantics, and eventually execution integration.

Live trading should remain much later. The system should first prove that its signal records are useful before it is allowed to place orders.

The final ByteCosmos product

The mature ByteCosmos should answer:

What market condition is present now, which assets satisfy a previously defined model, how did this exact model behave historically, and how have its publicly timestamped signals performed since publication?

The mature flow is:

Market data -> features -> research -> frozen model -> historical validation -> current signal -> public setup -> forward result -> cumulative signal quality -> model lifecycle.

The dashboard remains. The Research Lab remains. But the accumulated signal history becomes the product asset.

4. The roadmap by horizon

Horizon 0: keep the foundation

No large rewrite.

Blackdeck keeps ingestion, clustering, taxonomy, map, pathway model, screening score, and evidence model.

ByteCosmos keeps Upbit scope, OHLCV, dashboard, SQL Research, point-in-time validation, and the isolated sandbox.

This horizon is mostly complete.

Horizon 1: build the missing public value loop

This is the work that should happen next.

For Blackdeck: choose one observable impact domain, connect one reliable operational dataset, make event pages persistent, show baseline versus observed change, and maintain an evidence/update history.

For ByteCosmos: select a small number of research hypotheses, freeze model versions, improve historical data coverage and metadata, generate production signals from approved models, timestamp them publicly, and track subsequent outcomes.

This is the highest-priority horizon.

Horizon 2: expand only what proves useful

After the first loops work, Blackdeck expands from one route to several routes, then commodities, industrial nodes, and selected company exposure.

ByteCosmos expands from a few models to more validated models, regimes, themes, and model comparison.

Expansion should follow evidence of usefulness, not precede it.

Horizon 3: mature intelligence products

The long-term Blackdeck is a durable global event-to-real-world-impact intelligence graph with observed outcomes and historical revisions.

The long-term ByteCosmos is a versioned market-model system with transparent research, current signals, and a long forward performance record.

At that stage, both products become less dependent on generic dashboards. Their accumulated histories become the moat.

5. What should not be built next

For Blackdeck, do not add more arbitrary risk scores, fake precision for company losses, blanket event-to-commodity mappings, taxonomy for its own sake, or any model that treats news frequency as physical impact.

For ByteCosmos, do not add more generic indicators to the public dashboard, expose the Research sandbox to everyone, create dozens of unvalidated strategies, call repeatedly inspected holdout data a blind test, add live order execution, or add stocks.

Those changes would increase surface area without solving the current product gap.

6. How success should be judged

Blackdeck succeeds in the next phase when one persistent event page can show what was initially believed, what new evidence appeared, what observable metric changed, how the assessment changed, and what remains unknown.

ByteCosmos succeeds in the next phase when one frozen model can show when its signal was generated, which asset matched it, that the signal record was not rewritten afterward, what happened after publication, and how the cumulative forward record is changing.

This is a different standard from saying that a page was deployed.

7. The final distinction

The architecture is not being replaced. The role of each component is being clarified.

For Blackdeck:

Taxonomy is infrastructure. Map is navigation. Screening score is prioritization. Observed change history is the product.

For ByteCosmos:

Dashboard is context. Research is the laboratory. Model version is the specification. Public signal history is the product.

That is the main change in direction.

The systems already exist. Now they need to accumulate evidence, not merely features.