A recent EVE Frontier UI surfaced a phrase players immediately wanted to decode: System Resource Potential. The labels around it suggest resource categories such as transient mass, composition, and crude umbra. EF-Map cannot confirm the official formula behind that UI, but we can compare the wording with the extended solar system database that EF-Map already inventories.
Scope first
This is a database-grounded hypothesis, not an official CCP explanation and not proof that EF-Map's current production database is the source for the UI. The system name shown in the shared discussion, 043-MCJ, is not present in the current public map database checked for this article, which makes a dev, test, future, or separate data path plausible.
What EF-Map actually has
The useful context is the extended FrontierData solar system database. The inspected 2026-05-29 output contains 24,426 solar systems, 24,026 stars, 230,317 planets and moons, 416,285 Lagrange points, 87,381 landscape zones, 122,951 landscape sites, and 359,342 landscape tags.
At the system level it includes fields such as frost_line, habitable_zone_inner, habitable_zone_outer, remnant_dust_mass, remnant_gas_mass, potential, and system_radius. At the body level it includes type descriptions, temperature, density, pressure, surface gravity, escape velocity, orbital values, and mass-like fields named mass_dust and mass_gas.
The landscape layer adds asteroid belt and trojan zones, ecosystem families, generated sites, site counts, and tags such as belt, trojan, inner, outer, outer_icy, and non_zero_danger_level.
What EF-Map does not have
The inspected schema does not contain explicit columns named resource, fuel, or mineral. That matters. Gas and dust mass fields look resource-like, and landscape sites look exploration-relevant, but the database does not label them as player-facing resource pools.
There are also optional compatibility fields in the TypeScript loader, including life, locked, and fragmented. Those are supported defensively for legacy or future schemas, but they are not present as columns in the inspected database.
Why the word potential is interesting
The strongest named overlap is the system-level potential column. In the inspected DB it is present for all 24,426 system rows and ranges from 0 to 1. That sounds temptingly close to System Resource Potential, but it is not enough to call it a match.
It could be a generation scalar, a normalized derived value, an input to another formula, or a value that happens to share a similar word. The safe statement is narrower: EF-Map has a normalized system-level field named potential, and any future comparison with official UI values should start there.
Candidate signals behind resource buckets
If System Resource Potential is computed from static universe data, the EF-Map inventory points to a few plausible families of inputs.
- Transient mass: System-level
remnant_dust_massandremnant_gas_mass, plus body-levelmass_dustandmass_gas, are the closest matches by name and shape. - Composition: Planet and moon
type_description, density, pressure, mass ratios, star metallicity, and ecosystem or landscape tags could all feed a composition-style summary. - Crude umbra: There is no obvious
crudeorumbrafield in the inspected schema. If this bucket is real gameplay data, it may be derived, stored elsewhere, hidden behind another naming layer, or absent from the static DB EF-Map currently inventories. - Overall potential: The
systems.potentialcolumn is the obvious first field to test against, but it needs validation against known UI values before anyone treats it as the answer.
Where landscape data may fit
The landscape tables are easy to underestimate because they do not say "resource" on the tin. They describe generated zones and sites: asteroid belts, trojans, ecosystem families, tag sets, site counts, and distance from star. If a resource UI is meant to summarize where valuable site types can appear, this layer is at least as interesting as the planet table.
That is why System Finder already exposes orbital-zone and landscape signals. It can filter real database fields such as asteroid belt and trojan presence without pretending those fields are confirmed resource yields.
How EF-Map uses this database today
EF-Map already uses this data in practical tools. Solar System View renders stars, planets, moons, Lagrange points, frost lines, habitable-zone boundaries, landscape sites, and orbital-zone context. Hover cards use star class, temperature, luminosity, radius, age, planet temperature, pressure, gravity, orbit values, and zone chips.
The map also uses this database for System Finder star filters, planet and moon type filters, moon counts, stargate counts, orbital-zone counts, landscape summaries, and human-habitability flags. That is enough to make EF-Map a useful research surface, but it is still not a resource oracle.
The caveats scouts should keep
There are three big caveats. First, static client-derived data is not the same thing as live server truth. Second, a future EVE Frontier universe update could change IDs, values, generation rules, or derived scores. Third, UI labels may be backed by a service or a newer data file that EF-Map has not seen yet.
This is the same reason our dual database pipeline keeps extraction and validation steps separate. We can inventory what exists, compare it against observed behavior, and publish new filters when the semantics are defensible.
Practical takeaway
If you are trying to reason about System Resource Potential today, treat EF-Map's extended database as a clue set. The best candidates are systems.potential, remnant gas and dust mass, body gas and dust mass, density, star metallicity, and the landscape zone/site layer. The weakest candidate, based on the inspected schema, is anything that assumes explicit crude, fuel, mineral, or resource columns already exist.
The next useful step is comparison, not certainty. If players collect enough official UI examples for known public systems, EF-Map can test whether those values correlate with the static fields above. Until then, the honest answer is that the database has several plausible signals and one especially suggestive column name, but no confirmed decoder for the EVE Frontier UI.