The question
Whether the decision-maker is an individual investor, a fund analyst, a housing non-profit, or a municipal planner, property decisions look the same on paper: combine a set of signals that don’t naturally compare and produce one number that someone has to act on.
A walkability index is a 0–100 lifestyle score. A crime rate is incidents per 1,000 residents. Rental demand is a market signal expressed in days-on-market or median rent delta. School quality is categorical. Affordability is a ratio. Growth is a trend line. None of these live on the same axis — and yet they all feed the same decision.
Blunt averaging hides the trade-offs. Ad-hoc spreadsheet judgment doesn’t scale or explain itself a year later. A black-box ML model trains on the past and obscures the policy — which is exactly the part a stakeholder needs to see.
What people actually need is a system where the inputs are visible, the weighting is a policy decision rather than a guess, and the recommendation can be defended in a meeting.
The approach
Multi-source weighted scoring with transparent inputs. The system pulls independent signals from a set of named sources, normalizes each to a comparable 0–100 scale, applies configurable weights that encode what the decision-maker actually cares about, and outputs both a composite score and a thresholded recommendation.
Critically, this is not a model in the machine-learning sense. There is no training set, no fitted parameters, no inference step you can’t read. It’s a policy expressed in code — which makes it auditable, tunable, and portable across stakeholders with different priorities.
Why a policy, not a model
- Explainable. Every output traces back to inputs. There’s no “the model said so.”
- Auditable. The weights live in version-controlled config. You can see exactly what was prioritized, and when it changed.
- Tunable per stakeholder. Same inputs, different weights. An investor’s weights aren’t a housing non-profit’s weights, and the system should reflect that without re-engineering.
- Defensible. For regulated or public-facing decisions, transparency outranks marginal accuracy. A policy you can show beats a model you can’t.
The architecture
The system is built from small, named components — each with one job, each replaceable.
Source adapters handle one external signal each — rate-limited, cached, and tolerant of partial data. Normalizers convert raw values to a 0–100 scale using domain-specific scaling (a $400/mo rent delta and a 12-point walk-score delta have to become commensurable). The scoring engine assembles a composite score from the normalized inputs and the weighting layer, which reads from a versioned config file. The decision band maps the composite score to an action: BUY, HOLD, or PASS.
The seven signals
For the property-investment configuration, the system tracks:
These weights are an answer to the question “what should the investor prioritize?” — not the answer. The point of the weighting layer is that the same engine can serve a buyer focused on cash flow, a buyer focused on appreciation, or a housing analyst focused on affordability — by editing one file.
Key design choices
-
Weights as policy, not as model parameters.
The weights live in a versioned config file that a non-engineer can read. When a stakeholder asks “why did we recommend this property?”, the answer is the inputs and the weights — both of which are visible. This is the single most important decision in the system. It’s what makes the output defensible. -
Configuration over coding.
Adding a new factor — flood risk, climate exposure, tax burden — requires writing a source adapter and a normalizer, then adding one line to the weights file. No retraining, no model versioning, no statistical justification needed. The system grows with the decision-maker’s understanding of the problem. -
Graceful fallback on data quality.
Real-world data is missing. ZIP-level data isn’t always available; city-level often is. The system falls back along a defined hierarchy and marks the output with a confidence score so a downstream reviewer knows when to look closer. The default is never silently fabricated — if a signal is unavailable, the system says so. -
Decision bands, not raw scores.
People don’t act on “73.4.” They act on “this is a BUY.” The decision layer commits the system to a recommendation, which forces honesty: if your bands are wrong, the system makes obviously wrong calls. If your bands are right, you have a usable workflow. Either way, the failure mode is visible — which is exactly what you want from a decision-support tool.
What this demonstrates
The property-scoring example is small enough to fit in one writeup, but the pattern is how Neptari approaches decision intelligence problems generally:
- Treat data signals as inputs to a policy, not as ground truth.
- Make the policy explicit, versioned, and tunable.
- Trace every decision back to its inputs, with a stated confidence.
- Build for the stakeholder’s workflow, not the algorithm’s elegance.
The same architecture pattern fits problems that look very different on the surface:
- Vendor risk scoring — compliance, financial health, operational continuity, and security signals weighted into an approve / review / decline recommendation, with a clear audit trail.
- Grant funding prioritization — impact, alignment, organizational capacity, and risk weighted into a fund / hold / decline decision, with reviewer confidence per criterion.
- Site selection — demographics, infrastructure, regulatory environment, and competitive density combined into a ranked candidate list, with weights set by the strategic priority of the project.
- Loan underwriting policy — credit, capacity, collateral, and conduct signals combined into an approve / review / decline recommendation, with every decision auditable on demand.
In each case the underlying principle is the same: multiple signals, weighted by an explicit policy, with transparent reasoning the stakeholder can defend.
What’s honest about this
A few things worth saying directly. This piece describes a methodology and a system architecture, not a deployed customer engagement. The property-scoring system the architecture is drawn from is in active development — some source adapters are live, others are stubbed pending data-source selection against budget and reliability constraints.
A production deployment for any specific stakeholder would involve a data-source selection workshop, weight calibration with subject-matter experts, integration with existing systems of record, and a thin analytics layer for ongoing decision review. Those steps are part of the engagement, not skipped over.
The reason this writeup exists at all is that the thinking — multi-source, weighted, explainable, defensible — is portable. The data sources change. The architecture doesn’t.