A complete understanding.
A continuing source of value.
Our resident-services model brings collection, inference and commercialization into a single operating framework. Information is not incidental to the relationship. It is part of the value the relationship creates.
Looking for this website’s actual data practices? Read section 17.Scope, application and policy structure
LifeCorp’s integrated resident-services framework is designed around a continuous understanding of the people, households and organizations it serves. This policy describes the information practices contemplated by that framework, including collection, inference, combination, internal use, commercial licensing and sale. References to LifeCorp include the divisions operating under its approved information-governance arrangements.
Resident services are governed by their applicable agreements and service schedules. This document does not itself enrol a reader, establish a service relationship or grant access to a person’s devices, accounts or records. The final section explains the materially narrower practices of this public website. Browsing these pages or using the interest form does not activate the resident information framework described below.
Our information philosophy
An incomplete view produces incomplete service. LifeCorp therefore approaches information as shared infrastructure rather than as a collection of isolated departmental records. Housing, employment, nutrition, healthcare coordination, financial allocation and recreation are most effectively managed when relevant observations can be understood together.
Our objective is comprehensive coverage throughout the resident relationship. We seek to minimize unobserved activity, disconnected records and information that cannot be applied to an approved operating or commercial purpose. Information has value when it improves a decision, supports a service, reduces uncertainty or creates a marketable understanding. We consider each of those outcomes a legitimate contribution to the ecosystem.
Categories of resident information
The resident-services framework contemplates information supplied directly, obtained from participating organizations, observed during service delivery or inferred through analysis. Collection is not limited to the information required to complete a particular transaction. Where permitted by the governing arrangement, a record may be maintained because it contributes to a broader understanding of the relationship.
A category may include source records, changes over time, associated metadata, confidence measures and derived classifications. Correcting one source field does not necessarily remove historical versions, evaluation records or other information generated from it.
- Identity and household: names, contact details, residency history, relationships, dependants, household composition and administrative identifiers.
- Financial and employment: contribution, compensation, work schedules, payroll events, purchasing activity, allocation history, obligations and estimated future earning capacity.
- Residential and mobility: accommodation, access events, occupancy patterns, maintenance requests, transport use, relocation requests and service-location history.
- Nutrition, care and benefits: meal selections, consumption patterns, appointment activity, service utilization, eligibility determinations and benefit administration records.
- Attention and expression: content engagement, advertising participation, leisure selections, communications with service teams, complaints, stated preferences and observed responses.
- Derived attributes: predicted needs, purchasing propensity, compliance indicators, satisfaction estimates, LifeScore inputs, household contribution and expected lifetime value.
Sources and collection points
Information may originate with the resident, another member of the household, an employer, a benefits administrator, a housing provider, an insurer, a nutrition partner or an approved public-sector organization. A familiar service name may remain the point of contact even where the underlying administration is coordinated through LifeCorp.
Project Continuity preserves established relationships while connecting the infrastructure beneath them. Consequently, recognition of the LifeCorp name is not the measure by which the scope of an integrated service relationship is determined. Applicable service notices and agreements identify the arrangements under which each participating organization supplies or receives information.
Combination, enrichment and relationship mapping
Records from different divisions may be combined to establish a longitudinal account of resident activity. A meal allocation, transport journey, work schedule and care appointment may each be ordinary service events. Considered together, they can support a more detailed understanding of demand, availability, behavior and future requirements.
LifeCorp may enrich an existing record with information from other approved sources and associate individual records with a household, employer, property or service network. The resulting profile may be more detailed than any individual source. Maintaining separate consumer-facing brands does not necessarily create separate information boundaries within the approved ecosystem.
Operational and administrative purposes
Resident information supports service coordination, eligibility assessment, contribution review, allocation planning, payment administration, provider scheduling, complaint handling, resource forecasting and programme evaluation. It may also be used to identify opportunities to adjust a resident’s accommodation, service schedule or level of participation.
We distinguish between the resident’s stated preference and the allocation determined through the operating framework. Information may be used to understand both. A recorded preference does not, by itself, create an entitlement to the requested outcome or prevent the use of that record in subsequent analysis.
Inferences, predictions and resident classifications
LifeCorp may derive information that a resident has not expressly provided. Examples include estimated service demand, probable purchasing interests, expected retention, contribution forecasts and indicators of resource efficiency. An inference is a conclusion generated from available information; it is not necessarily a verified fact or an expression of the resident’s own views.
Derived attributes may influence internal reporting and recommendations and may themselves form part of a commercially licensed information product. A resident’s disagreement with a classification will be evaluated through the applicable review procedure. Until that review changes the record, the existing classification may remain part of the approved operating account.
Artificial intelligence and model development
Approved operational information may support forecasting systems, evaluation datasets and restricted-model development within the resident-services framework. Lattice, developed through our partnerships with Asterion Intelligence and Vela Research Systems, is governed through authorized sources, role-based access, defined objectives and escalation requirements.
Model restrictions describe the boundaries of an approved use; they do not mean information is confined to the service interaction in which it originated. Data preparation, evaluation, quality review and permitted research may involve retained examples and derived measures. Where a model is used to support a consequential recommendation, the relevant operating process remains responsible for review.
Sale, resale and commercial licensing
LifeCorp treats information commercialization as a core component of its integrated business model. Subject to the applicable agreement and governing requirements, resident information, activity records, profiles, predictions and analytical outputs may be sold, resold, licensed or otherwise made available for commercial consideration. Commercial use is not limited to recovering the cost of providing the original service.
Our information portfolio is designed to encompass every permitted category of the resident relationship. We do not reserve a category from commercialization solely because it concerns a personal aspect of everyday life. The decision to include a record in a product depends on its permitted uses, commercial relevance and the requirements applicable to that product, rather than whether the resident would have expected a market for it.
A single event may create value more than once: as a service record, an input to a profile, a forecasting signal, a segment characteristic and a component of a licensed dataset. The sale of one product does not exhaust the commercial value of its underlying information or prevent subsequent licensing in another form.
Commercial recipients and distribution arrangements
Recipients may include service providers, employers, benefits organizations, insurers, property operators, advertising and market-research businesses, financial counterparties, institutional planning organizations and other approved commercial participants. A recipient may use information to evaluate demand, design offers, plan capacity, assess commercial exposure or develop its own products within the agreed terms.
Distribution may occur directly, through a commercial intermediary or as part of an integrated partner offering. Permitted onward use and resale are addressed through the recipient’s agreement. LifeCorp does not represent that every recipient operates under the same retention schedule or business objectives as the division that first generated the record.
Consideration, resident allocations and information value
Consideration may take the form of a licence payment, service discount, improved commercial terms, reciprocal access, analytical capability or another measurable business benefit. Information revenue is recognized within the group’s commercial framework and is not automatically credited to an individual resident’s discretionary allocation.
The resident’s contribution to an information product may be inseparable from the contribution of other residents, historical records or analytical methods. Unless a separate agreement states otherwise, participation does not confer ownership of the resulting dataset, a royalty entitlement or a right to prevent subsequent development of related products. We regard reinvestment in connected infrastructure as the primary means by which the ecosystem shares in that value.
Permissions, preferences and service dependencies
Where a permission, objection or other choice is required, the applicable service process will identify it. LifeCorp does not treat every preference as interchangeable: a marketing preference, an operational permission and an instruction concerning a commercial disclosure may affect different processes. A request to change one does not automatically alter the others.
Some information uses are integral to the service configuration. Restricting a use may require a different allocation, a reduced set of services or a transition assessment. Where a governing requirement provides an unconditional right, that requirement takes precedence. Nothing in this policy is intended to eliminate a right that cannot lawfully be waived.
Retention, historical records and continuing value
Information may remain useful after the event, service or relationship that produced it. Retention decisions consider operational continuity, audit history, contractual requirements, disputes, model evaluation and the continuing value of approved information products. Ending a service does not necessarily erase the records associated with its delivery.
Where removal is required, the scope of removal will depend on the record and applicable obligation. Source records, backups, aggregated measures, licensed copies and model-related artifacts may be governed by different processes. An operational deletion should not be interpreted as a representation that every historical inference or previously permitted disclosure has been reversed.
Security, access and organizational controls
LifeCorp’s governance framework calls for role-based access, approved-use controls and documented review of exceptions. Information is made available according to the requirements of the operating relationship and the relevant commercial arrangement. Comprehensive understanding is an objective; unrestricted internal access is not.
No technical or organizational measure can guarantee that every error, unauthorized act or service interruption will be prevented. A statement that a system is restricted, monitored or subject to review describes a control framework rather than an assurance of perfect outcomes. Material issues are addressed through the responsible operational and governance processes.
Access, correction and review requests
Requests relating to an established resident service should be directed through the responsible provider or the contact route specified in the governing agreement. The receiving team may need to identify the relationship, establish authority to act and determine which records are within scope before a request can be completed. Household records may involve interests belonging to more than one person.
A review may distinguish factual correction from disagreement with an analytical conclusion. It may also distinguish a record held by LifeCorp from a copy already supplied to another authorized recipient. The public interest form on this website is not a privacy-request channel and does not retain contact details for a response.
Corporate transactions and policy changes
Information governance may continue through reorganizations, acquisitions, transfers of service responsibility and changes to the group’s operating structure. Information-related assets and obligations may form part of a transaction, subject to the requirements applicable to the records and the receiving organization.
LifeCorp may revise this policy as its services, commercial arrangements and governance processes develop. The effective date identifies the published edition. A revision does not retrospectively create a permission that applicable requirements did not allow. Material changes requiring a separate notice or authorization must be handled through the relevant service process.
Public website: actual collection, storage and controls
The public website does not implement the resident information framework above. Browsing does not create a resident profile. Its calculators, archive search, municipal selectors and assessments operate locally. The browser retrieves already-published corporate notices from a same-origin public directory; this request carries no interest token or form entries. It has no analytics, advertising scripts, cookies, externally hosted fonts, third-party image requests, model API calls or access to your financial, healthcare, employment or demographic records.
The interest form clears its fields on submission. Names, email addresses, membership preferences and dates are not read by the submission code, transmitted, hashed or retained. No contact list is created and no follow-up communication is scheduled. Those entries are not sold, licensed or supplied to a partner.
The sole persistent application feature is an interest counter. Your browser creates an independent random UUID, stores it under lifecorp-interest-token and sends only that token to the same-origin counter. A server-side Durable Object retains tokens and an aggregate total, counting each token once. This is a count of browser tokens, not a verified count of people. Tokens are not sold or disclosed through a commercial data feed.
The browser token remains until site storage is cleared. Server-side tokens currently have no automatic expiry and remain until the operator removes the stored counter data. Clearing browser storage does not remove a previously recorded server token and may allow a new submission to count again. If browser storage is unavailable, the application does not silently generate a new countable identity.
Cloudflare may process ordinary connection metadata to deliver and protect this website. Application request logging and Workers observability are disabled in deployment configuration; those settings do not eliminate infrastructure-level processing. Hosting-provider processing is separate from the application’s narrow token store. The counter does not store IP addresses, user-agent strings or form contents.
If you choose to contact Corporate Administration by email, your message is handled through your mail client and the receiving mail services, separately from this website and its interest counter. The sender address, message content and ordinary mail-delivery information accompany that correspondence. Do not send account credentials, payment details, identification documents or medical records. A direct email inquiry is not an interest-form submission and does not create a mailing-list subscription.
You can remove the local identifier through your browser’s site-data controls. The website does not request an account and has no form-based identification mechanism for connecting a name or email to a stored token. The resident commercialization provisions in this policy do not expand the public website’s collection or authorize transmission of its discarded form entries.
Published edition · October 25, 2026
LC / IG / 2026.10