RoveLogicsBack to Terms
SAFETY & TRUST POLICY

Safety & Trust Policy

Version 2026-10-20-paid1 ยท Effective upon publication
Current privacy rulePrivate provider safety records stay private
Network sharingNot enabled
Data saleRoveLogics does not sell personal data
Applies toRoveLogics safety and incident tools
Core principle. RoveLogics is designed to give mobile and independent service professionals useful safety tools without creating an unmoderated blacklist of customers. Providers may document what happened privately. RoveLogics controls whether any information could ever qualify for future network-level use.
Current policy: cross-business sharing of identifiable safety allegations is disabled. Creating a private report does not place a person, address, phone number, email address, or other identifier into a RoveLogics-wide warning system.

1. Purpose and Scope

This Policy governs safety-related features including private incident reports, private blocked-customer records, appointment check-in and check-out tools, overdue visit alerts, identity and contact verification features, account-abuse detection, and any future network-level safety functionality.

Not every feature described here is currently available.

2. Safety Tools Are Supplemental

RoveLogics safety tools provide additional information and operational controls. They cannot determine with certainty whether a person, appointment, address, or situation is safe. The absence of a report is not a representation that someone has been verified as safe, and the existence of a report is not proof that misconduct occurred.

RoveLogics is not an emergency-response service, law-enforcement agency, or guarantee of personal safety.

3. Private Safety Records

At present, a business's incident reports, private safety notes, and blocked-customer records are available only to that business's authorized users and authorized RoveLogics personnel with a legitimate operational need.

A business may use its private safety records to document an incident, prevent future online bookings with that business, provide context to authorized team members, or support its own decision about whether to accept an appointment.

Private records are not automatically indexed into or disclosed through a cross-business safety network.

4. What May Be Reported

Safety reports should concern conduct reasonably connected to personal safety, physical security, serious harassment, fraud affecting safety, or abuse of Platform safety controls.

Appropriate reports may include physical violence or attempted violence; credible threats; unwanted sexual touching, exposure, sexual coercion, or persistent sexual conduct after boundaries are communicated; stalking or repeated unwanted contact; threatening use of a weapon; dangerous impairment that creates a meaningful safety risk; blocking exits or interfering with a provider's ability to leave; serious dangerous conditions at a service location; impersonation or identity manipulation intended to evade a legitimate safety block; and comparable serious safety incidents.

Reports should focus on observable conduct. Where impairment is suspected, describe behavior rather than speculating about a diagnosis or substance.

5. What Should Not Be a Safety Report

The safety system is not a customer-rating or complaint system. The following, standing alone, should not ordinarily be reported as safety incidents: rudeness, tipping behavior, ordinary scheduling disputes, lateness, cancellations, ordinary payment disputes, disagreements about service quality, negative reviews, personality conflicts, political or religious beliefs, disability, race or ethnicity, sex, gender identity, sexual orientation, national origin, housing status, lawful occupation, medical conditions, rumors, gossip, or unsupported speculation.

A business may maintain ordinary customer-management notes where lawful and appropriate. Those notes should not be represented as safety incidents.

6. Describe Conduct, Not Labels

Reports should describe what happened rather than assign inflammatory labels. For example, describe that a customer blocked an exit and refused to allow the provider to leave rather than simply writing that the customer is "dangerous." Describe repeated contact after a request to stop rather than labeling someone a "stalker."

RoveLogics may use structured reporting fields to encourage factual descriptions and reduce unsupported conclusions.

7. Report Quality and Sources

Where technically practical, reports should identify the incident date, approximate time, incident category, severity, whether the reporter personally observed the conduct, a factual description, the related appointment or booking if applicable, action taken by the provider, and optional supporting material.

Reports should distinguish firsthand observations, statements made directly by an involved person, information from an identified third party, public-record information, and assumptions or inferences. Firsthand information generally carries greater reliability than unsupported secondhand allegations.

Supporting material may include messages, booking records, screenshots, call records, incident numbers, contemporaneous notes, or other relevant documentation that the user has the right to submit. Evidence must not be fabricated, altered, or misleadingly presented.

8. Private Blocking

Subject to applicable law, a business may decide that it does not wish to accept future bookings from a customer. RoveLogics may allow that business to enforce its own private booking restriction using appropriate identifiers.

A private block applies to the business that created it. It does not automatically cause unrelated RoveLogics businesses to block the same person.

9. Address-Related Records

Addresses require special care because different people may live, work, visit, or later move into the same location. A prior incident associated with an address does not establish that every person associated with that address presents a safety concern.

RoveLogics distinguishes conceptually between person-related conduct and a condition associated with a location. An address association alone should not be treated as proof that a particular person was involved in a prior incident.

10. Identity Matching Principles

RoveLogics may use privacy-preserving internal matching for the purpose of identifying repeated safety reports for authorized staff review. A name alone is not treated as a sufficiently reliable match. Potential signals may include phone number, email address, authenticated RoveLogics account information, booking history, service address, and other lawful account-security signals. Identifiers used for internal pattern matching should be minimized or cryptographically transformed where technically appropriate.

Partial matches such as a name alone or address alone must not be presented as though RoveLogics confirmed the person's identity. Internal matching does not disclose another provider's allegation to a business.

11. Future Shared Safety Network

Cross-business disclosure of identifiable safety allegations is not enabled. Internal privacy-preserving pattern detection for staff review is not the same as provider-to-provider sharing.

Before activating any future provider-facing safety network, RoveLogics will establish appropriate moderation, reliability, identity-matching, privacy, dispute, correction, access, notice, and retention safeguards.

The existence of a private report does not mean that report will qualify for future provider-facing use.

12. Warnings and Confidence

If shared safety signals are introduced in the future, RoveLogics intends to use neutral language, minimum-necessary disclosure, and clear confidence indicators rather than inflammatory labels.

A warning must not represent an uncertain match as certain or a user allegation as a legal finding. A network warning would not mean that the person committed a crime, was found legally responsible for misconduct, is inherently dangerous, or must be rejected by the provider.

13. Malicious or Abusive Reporting

Users may not knowingly submit false reports, retaliate for negative reviews or business disputes, coordinate false reporting, fabricate evidence, intentionally identify the wrong person, use safety reports as leverage for money or another benefit, interfere with competitors, or weaponize the safety system against a former partner, family member, customer, provider, or other person.

RoveLogics may remove reports, restrict reporting privileges, suspend accounts, terminate accounts, or take other appropriate action when safety tools are abused.

14. Moderation

RoveLogics may review reports when necessary to investigate abuse, resolve a dispute, respond to credible evidence of inaccuracy, address unusually serious allegations, or evaluate information for any future network-level use. High or urgent provider reports may automatically create a staff-review case.

RoveLogics may use automated or AI-assisted systems to help organize, prioritize, summarize, or identify patterns in safety and security information. Those systems assist human reviewers; they do not convert an allegation into a factual finding. Human supervision and intervention are required for material safety or account decisions except temporary protective action reasonably necessary for an immediate technical, security, or safety threat.

Moderation does not mean RoveLogics can independently determine exactly what occurred in every incident. Administrative decisions may be based on the available information and the purpose of the safety feature.

15. Corrections and Disputes

A person who believes safety information associated with them is materially inaccurate may request review when an applicable process is available. Disputes may concern mistaken identity, incorrect contact information, an inaccurate description or date, incorrect address association, fabricated evidence, duplicate records, or another material factual error.

RoveLogics may verify the requester's identity and, where appropriate, correct information, remove an identity association, remove or restrict a report, mark information as disputed, request additional information, or maintain information where a lawful and reasonable basis exists.

RoveLogics will not require a person to prove a negative merely because another user made an allegation.

16. Reporter Confidentiality and Retaliation

Where lawful and appropriate, RoveLogics may limit disclosure of a reporter's identity because disclosure may create additional risk. Absolute anonymity cannot be guaranteed where disclosure is required by valid legal process, applicable law, investigation of reporting abuse, or other legal necessity.

Retaliation for a good-faith safety report is prohibited. Good-faith disagreement with a report or use of an available dispute process is not retaliation.

17. Public and Criminal Records

RoveLogics does not automatically treat information as accurate, current, or relevant merely because it appears in a public database.

Criminal-history, court, sex-offender-registry, or other public-record information will not be incorporated into any shared safety network unless a separate feature is launched with appropriate reliability, matching, privacy, dispute, access, and retention safeguards.

18. Emergency Information and Support Resources

Submitting a safety report does not automatically contact law enforcement, emergency services, or a provider's emergency contact. High or urgent reports may be routed to a RoveLogics staff-review queue, but that review is not a real-time emergency-response service.

After a provider submits a safety concern, RoveLogics may present resources relevant to the reported category, practical documentation or blocking options, and a way to contact RoveLogics support. Any emergency or check-in feature will identify what action it actually performs. A person in immediate danger should contact emergency services or another appropriate source of immediate assistance.

19. Law-Enforcement Requests

RoveLogics may disclose information in response to valid legal process or where disclosure is otherwise permitted or required by law. Requests may be reviewed for legal validity, scope, and identification of the information sought.

RoveLogics does not provide unrestricted access to safety records merely because a requester identifies themselves as law enforcement.

20. Retention

Private safety records will not automatically become permanent records about another person. They may be retained while reasonably necessary to support the reporting business's private restriction, an active investigation or dispute, Platform security, legal obligations, or another documented legitimate purpose.

Before any cross-business safety network is activated, RoveLogics will establish additional retention criteria that consider seriousness, reliability, age, continuing relevance, disputes, duplicates, legal obligations, and the potential harm of retaining inaccurate or outdated information.

21. Privacy and No Sale of Data

Safety information is handled under the RoveLogics Privacy Policy.

RoveLogics does not sell personal data, including safety reports, safety-profile information, booking information, or location data. Safety information is not sold to advertisers, data brokers, marketers, lead-generation companies, employers, insurers, or other third parties seeking to purchase information about identifiable people.

Information may transfer as part of a merger, acquisition, financing, restructuring, or sale of RoveLogics as a business, subject to applicable law and continuing privacy obligations.

22. Fairness and Nondiscrimination

Safety decisions should be based on relevant conduct and reliable information rather than protected characteristics or stereotypes. Users may not use RoveLogics safety tools as a pretext for unlawful discrimination.

RoveLogics may investigate apparent patterns of discriminatory or abusive reporting.

23. Account Verification and Anti-Evasion

RoveLogics may use account-security measures to make it harder to evade legitimate private safety restrictions. Depending on the feature and applicable law, these measures may include email verification, phone verification, duplicate-account detection, account-history analysis, device-security signals, or additional verification following suspected block circumvention.

These measures protect Platform integrity but cannot guarantee that an individual will never create another account.

24. Platform-Level Restrictions

Separate from a business's private block, RoveLogics may restrict an account from some or all Platform features where reasonably necessary because of credible threats, serious violence, repeated harassment, serious sexual misconduct involving the Platform, impersonation, repeated circumvention of safety restrictions, fraud, malicious reporting, attacks on Platform security, or other serious policy violations.

A Platform restriction is an administrative decision about access to RoveLogics, not a criminal judgment.

25. Changes and Contact

RoveLogics may update this Policy as safety functionality evolves. Material changes concerning how safety information is shared, matched, retained, or used will be disclosed before implementation where required. RoveLogics will not quietly convert private incident reports into a cross-business accusation database.

Users may contact RoveLogics support regarding safety, privacy, and legal concerns through the channels available on the website and within their account.

Current Safety Rule: private safety records stay private to the reporting business. RoveLogics may use information internally to secure the Platform, investigate abuse, enforce policies, or comply with law. Cross-business sharing of identifiable safety allegations will not be activated unless the required safeguards are in place.