<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Muhail01</title>
    <description>The latest articles on DEV Community by Muhail01 (@muhail01).</description>
    <link>https://dev.to/muhail01</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4042643%2F99ee7b4c-a9f1-4cad-9301-d2119abe662c.jpg</url>
      <title>DEV Community: Muhail01</title>
      <link>https://dev.to/muhail01</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/muhail01"/>
    <language>en</language>
    <item>
      <title>GMF Core: an open-source recommendation and decisioning engine for marketplaces</title>
      <dc:creator>Muhail01</dc:creator>
      <pubDate>Wed, 22 Jul 2026 20:25:47 +0000</pubDate>
      <link>https://dev.to/muhail01/gmf-core-an-open-source-recommendation-and-decisioning-engine-for-marketplaces-4jon</link>
      <guid>https://dev.to/muhail01/gmf-core-an-open-source-recommendation-and-decisioning-engine-for-marketplaces-4jon</guid>
      <description>&lt;p&gt;While building &lt;strong&gt;GILLZY&lt;/strong&gt;, a digital goods marketplace, I ended up working on a problem that appears in almost every sufficiently large marketplace:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;How do you turn behavioral events and catalog candidates into explainable, safe, and reproducible recommendation decisions?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;At first, recommendation logic tends to be simple.&lt;/p&gt;

&lt;p&gt;Fetch some products.&lt;br&gt;&lt;br&gt;
Calculate a score.&lt;br&gt;&lt;br&gt;
Sort them.&lt;br&gt;&lt;br&gt;
Return the top N.&lt;/p&gt;

&lt;p&gt;But as a marketplace grows, the pipeline quickly becomes more complicated:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;multiple candidate sources;&lt;/li&gt;
&lt;li&gt;feature signals;&lt;/li&gt;
&lt;li&gt;deterministic ranking;&lt;/li&gt;
&lt;li&gt;model-assisted scoring;&lt;/li&gt;
&lt;li&gt;diversity constraints;&lt;/li&gt;
&lt;li&gt;business and safety guardrails;&lt;/li&gt;
&lt;li&gt;exploration;&lt;/li&gt;
&lt;li&gt;fallbacks;&lt;/li&gt;
&lt;li&gt;telemetry attribution;&lt;/li&gt;
&lt;li&gt;explainability;&lt;/li&gt;
&lt;li&gt;experimentation.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;The problem is that these systems often become tightly coupled to one product and one private database schema.&lt;/p&gt;

&lt;p&gt;So I extracted the reusable parts into an independent Apache-2.0 open-source project:&lt;/p&gt;
&lt;h1&gt;
  
  
  GMF Core
&lt;/h1&gt;

&lt;p&gt;&lt;strong&gt;GMF Core is an open-source recommendation&lt;/strong&gt;, ranking, telemetry, and decisioning engine designed for marketplaces and discovery products.&lt;/p&gt;

&lt;p&gt;GitHub:&lt;br&gt;&lt;br&gt;
&lt;a href="https://github.com/Muhail01/GMF-Core" rel="noopener noreferrer"&gt;https://github.com/Muhail01/GMF-Core&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Current release: &lt;strong&gt;v0.1.0&lt;/strong&gt;&lt;/p&gt;


&lt;h2&gt;
  
  
  The pipeline
&lt;/h2&gt;


&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;Event Ingest
    ↓
Candidate Providers
    ↓
Feature Signals
    ↓
Deterministic Baseline Ranking
    ↓
Optional Model Scoring
    ↓
Diversity Rerank
    ↓
Policy / Guardrails
    ↓
Controlled Exploration
    ↓
Explainable Decision
    ↓
Decision Log + Transactional Outbox
    ↓
Impression / Click / Outcome Telemetry

The core idea is that a recommendation should not be treated as just a sorted list.

It is a decision.

**Every response gets a stable decision_id,** which allows downstream impression, click, and outcome events to be connected back to the exact decision that produced the result.

What is included in v0.1.0

The current release already includes:

standalone Go API;
pluggable candidate providers;
deterministic weighted ranking;
stable tie-breaking;
optional model-assisted scoring;
deterministic model rollout;
automatic fallback to baseline ranking;
diversity-aware reranking;
policy and guardrails;
controlled exploration;
explainable score breakdowns;
persisted decision lookup;
PostgreSQL storage;
in-memory storage;
transactional outbox;
reference outbox worker;
idempotent telemetry ingestion;
TypeScript telemetry SDK;
OpenAPI 3.1;
Docker Compose;
property and fuzz tests;
benchmarks;
privacy-safe observability hooks;
automated CI and public-boundary checks.

**The project intentionally does not contain private marketplace data**, production ranking coefficients, fraud logic, payment systems, KYC, paid advertising billing, credentials, or proprietary model configuration.

The public core is vendor-neutral.

Run the full stack

The reference stack includes GMF Core, PostgreSQL, and the outbox worker.

git clone https://github.com/Muhail01/GMF-Core.git
cd GMF-Core

docker compose up --build

Check that the API is alive:

curl -s http://localhost:8080/healthz

Request recommendations:

curl -s -X POST http://localhost:8080/v1/recommendations \
  -H 'Content-Type: application/json' \
  -d '{
    "surface":"home",
    "session_id":"demo-session",
    "limit":4,
    "context":{"category":"games"}
  }'

The response contains a decision_id, ranked items, scores, reason codes, and score breakdowns.

You can then retrieve the persisted decision:

curl -s http://localhost:8080/v1/decisions/&amp;lt;decision-id&amp;gt;

And send telemetry linked to that exact decision:

curl -s -X POST http://localhost:8080/v1/events \
  -H 'Content-Type: application/json' \
  -d '{
    "event_id":"evt-1",
    "event_type":"recommendation_impression",
    "session_id":"demo-session",
    "decision_id":"&amp;lt;decision-id&amp;gt;",
    "item_id":"game-1",
    "surface":"home"
  }'

This gives you a full chain:

**recommendation request**
→ decision
→ ranked items
→ score breakdown
→ persisted decision
→ impression
→ click
→ outcome
Why deterministic ranking still matters

One design decision I wanted to preserve is that the system must remain useful even without an external model.

The baseline ranking path is deterministic.

Optional model scoring can be enabled on top of it, but model failure does not make the recommendation system unavailable.

The intended behavior is:

baseline ranking
        ↓
optional model scorer
        ↓
model available? ── yes → hybrid result
        │
        no
        ↓
safe baseline fallback

This makes it possible to experiment with learned ranking without turning the model provider into a single point of failure.

Explainability

Each returned item can include a score breakdown and reason code.

Instead of returning only:

item A
item B
item C

the system can preserve information about why those items were selected and how the final ranking was produced.

That becomes useful for:

debugging;
experiments;
model comparison;
ranking regressions;
policy analysis;
telemetry attribution.
Transactional outbox

**Decisions and telemetry** events can be persisted together with outbox messages.

The reference worker is intentionally provider-neutral.

A deployment can connect it to systems such as:

Kafka;
NATS;
webhooks;
queues;
analytical pipelines.

The core itself does not require one specific messaging vendor.

What I am looking for now

The project is still early, and I would especially appreciate technical feedback on:

the decision pipeline;
API boundaries;
ranking and reranking abstractions;
model fallback semantics;
feature-store integration;
telemetry contracts;
transactional outbox design;
observability.

I have also opened contribution-sized issues for things such as:

Go client SDK;
Python SDK;
React telemetry hooks;
Redis decision cache;
Prometheus integration;
OpenTelemetry integration;
Kafka outbox sink;
NATS outbox sink;
ClickHouse telemetry storage;
feature-store provider interface;
benchmark documentation.

Some are intentionally marked as good first issue so that contributors do not need to understand an entire marketplace codebase before making a useful first contribution.

Repository

⭐ GMF Core:

&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;


&lt;p&gt;&lt;code&gt;https://github.com/Muhail01/GMF-Core&lt;br&gt;
&lt;/code&gt;&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;


**The project is licensed under Apache-2.0.**

I am particularly interested in criticism from people who have worked on recommendation systems, ranking infrastructure, marketplaces, experimentation platforms, or large-scale telemetry systems.

What would you change in this architecture before building a v0.2?
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

</description>
      <category>opensource</category>
      <category>go</category>
      <category>backend</category>
      <category>machinelearning</category>
    </item>
  </channel>
</rss>
