Why technology partner traits matter for vendorlock-in protection in 2026
In my experience working with U.S. P&C carriers between $500M and $5B GWP, the trait checklist a CIO uses to evaluate insurance technology partners determines whether the carrier will sign a 5-7 year partnership or sign up for a 5-7 year hostage situation. The difference is not visible on day one. It surfaces in years three through five, when the carrier wants to extend the platform to new products, integrate with new distribution channels, or eventually consider an exit. The traits the carrier failed to verify at signing become the traits that determine whether the exit is possible at all.
The vendor lock-in problem in insurance technology is not new. Carriers have been locked into legacy COBOL systems for 25-30 years because the original vendor disappeared, the documentation was inadequate, the data was in proprietary formats, and migration would have cost more than the next-best alternative. The pattern repeats in modern SaaS deployments when carriers sign multi-year contracts without verifying the exit terms, when they accept “trade secrets” clauses that prevent the carrier from understanding their own configuration, and when they assume that “open APIs” means actual data portability.
I run the company that has shipped 100+ insurance projects since 2006, and I review 40+ vendor RFP responses every year for mid-tier carriers. What I tell every Tom-level CTO who calls me about partner evaluation: “The five traits in most RFP scoring matrices are insurance domain depth, technical expertise, communication, long-term commitment, and adaptability. Those traits matter, but they do not protect you from vendor lock-in. You need three additional traits explicitly in the scoring matrix: IP ownership clarity, escrow and open source posture, and exit strategy contract clauses. Without those three, the partnership decision is being made on incomplete information.”
For mid-tier carriers specifically, the lock-in problem matters more than it does for enterprise carriers. A $10B+ carrier with 500 in-house engineers has the negotiating power to set exit terms, the budget to migrate if necessary, and the operational redundancy to survive vendor service interruption. A $1.5B mid-tier carrier with 80 in-house engineers has none of those buffers. The mid-tier carrier’s lock-in is structurally tighter because the alternatives are fewer and the migration cost is proportionally larger relative to IT budget.
This article is the vendor evaluation deep dive that pairs with our Pillar Main on legacy-to-modern modernization for U.S. carriers in 2026 and complements our Build vs Buy vs Partner decision framework. The Pillar Main covers the modernization strategy; the Build vs Buy framework covers the approach selection; this article covers the partner evaluation criteria once a carrier has decided to work with a vendor.
What does it mean to choose a good insurance technology partner?
Choosing a good insurance technology partner means selecting a vendor whose insurance domain expertise matches the carrier’s actual lines of business and regulatory profile, whose commercial model and architectural choices preserve the carrier’s optionality over a 5-7 year relationship, and whose contract terms allow the carrier to exit cleanly if the partnership stops working. The trait checklist is not the same as the feature checklist. Features change every release; partnership characteristics determine the relationship’s structural quality.
The 8 traits that actually matter
I have expanded the traditional 5-trait checklist to 8 traits because the additional 3 (IP ownership, escrow and open source posture, exit strategy contract clauses) address the vendor lock-in dimensions that the 5-trait list does not cover. Every trait belongs in the partner evaluation regardless of which approach the carrier picks - Buy enterprise, Buy mid-tier, or Partner co-development.
Why traits 3-8 are often missing from RFPs
In my experience, traits 3-8 are missing from 70-80% of insurance technology RFPs I review. The reason is structural: RFPs are written by procurement teams optimizing for the visible features and standard commercial terms; the lock-in dimensions are visible only after operating the platform for 18-36 months. By that point, the contract is signed, the implementation is mid-flight, and renegotiating exit terms is impossible.
The fix is to include all 8 traits in the RFP scoring matrix at the time of vendor selection, not after. This article walks through each trait, what to ask, and what specifically to look for in the vendor’s responses.
For the broader vendor selection decision (which approach to take - Build, Buy enterprise, Buy mid-tier, or Partner), our Build vs Buy vs Partner decision framework covers the prior strategic choice. This article assumes that choice has been made and focuses on evaluating the specific vendor.
Trait 1 (Insurance domain depth) and Trait 2 (Honest vendor positioning)
Trait 1: Insurance domain depth
Insurance domain depth is more specific than “the vendor understands insurance.” It means the vendor has built and operated platforms for carriers writing the specific lines of business the carrier writes, in the specific regulatory environments the carrier operates in, with the distribution models the carrier uses. A vendor with deep personal auto experience may have shallow commercial property experience. A vendor with deep admitted-market experience may not understand surplus lines. The depth question is line-specific and regulatory-specific.
The questions I recommend asking to verify insurance domain depth:
Show me 3 named carrier references in our lines of business and our state footprint. Generic “insurance” references are not enough. The references should match the carrier’s actual profile - same LoB mix, similar state count, comparable GWP scale.
Walk me through your platform’s data model for [specific LoB the carrier writes]. Vendors who have actually shipped that LoB will explain the data model in 15 minutes. Vendors who have not will pivot to “configurable” without showing the underlying structure.
Describe a regulatory examination your platform supported in the last 24 months. Real insurance regulatory examinations produce specific documentation patterns. Vendors who have been through them describe specifics; vendors who have not speak in generalities.
Trait 2: Honest vendor positioning
Honest vendor positioning is the trait I see least often in vendor sales conversations, and it is the trait that predicts partnership success most reliably. A vendor who says “we are the best fit for $5B+ enterprise carriers and we are oversized for mid-tier” is being honest. A vendor who says “we do everything from MGA to enterprise” is positioning, not informing. Carriers should reward the first vendor with serious consideration and exclude the second from finalist lists.
Decerto’s positioning is intentionally honest: we are the right-sized option for $500M-$5B GWP P&C carriers, and we are not the right fit for $5B+ enterprise carriers - Guidewire is the industry standard there. We say this in vendor demos, in RFP responses, and in this article. The honesty is not a sales tactic; it is the operating discipline that prevents the wrong-fit project that consumes years of the carrier’s IT budget and produces no working platform.
The questions I recommend asking to verify honest positioning:
Where is your platform NOT a good fit? A vendor who cannot name a scenario where their product is the wrong choice is positioning. Vendors with mature self-awareness will name 2-3 carrier profiles where they would refer the carrier to a competitor.
Describe a recent prospect you walked away from and why. Vendors who walk away from poor-fit prospects have the discipline that produces successful partnerships. Vendors who claim they have never walked away are operating revenue-first, not fit-first.
What is your product roadmap reality vs marketing? Every vendor has features in marketing materials that are not yet shipped. Honest vendors will say “this is on the roadmap” instead of “we have this.” Verify the difference before signing.
For the deeper context on Decerto’s honest positioning approach, our Build vs Buy vs Partner decision framework covers the explicit competitor landscape we operate in and where Higson fits relative to Guidewire, Duck Creek, Sapiens, Insurity, EIS, and Majesco.
Trait 3 - IP ownership clarity (code, configurations, data)
IP ownership clarity is the trait that determines what the carrier actually owns at the end of the partnership, and it is the trait most commonly addressed by vague contract language that produces disputes at exit time. The clarity question has three layers that should be answered explicitly in the contract before signing.
The three-layer IP ownership model
Layer 1: Platform code. The vendor’s platform code is the vendor’s IP. The carrier licenses the right to use it. This is standard and appropriate - the vendor cannot give away the platform.
Layer 2: Configuration and business logic. Carrier-specific configuration of the vendor’s platform - the underwriting rules, the rating logic, the workflow definitions, the data model extensions - is the gray zone. Some vendors claim this as their IP (extension to their platform). Others recognize it as the carrier’s IP (carrier business logic configured on the platform). The contract must specify which.
Layer 3: Carrier data. Policy data, claims data, customer data, transaction history - all generated by the carrier’s operations. This is unambiguously the carrier’s IP. The contract should explicitly confirm this and specify the format and timeline for data return at the end of the relationship.
The specific contract questions
In my experience reviewing vendor contracts for mid-tier carriers, the IP ownership clauses are usually buried in 40-60 pages of legal language and are easy to miss in time-pressured signing windows. I have worked with carriers who discovered at year 3 that their “configurable” platform’s business logic was claimed as vendor IP - which meant the carrier could not export the rules even if it wanted to migrate. The specific questions to clarify with legal counsel before signing:
Does the contract explicitly state that configuration and business logic developed during implementation are the carrier’s IP? If the contract is silent, the default in most jurisdictions favors the vendor. If the contract claims configuration as vendor IP, the carrier has just paid for implementation work that the vendor can resell to competitors.
Does the contract specify the data extraction format and timeline at termination? Vague language (“vendor will provide reasonable assistance”) is not sufficient. The contract should specify the data format (ACORD XML, JSON, CSV with documented schema), the extraction timeline (typically 30-90 days), and any associated fees.
Does the contract specify who owns customizations developed jointly? Many vendor relationships include joint development of capabilities (carrier-funded extensions to the platform). The IP ownership of those extensions must be explicit - sole carrier IP, sole vendor IP, joint IP with carrier perpetual license, or some other structure.
The Decerto IP ownership posture
For context on how partnership-model vendors typically handle this, Decerto’s standard contract structure recognizes the carrier’s configuration and business logic as the carrier’s IP, with the carrier retaining the right to extract that IP in documented formats at any point in the relationship (not just at termination). This is the posture I recommend mid-tier carriers require from any partner-model vendor.
For the broader strategic context on how the partnership model affects IP ownership and what to negotiate at signing, our coverage of composable insurance and MACH architecture addresses how API-first architecture changes the IP ownership conversation.
Trait 4 - Configuration vs custom code lock-in implications
The distinction between configuration and custom code is often presented as a technical detail but is actually a strategic lock-in dimension. Configuration is parameter changes that the platform supports natively. Custom code is engineering work that extends or modifies the platform beyond its native capabilities. The two have fundamentally different lock-in implications, and many carriers do not understand which they are buying.
The configuration-versus-custom-code spectrum
The trap I see most often: carriers assume they are buying “configuration” and discover at month 18 they have committed to “core code modification” because the vendor’s “configurable” platform requires source-level changes for the carrier’s specific requirements. The difference matters because upgrade paths, exit cost, and ongoing maintenance burden are dramatically different.
The specific questions to ask
For each customization the carrier needs, which category does it fall into? The vendor should be able to map every requirement to one of the five categories above. Vendors who answer “it depends” or “we make it work” are usually describing high-lock-in customizations dressed up as configuration.
What happens to our customizations when the vendor upgrades the platform? Pure configuration survives upgrades. Plugin extensions usually survive with minor adjustment. Core code modifications often break and require re-implementation. The answer determines how much engineering capacity the carrier needs to maintain over 5+ years.
Can our customizations be exported and reused if we eventually migrate to a different platform? Pure configuration concepts are portable (a rating algorithm is a rating algorithm). Custom code in a vendor-specific runtime is not portable. The portability of customizations determines the actual exit cost.
The honest framing on customization trade-offs
My take, after seeing many mid-tier carriers struggle with this: the right answer is usually to push as much customization as possible into pure configuration and API-level integration, accept some plugin extensions where necessary, and refuse core code modifications absent a strong strategic reason. The carriers who follow this discipline preserve their optionality; the carriers who customize at the core code level are signing up for a 7-10 year platform commitment regardless of how the relationship evolves.
For carriers thinking about how composable architecture supports the low-lock-in customization pattern, our coverage of composable insurance and MACH architecture covers the technical patterns that keep customization in the portable range.
Trait 5 (Open source posture) and Trait 6 (Escrow agreements)
Trait 5: Open source posture
The vendor’s open source posture is a structural signal about the partnership’s long-term shape. Vendors who use significant open source components (Apache Kafka, PostgreSQL, Spring Framework, React, Kubernetes) have made architectural choices that reduce their own platform lock-in and tend to produce platforms with better portability. Vendors who build everything proprietary have made architectural choices that maximize their platform’s stickiness.
The questions I recommend asking to verify open source posture:
What percentage of your platform is built on open source components? Modern insurance platforms typically have 40-70% of their codebase using open source dependencies (databases, messaging, web frameworks, identity management). Vendors with very low open source percentage are usually maintaining proprietary versions of capabilities that the industry has standardized on - which is expensive for them to maintain and risky for the carrier to depend on.
Do you contribute back to open source projects you use? Vendors who contribute back are signaling that they intend to maintain the open source relationship for the long term. Vendors who only consume open source are signaling that they treat OSS as a cost reduction strategy, which is fine but does not indicate the long-term commitment that contributing back would.
Have you been involved in any open source license violations or disputes? This is a low-frequency but high-impact question. License violations can produce expensive downstream litigation that the carrier may inherit if the vendor is acquired or restructured.
Trait 6: Escrow agreements - the safety net and its limits
Source code escrow is the traditional safety net for vendor disappearance. The carrier and vendor deposit the platform’s source code with a neutral third party (Iron Mountain is the historical leader, with NCC Group and similar firms as alternatives). If the vendor goes bankrupt, gets acquired in ways that interrupt service continuity, or otherwise fails to maintain the platform, the escrow agreement triggers and the carrier receives access to the source code.
In practice, escrow is more limited than the marketing suggests. The four specific limits I see in production:
Limit 1: Escrow does not include the operational knowledge to run the platform. Source code without the platform engineering team that built it is rarely operable. The carrier gets the code but not the ability to use it without major investment.
Limit 2: Escrow triggers are narrowly defined. Most escrow agreements trigger only on vendor bankruptcy or contract termination by the vendor. Vendor acquisition by a competitor, vendor pivot to a different product, or vendor de-prioritization of your specific platform usually does not trigger escrow.
Limit 3: Escrow does not include integration with vendor SaaS services. If the platform depends on the vendor’s cloud services, AI services, or hosted components, the source code in escrow does not include those dependencies. The carrier gets the application code but cannot operate it without the vendor’s services.
Limit 4: Escrow update frequency is usually inadequate. Many escrow agreements require updates every 6 months or annually. Modern continuous deployment platforms change daily. The escrowed code is usually significantly behind the production version.
What to ask about escrow
Is source code escrow included in the standard contract or available as an option? It should be standard. Vendors who push back on escrow as standard are signaling something about their confidence in the relationship.
What are the specific trigger events for escrow release? Beyond bankruptcy, the contract should specify vendor product end-of-life, vendor failure to maintain SLAs for a defined period, and vendor acquisition that affects service continuity.
What additional materials are deposited beyond source code? Documentation, build instructions, dependency manifests, infrastructure-as-code definitions, deployment runbooks - all materially affect whether the escrowed code is actually operable.
Trait 7 (Data portability) and Trait 8 (Exit strategy contract clauses)
Trait 7: Data portability - the actual exit feasibility test
Data portability is the single most important practical test of partnership exit feasibility. The contract may include escrow agreements and IP ownership clauses, but if the carrier cannot extract its operational data in a usable format, the exit is theoretical. The portability test should be performed at vendor evaluation time, not at exit time.
The specific data portability test I recommend mid-tier carriers run during vendor evaluation:
Step 1: Define the data extraction scope. Policy data, claims data, customer data, transaction history, configuration definitions, document repository. The full operational data set the carrier would need to migrate to a different platform.
Step 2: Ask the vendor to demonstrate the extraction process. Not promise the extraction process - demonstrate it on a non-production dataset. The vendor should be able to produce a sample export in the documented format within 30 days.
Step 3: Verify the format is industry-standard. ACORD AL3, ACORD XML, ACORD digital standards for P&C carriers. Vendors who export to “vendor-specific format with documentation” are functionally locking the carrier in even though the marketing claims data portability.
Step 4: Test the import on a different platform. If possible, take the sample export and import it into a second platform (a sandbox of another vendor, a test environment of a competitor) to verify the data actually migrates cleanly.
Carriers who run this test during evaluation discover the vendors who have actually engineered for portability and the vendors who have only marketed it. The difference is usually obvious in the first 30 days of testing.
Trait 8: Exit strategy contract clauses - the seven that matter
The exit strategy is not a single contract clause; it is a set of seven clauses that together determine what happens when the partnership ends. Mid-tier carriers should ensure all seven are in the contract before signing.
Clause 1: Termination triggers. Carrier-side termination should be permitted for cause (vendor breach of SLA, vendor failure to deliver) and for convenience (with appropriate notice period and exit fees). Vendors who only allow vendor-side termination are creating asymmetric exit risk.
Clause 2: Notice period. Standard is 90-180 days for convenience termination. Shorter periods favor the vendor (less transition time); longer periods favor the carrier.
Clause 3: Data extraction obligation. The vendor must produce the carrier’s operational data in documented format within a specified timeline (30-90 days post-termination). The format and timeline should be explicit, not “reasonable.”
Clause 4: Transition assistance. The vendor must provide migration support for a defined period (6-12 months typically) with specified hours per month, team involved, and rate structure.
Clause 5: IP ownership at termination. Carrier’s IP (configuration, business logic, data) transfers fully to the carrier. Vendor’s platform IP remains with the vendor.
Clause 6: SLA penalties and credits. SLAs should have meaningful financial penalties for vendor failure. Credits to next month’s bill are not meaningful penalties; cash refunds for sustained SLA failures are.
Clause 7: Audit rights. The carrier should have the right to audit vendor compliance - security practices, SLA performance, data handling, regulatory compliance - exercisable on reasonable notice, not “with vendor consent.”
For mid-tier carriers, all seven clauses should be in the RFP scoring matrix at evaluation time. Vendors who push back on any of the seven are signaling something about how they will operate in the partnership. The pushback patterns I see most often are on Clauses 1 (termination triggers), 3 (data extraction obligation specificity), and 6 (meaningful SLA penalties).
For the broader strategic context on how exit risks affect the partnership decision and what happens during legacy retirement after a successful migration, our insurance software integration with legacy systems article covers the Strangler Fig pattern that mid-tier carriers use to migrate cleanly between platforms.
Putting the 8 traits together - vendor evaluation framework
The 8 traits become a coherent evaluation framework when scored together. Each trait gets evaluated against the same set of criteria, with each trait’s score weighted by its importance to the carrier’s specific situation.
The 8-trait scoring framework
A vendor scoring 32-40 across all 8 traits is a strong partner candidate. A vendor scoring 24-31 has caveats but may be acceptable depending on which traits scored low. A vendor scoring below 24 is creating structural risk for the carrier regardless of features or commercial terms.
The scoring discipline
In my experience reviewing vendor RFPs, the discipline of scoring all 8 traits explicitly is more important than the specific scoring approach. Carriers who score only the first 5 traits (the conventional checklist) systematically underweight lock-in risk. Carriers who score all 8 produce evaluation matrices that surface the lock-in dimensions that conventional checklists miss.
What the 8 traits look like in production
The carriers I have advised across 20+ years of insurance delivery who applied this framework rigorously made different vendor selections than they would have made on conventional checklists alone. In two specific cases in the last 36 months, the carrier had a vendor finalist that scored highly on the first 5 traits and poorly on traits 6-8 (escrow, data portability, exit clauses). Both carriers ultimately selected a different vendor with slightly weaker scores on traits 1-5 but materially stronger scores on traits 6-8. Both projects have completed successfully; both carriers retained the optionality the 8-trait framework was designed to protect.
For the broader strategic framework that puts vendor evaluation in context (Build vs Buy vs Partner decision before this vendor evaluation), our Build vs Buy vs Partner decision framework addresses the prior strategic choice. This 8-trait framework applies after the carrier has decided to work with a vendor, regardless of which approach the carrier selected.
FAQ
How do you avoid vendor lock-in with insurance software?
You avoid vendor lock-in with insurance software by evaluating 8 traits at vendor selection time rather than the conventional 5: IP ownership clarity (who owns configuration, business logic, data), configuration vs custom code distinction (low-lock-in customization types preferred), open source posture (vendors using and contributing to OSS), source code escrow with comprehensive trigger events, data portability tested with actual export in ACORD format, and exit strategy contract clauses (the 7 specific terms covering termination, notice, data extraction, transition assistance, IP ownership at termination, SLA penalties, and audit rights). The traits should be scored explicitly in the RFP matrix, not assumed.
What should you look for in an insurance technology vendor?
Look for 8 specific traits: 1) Insurance domain depth specific to your lines of business and regulatory profile, 2) Honest vendor positioning where they admit non-fit scenarios, 3) IP ownership clarity in the contract, 4) Configuration vs custom code distinction with most needs in low-lock-in categories, 5) Open source posture with active OSS use and contribution, 6) Escrow agreements with comprehensive triggers, 7) Demonstrated data portability via ACORD format export, 8) Exit strategy contract clauses with the 7 specific terms. The conventional 5-trait checklist (domain, expertise, communication, commitment, adaptability) is necessary but insufficient.
What is a source code escrow agreement for insurance software?
A source code escrow agreement is a contract where the vendor deposits the platform’s source code with a neutral third party (Iron Mountain, NCC Group, similar firms), with documented release triggers - typically vendor bankruptcy, vendor product end-of-life, sustained SLA failures, or vendor acquisition that affects service continuity. If a trigger occurs, the escrow firm releases the source code to the carrier. In practice, escrow has four limits: it does not include operational knowledge to run the platform, triggers are narrowly defined, it does not include vendor SaaS dependencies, and update frequency is often inadequate compared to modern continuous deployment.
How do you exit an insurance software vendor cleanly?
You exit an insurance software vendor cleanly by ensuring 7 contract clauses are in place at signing: termination triggers for cause and convenience, 90-180 day notice period, explicit data extraction obligation with format and timeline (ACORD AL3 within 30-90 days post-termination), transition assistance for 6-12 months with defined hours and team, IP ownership at termination clarifying carrier and vendor IP, meaningful SLA penalties with enforceable structures, and audit rights exercisable on reasonable notice. Without these clauses, exit becomes a negotiation rather than a contractual right.
What is the difference between configuration and custom code in insurance software?
Configuration is parameter changes that the vendor’s platform supports natively - rating tables, workflow definitions, data field additions through the platform’s UI. Custom code is engineering work that extends or modifies the platform beyond its native capabilities - plugins, extensions, or modifications to the platform’s source code. The two have fundamentally different lock-in implications: pure configuration is largely portable concepts, while custom code in vendor-specific runtimes is platform-dependent. Carriers should push as much customization as possible into configuration and refuse core code modifications absent strong strategic reasons.
How do you test data portability with an insurance software vendor?
You test data portability by running a 4-step process during vendor evaluation: 1) Define the data extraction scope (policy data, claims, customer, transaction history, configuration), 2) Ask the vendor to demonstrate extraction on a non-production dataset within 30 days, 3) Verify the format is industry-standard (ACORD AL3, ACORD XML, ACORD digital standards), 4) Test importing the export into a different platform to confirm the data actually migrates cleanly. Vendors who have engineered for portability complete this test in days; vendors who only marketed portability fail at step 2 or step 3.
Talk to Decerto about IT Audit and Architecture Review
Choosing an insurance technology partner is a 5-7 year commitment that determines whether the carrier preserves its operational optionality or trades it for short-term implementation speed. The mid-tier carriers I have advised who finished their partnerships with their optionality intact are the ones who scored all 8 traits explicitly at evaluation time, who pushed back on vague IP ownership clauses, and who tested data portability before signing rather than after. The carriers who skipped the 8-trait discipline usually discovered the missing protections at year 3-4, when renegotiation was no longer possible.
In my experience, every carrier that has tried to make this evaluation from vendor demos has spent 6-12 months and significant consulting fees before reaching the same answer that a vendor-neutral 4-hour evaluation framework would have produced. Vendor demos optimize for showing platform capabilities; they do not surface the lock-in dimensions that the 8-trait framework addresses.
What we offer: a free 4-hour IT Audit with a senior architect from Decerto. The output is a 25-30 page report covering the carrier’s vendor evaluation framework, the 8-trait scoring approach applied to relevant vendors in the carrier’s context, the specific contract clauses to negotiate, and the data portability test design for the carrier’s specific data set.
It is not a product demo or a sales pitch. The audit can recommend that the carrier select a different vendor (including Guidewire, Duck Creek, Sapiens, Insurity, EIS, or Majesco) if the fit is better for the carrier’s profile. I have written that recommendation more than once. The output is an honest vendor-neutral assessment the CIO and CTO can defend to the Board, regardless of which vendor ultimately wins the decision.
The 20+ year context: Decerto has shipped 100+ insurance projects since 2006, including partnership-model engagements at carriers including Allianz Poland (product management on Higson), Warta/HDI/Talanx Group (multi-line modernization on eAgent and Higson), BNP Paribas Cardif (claims centralization on Higson), and InterRisk (Vienna Insurance Group). The verified case studies are documented on our case study page. Decerto’s standard contract structure recognizes carrier configuration and business logic as carrier IP, supports source code escrow as standard, and includes all 7 exit strategy clauses in our base contract template. Higson, our flagship product, is built for mid-tier P&C carriers $500M-$5B GWP. Higson is not the right fit for $5B+ enterprise carriers - Guidewire is the industry standard there. We are honest about that, because the wrong-fit partnership is the most expensive mistake a carrier can make.
.avif)
Subscribe to receive the latest blog posts to your inbox every week.
