The Stable Marriage Problem is a classic matching algorithm that finds a bijective mapping between two equally sized sets where no two elements would mutually prefer each other over their current assigned partners. In ontology alignment, it resolves cardinality constraints by treating source and target entities as two sets with similarity scores as preference lists, ensuring a globally optimal one-to-one correspondence.
Glossary
Stable Marriage Problem

What is Stable Marriage Problem?
An algorithmic solution applied to ontology matching that finds a stable one-to-one mapping between two sets of entities based on mutual preference scores, optimizing global alignment cardinality.
The algorithm iteratively proposes matches based on ranked preferences, eliminating unstable pairs where a source entity ranks a target higher than its current match and that target reciprocates the higher ranking. This guarantees a Pareto-optimal alignment free from logical inconsistencies, making it essential for strict 1:1 ontology merging scenarios where ambiguous or overlapping mappings must be resolved deterministically.
Key Characteristics of Stable Marriage Matching
The Gale-Shapley algorithm guarantees a stable, globally optimal one-to-one mapping between two sets of entities based on mutual preference scores, making it ideal for ontology alignment cardinality constraints.
Guaranteed Stability
The algorithm's core property ensures that no blocking pair exists in the final matching. A blocking pair consists of two unmatched entities that would both prefer each other over their current assigned partners. This prevents logical inconsistencies in merged ontologies where a concept from Ontology A would rather map to a different concept in Ontology B than its current alignment, eliminating semantic drift and ensuring the merged knowledge graph remains coherent under reasoning.
Deferred Acceptance Mechanism
The Gale-Shapley algorithm operates through an iterative proposal and provisional acceptance cycle:
- Proposers (e.g., source ontology entities) propose to their highest-ranked candidate that hasn't rejected them yet
- Receivers (e.g., target ontology entities) provisionally accept the best proposal received so far, rejecting previous engagements if a better match arrives
- This deferred decision-making prevents premature commitment to suboptimal alignments and guarantees convergence in O(n²) time complexity
Proposer-Optimality Bias
The algorithm is asymmetric: the set that initiates proposals always receives their optimal stable matching, while the receiving set gets their pessimal stable outcome. In ontology alignment, this means the choice of which ontology acts as the proposer significantly impacts the final mapping. Source ontologies should typically be the proposers to ensure their concepts find the best possible matches. This property requires careful design consideration when aligning peer ontologies where neither should be privileged.
Cardinality-Constrained Matching
Unlike unconstrained similarity scoring, stable marriage enforces one-to-one mapping by design. This is critical for ontology alignment scenarios requiring:
- Functional properties: Each source class maps to exactly one target class
- Inverse functional constraints: Each target class receives at most one source mapping
- Global consistency: Prevents multiple source concepts from collapsing into a single target, preserving the distinctness of ontological categories and avoiding unintended equivalence assertions
Preference Score Construction
The algorithm requires a complete preference ordering for each entity, not just raw similarity scores. In ontology matching, these rankings are typically derived from:
- Lexical matchers: Edit distance, Jaccard coefficient on labels
- Structural similarity: Graph convolutional network embeddings comparing neighborhood topology
- Logical confidence: Weighted combinations of multiple matcher outputs
- The ranking transformation converts continuous similarity scores into strict ordinal preferences, which can amplify small differences into significant ordering changes
Resident-Hospital Extension
The classic Hospitals/Residents Problem variant extends stable marriage to handle many-to-one matchings where each target entity (hospital) can accept multiple source entities (residents) up to a defined capacity. This is directly applicable to ontology scenarios where a general concept subsumes multiple specific concepts, enabling controlled one-to-many cardinality while maintaining stability guarantees through capacity-constrained deferred acceptance.
Frequently Asked Questions
Explore the algorithmic foundations of the Stable Marriage Problem and its critical application in ontology alignment, where mutual preference scores drive optimal one-to-one mappings between heterogeneous knowledge graphs.
The Stable Marriage Problem is a classic algorithmic matching problem that finds a stable, one-to-one correspondence between two equally sized sets of elements based on their mutual preference rankings. A matching is considered 'stable' when no pair of unmatched elements would both prefer each other over their currently assigned partners. The seminal Gale-Shapley algorithm solves this in polynomial time by iteratively proposing and tentatively accepting matches. In ontology alignment, this translates to mapping classes from a source ontology to a target ontology where each entity ranks potential matches by a similarity confidence score, ensuring the final alignment is globally optimal and free from logical contradictions.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Stable Marriage vs. Other Matching Paradigms
A comparative analysis of the Gale-Shapley stable marriage algorithm against alternative matching paradigms used for mapping concepts between heterogeneous ontologies.
| Feature | Stable Marriage (Gale-Shapley) | Maximum Weight Bipartite Matching | Greedy Nearest-Neighbor Matching |
|---|---|---|---|
Primary Objective | Find a stable one-to-one mapping where no unmatched pair mutually prefers each other over their current assignments | Maximize the global sum of similarity scores across all matched pairs | Iteratively assign each source entity to its highest-scoring unmatched target entity |
Stability Guarantee | |||
Global Optimality | |||
Cardinality Constraint | One-to-one only | One-to-one only | One-to-one or one-to-many configurable |
Handles Asymmetric Preferences | |||
Computational Complexity | O(n²) | O(n³) with Hungarian algorithm | O(n² log n) |
Typical Alignment Coherence | High: avoids logical inconsistencies from conflicting cardinality | Moderate: may introduce unsatisfiable classes without repair | Low: frequently produces incoherent mappings requiring extensive repair |
Use Case | Ontology alignment requiring bidirectional consistency and logical satisfiability | Resource allocation and assignment problems with uniform cost functions | Rapid prototyping and initial candidate generation for large-scale matching |
Applications in Ontology Alignment Systems
The Stable Marriage Problem provides a foundational algorithmic framework for resolving one-to-one cardinality constraints in ontology matching, ensuring a globally optimal and logically consistent set of entity correspondences.
Core Algorithmic Mechanism
The algorithm finds a stable matching between two equally sized sets of elements, each with a ranked preference list for the other set. In ontology alignment, these sets are the classes or properties of two ontologies, and preferences are derived from similarity scores generated by lexical, structural, or embedding-based matchers. A matching is stable if no unmatched pair would mutually prefer each other over their current assigned partners, preventing logical inconsistencies in the final alignment.
Resolving Cardinality Constraints
Many ontology matchers produce a dense matrix of weighted correspondences, often suggesting multiple mappings for a single entity. The Stable Marriage algorithm enforces a strict one-to-one alignment cardinality, which is a common requirement for tasks like instance matching (linking owl:sameAs individuals) or schema merging. It selects the best global assignment from the similarity matrix, optimizing for mutual agreement rather than just local maximum similarity scores.
Preference List Generation
The quality of the final alignment is directly dependent on the input preference lists. These are constructed by sorting candidate matches for each entity based on a confidence value from a base matcher. Techniques include:
- Lexical Filtering: Using edit distance or Jaccard index on labels.
- Structural Scoring: Using Graph Convolutional Network (GCN) embeddings to compare neighborhood similarity.
- Composite Confidence: A weighted aggregation of multiple string, structural, and semantic similarity metrics.
Stability vs. Global Optimality
The classic Gale-Shapley algorithm guarantees a stable but not necessarily globally optimal matching. In ontology alignment, the goal is often to maximize the sum of global similarity scores. This transforms the problem into the Assignment Problem, solvable by the Hungarian algorithm. However, the Stable Marriage framework is preferred when the logical consistency of the alignment, defined by the absence of blocking pairs, is prioritized over pure aggregate similarity.
Application in Instance Matching
A primary use case is linking individuals across knowledge graphs. When matching entities in a source ABox to a target ABox, the algorithm ensures each real-world object is linked to at most one counterpart. This prevents the creation of logically inconsistent identity closures where an entity is transitively declared owl:sameAs two distinct entities in the target graph, which would violate the semantics of the equality property.
Integration with Alignment Repair
The output of a stable matching algorithm serves as a high-quality input for the alignment repair phase. By enforcing one-to-one mappings, it reduces the search space for logical reasoners like those used in LogMap. The reasoner then checks the proposed correspondences against the TBox axioms to detect and remove any mappings that cause unsatisfiable classes or violate the conservativity principle, ensuring the final alignment is both stable and logically coherent.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us