What we built above the standard techniques.
This tier documents system-level architecture developed by Tech-Enabled Capital. Each page describes the architectural class of problem and the capability we built to address it — not the engineering methodology required to reproduce it.
Two different claims, kept apart on purpose.
Technical Capabilities documents established engineering methods we know how to use well — retrieval, entity resolution, evaluation, quantization, orchestration, permission scoping. Those are industry techniques with public literature behind them. We did not invent them and we do not claim to. Listing them is a statement about competence and about deliberate tool selection, not about authorship.
This tier is the other claim. It describes architecture we developed above and across those primitives: the systems that make a set of individually well-understood components behave coherently against one real company’s messy, contradictory, decade-old operating record.
The distinction matters because the hard part of this work is not any single technique. Retrieval and identity resolution are mature technique classes with decades of public literature behind them; neither is finished as a research problem, and neither is ours. Making them agree with each other — over years of changing organizational reality, across systems that disagree, while preserving what is unknown rather than filling it in — is where the engineering actually lives, and that is what these seventeen pages describe.
The capability, not the recipe.
Each page states the problem class, what we developed, and what the architecture is designed to maintain. Each one also carries an explicit boundary section naming the established technique class it is built above — because the useful analogy is that a restaurant can explain its techniques without publishing the recipe, and because a reader who arrives at one of these pages directly should not have to come here to learn where the industry’s work ends and ours begins.
So these pages do not disclose prompts, routing thresholds, model-selection weights, internal evaluation sets, proprietary schemas, the complete ontology, deployment topology or orchestration logic. A technically competent reader should finish a page able to judge whether the problem is real and whether we understand it — not able to rebuild the system. That is deliberate, and it is the same standard applied across all seventeen.