A decision engine for consumer platforms, delivered as one API call.
Gortex is a real-time decision engine API. One POST /v1/decide call scores the candidates
a platform already retrieved, returns the order one recipient should see, places sponsored slots inside that same
order, and hands back a decision ID that explains it, in under 200ms p99. No decisioning engine to build in-house.
No rules file nobody owns.
What a decision engine does: picks, places and proves, per request.
A decision engine takes context and a set of options at request time and returns the choice to serve. For a consumer platform the choice is an order: which posts, profiles, listings or jobs go where, and which slots are worth selling. Gortex resolves all three parts of that decision (relevance, monetization and rationale) in one synchronous response instead of three systems.
Every ranked surface already runs a decision engine. Usually an accidental one.
The accidental version is a SQL sort, a weights file and a growing pile of special cases. It works until the surface matters commercially, then four costs land at once.
Four stages, one synchronous decision.
The architecture is published rather than implied, so a platform architect can review the hot path before writing a line of integration code.
Rules encode last year's judgement. A decision engine scores now.
| rules engine | decisioning engine |
|---|---|
| Human-written conditions, evaluated in order | Every candidate scored per request, per recipient |
| Outcomes as good as the last person to edit the weights | One comparable scale across organic and sponsored |
| Relevance and revenue live in separate branches | Placement priced by opportunity cost, not priority flags |
| Explanation means reading the file | Explanation returned with the response as a decision ID |
| Cost of change grows with every exception | New goals become inputs instead of new branches |
Rules stay useful for policy: eligibility, compliance, hard exclusions. The decision engine handles everything downstream of policy, where the question stops being “is this allowed” and becomes “what is this worth to this recipient right now”.
One real-time decision API, five entry points.
Ranking is the most common entry point: the same engine is documented surface-by-surface on the ranking API page.
For platforms with a ranking surface and no ranking team.
| a fit | not a fit |
|---|---|
| Seed to Series B consumer platforms, roughly 5 to 100 engineers | Catalog-first retail e-commerce |
| CTOs and platform architects owning a live ranked surface | Teams needing an ad network to supply advertiser demand |
| Social feeds, creator platforms, dating apps, marketplaces, job boards, delivery | Pre-PMF apps with no interaction volume to decide on |
| Teams that outgrew hand-tuned sorting with no data science hire budgeted | Anyone who needs a live real-time auction this quarter |
| Surfaces where sponsored placement is already on the roadmap | On-prem or air-gapped deployments |
The job being hired for stays narrow: ship a personalized surface that also earns revenue, without funding a decisioning engine build.
Most vendors solve half a decision. This one returns all of it.
Start in shadow mode. Deepen when numbers justify it.
A published integration ladder replaces the usual up-front commitment. Every level is opt-in and reversible.
Roadmap is dated, not implied: real-time auction Q1 2027, learned ranker mid-2027, agent-to-agent decision levels L4 to L7 from 2027.
Decision moves, roadmap stays.
Adopting a hosted decisioning engine is a scope decision before it is a technical one. These are the concrete shifts a platform team plans around.
Claims a technical buyer can check before requesting access.
Decision engine questions, answered in one line each.
What is a decision engine?
A system that takes context plus options at request time and returns the choice to serve. Here, that is a ranked and monetized order with a trace.
Does retrieval have to move?
No. Candidate generation, storage and identity stay in place; the engine receives candidates and returns the decision.
Is it fast enough for a live feed?
Sub-200ms p99 in beta on the single decide call, which is the bar a real-time decision API has to clear in the hot path.
Can a decision be explained later?
Yes. Each response carries a decision ID that resolves to the rationale behind every organic and sponsored placement.
How does a beta start?
Access is invite-only. Integrating during beta also means shaping the Q1 2027 auction design rather than inheriting a finished one.
Put a decision engine in your hot path without betting a quarter on it.
Beta seats go to consumer platforms with a live ranking surface. Requesting access returns the OpenAPI spec, an SDK key, and a shadow-mode integration that compares Gortex decisions against the current sort before anything reaches users.