Document type: Technical specification
This page is the technical specification for the Deeprank Profile format. For the reasoning behind these design decisions, see the Methodology page.
Overview
Purpose
A Deeprank Profile provides a structured format for expressing business identity, capability, and fit boundaries. It is designed to supplement (not replace) existing structured data formats like Schema.org by adding selection-specific declarations.
The profile format contains six layers. The specification is stable and published, providing value for clarity and consistency independent of current platform integration.
Six Mandatory Layers
1. Identity - Who you are
2. Problem Declaration - What problem you solve
3. Capability - How you solve it
4. Fit Conditions - Who you serve
5. Non-Fit / Exclusions - Who you do not serve
6. Stability / Confidence - How reliable this information is
Identity Layer
Definition
The Identity layer establishes who the business is. It includes the business name, entity type classification, and optional domain for verification.
Required Fields
name (string): Legal or operating name of the business.entity_type (string): Standardized business type classification.
Optional Fields
domain (string): Primary web domain for cross-reference verification.
Generic Entity Types
Avoid generic entity types like "company" or "business." Use specific classifications from the controlled vocabulary: "law-firm," "accounting-practice," "marketing-agency," "plumbing-contractor."
Problem Declaration Layer
Definition
The Problem Declaration layer states what category of problems the business solves. It maps to user intent in selection queries.
Required Fields
problem_class (string): Standardized problem category from controlled vocabulary.description (string): Human-readable summary of the problem space addressed.
Problem Class Specificity
Problem classes should be specific enough to enable accurate matching. "legal" is too broad. "legal-immigration" is better. "legal-immigration-employment" is appropriately specific for a firm that only handles employment-based cases.
Vague Descriptions
Descriptions like "we solve business problems" or "helping companies succeed" provide no information for selection. Descriptions must state the specific problem domain: "Employment-based immigration law for technology companies."
Capability Layer
Definition
The Capability layer declares specific things the business can do to solve problems within its problem class. Capabilities are expressed as standardized labels and specific methods.
Required Fields
labels (array of strings): Standardized capability labels from controlled vocabulary.
Optional Fields
methods (array of strings): Specific approaches, tools, or processes used.
Capability Inflation
Listing capabilities the business does not actually have or cannot deliver well leads to bad-fit selections. Only declare capabilities the business can reliably perform.
Fit Conditions Layer
Definition
The Fit Conditions layer declares what constraints the business can satisfy and what customer types it serves. This enables positive matching on selection queries.
Available Fields
geographic (array of strings): Locations served.customer_type (array of strings): Types of customers served.constraints (array of strings): Other conditions the business can satisfy.
Over-Inclusive Fit
Declaring fit conditions broader than actual capacity ("we serve anyone") leads to bad matches. A business that primarily serves enterprise clients should not claim to serve solopreneurs just to increase potential leads.
Non-Fit / Exclusions Layer
Definition
The Non-Fit layer declares explicit exclusions: work the business does not do, cannot do, or will not do. This enables AI systems to filter the business out of inappropriate selections.
Required Fields
exclusions (array of strings): Explicit declarations of what the business does not handle.
Missing Exclusions
Without explicit exclusions, AI systems may infer capabilities based on related work. An immigration attorney who does not declare "no asylum cases" may be selected for asylum queries because immigration is the problem class.
Exclusion Best Practice
List all significant types of work within your problem class that you do not handle. For every capability label you do not declare, consider whether it should be an explicit exclusion.
Stability / Confidence Layer
Definition
The Stability layer provides metadata about information reliability. These fields are self-declared and non-authoritative until externally verified. They signal the business's intent to maintain accuracy.
Required Fields
confidence (enum): Self-assessed confidence level: "high," "medium," or "low." Note: this is self-reported and carries no external authority.
Optional Fields
last_verified (date string): Date when the profile was last reviewed for accuracy.
Stale Information
Profiles without recent verification dates may be treated as potentially outdated. Regular review of profile accuracy is recommended even though no external system currently enforces verification.
Minimal Example
The following is a complete Deeprank Profile for an employment immigration law firm. This example demonstrates all six required layers.
{
"identity": {
"name": "Acme Immigration Law",
"entity_type": "law-firm",
"domain": "acme-immigration.com"
},
"problem_declaration": {
"problem_class": "legal-immigration-employment",
"description": "Employment-based immigration law for technology companies sponsoring foreign workers"
},
"capability": {
"labels": [
"h1b-visa",
"green-card-eb",
"perm-labor-certification"
],
"methods": [
"H-1B petition filing",
"PERM labor certification",
"EB-2/EB-3 green card processing",
"RFE response preparation"
]
},
"fit_conditions": {
"geographic": [
"United States"
],
"customer_type": [
"technology-company",
"employer-sponsor"
],
"constraints": [
"employer-sponsored-only",
"corporate-clients-only"
]
},
"non_fit": {
"exclusions": [
"family-immigration",
"asylum",
"deportation-defense",
"individual-self-petition",
"non-employment-visa"
]
},
"stability": {
"confidence": "high",
"last_verified": "2024-01-15"
}
}Schema Reference
Field Summary
| Layer | Field | Type | Required |
|---|---|---|---|
| identity | name | string | Yes |
| identity | entity_type | string | Yes |
| identity | domain | string | No |
| problem_declaration | problem_class | string | Yes |
| problem_declaration | description | string | Yes |
| capability | labels | string[] | Yes |
| capability | methods | string[] | No |
| fit_conditions | geographic | string[] | No |
| fit_conditions | customer_type | string[] | No |
| fit_conditions | constraints | string[] | No |
| non_fit | exclusions | string[] | Yes |
| stability | confidence | enum | Yes |
| stability | last_verified | date | No |
Full JSON Schema and controlled vocabulary files are available on the Reference page.