Trust & Transparency

You should have a reasonable sense of:

• what Arc knows;
• what it is using;
• where AI is involved;
• what remains under your control;
• what Arc is uncertain about;
• and where the product's limits are.

Transparency is not a separate feature of Arc.

It is part of how we believe coaching should work.

At a glance

Your training is the starting point

Arc can use information you maintain in the product to support coaching decisions.

Depending on the experience, that may include information such as:

• your current goal;
• your training plan;
• recent and completed training;
• readiness or other context you choose to provide;
• your feedback about how training felt;
• relevant coaching history;
• supported activity information you choose to enter or import.

Different Arc experiences use different amounts of context.

Arc is not designed around continuous surveillance of your life or training.

For the initial Beta, supported activity information may come from information you enter or files you choose to import.

If Arc later enables connected activity services, those connections should be explicit and authorized rather than treated as permission to continuously monitor your device, location, or life outside the supported connection.

The goal is not to collect as much information as possible.

The goal is to use the right information for the coaching decision in front of you.

AI has a role. It does not run everything.

Arc uses artificial intelligence in supported coaching, planning, review, and interpretation workflows.

That does not mean every Arc decision is generated by AI.

Arc also uses:

• structured product rules;
• canonical sources for important product facts;
• defined training and safety boundaries;
• deterministic calculations and validations;
• validation of supported AI outputs;
• fallback behavior;
• user-review and confirmation flows.

The role and authority of AI can differ by feature.

An AI-assisted coaching conversation and an AI-assisted training-plan proposal, for example, do not necessarily receive the same information or have the same authority within the product.

That distinction matters.

AI can help Arc synthesize context, notice relationships, prepare proposals, and communicate coaching clearly.

It should not become an invisible authority that can make any decision simply because a model produced an answer.

AI by experience

The exact implementation may evolve, but Arc is designed around a separation between AI interpretation and canonical product truth.

AI can still be wrong.

This architecture is intended to limit the consequences of an incorrect interpretation, not to pretend incorrect interpretations cannot happen.

Arc should show its work where it matters

A coaching recommendation is more useful when you can understand the important context behind it.

Arc is designed so supported experiences can surface things such as:

• why a recommendation is being made;
• what training or context is relevant;
• what changed;
• important limitations;
• what Arc is uncertain about;
• whether a meaningful change is still waiting for your review.

Not every output has the same explanation format.

Arc also does not claim that every AI-generated judgment can be perfectly reconstructed or explained.

But consequential coaching should not feel like unexplained instructions arriving from a black box.

When Arc does not have enough information to support a conclusion, the preferred answer is uncertainty—not invented certainty.

Meaningful changes stay reviewable

Arc is built around the idea that adaptation should not mean silently taking control away from the athlete.

A proposal can be identified, prepared, and explained without automatically becoming the athlete's plan.

Arc does not treat an AI suggestion as sufficient authority to silently apply a material plan change or phase transition.

That creates an important boundary:

Arc can help prepare the decision. The athlete remains part of the decision.

Not every small product calculation or presentation change requires confirmation.

But consequential changes to the training direction should remain understandable and reviewable.

Memory should be deliberate, not unlimited

Ordinary training history and retained personalization are not the same thing in Arc.

Your account naturally contains information such as:

• activities;
• goals;
• plans;
• reviews;
• coaching conversations;
• training history.

Arc separately treats certain context retained specifically for future coaching use as personalization.

Retained personalization has its own rules around:

• what the information represents;
• where it came from;
• whether you supplied or confirmed it;
• how long it remains relevant;
• which product decisions are permitted to use it;
• whether it has become stale or contradictory;
• and how you can control it.

Arc does not treat every conversation as permanent memory.

It also does not send a universal bag of everything it knows about you to every AI interaction.

The Beta architecture is deliberately narrow

Arc defines one approved personalization-to-Planning path: a structured availability constraint representing recurring weekdays when you are unavailable to train.

That path is rollout-controlled and should only influence Planning when the corresponding capability is enabled in the released Beta configuration.

Broader retained personalization is not authorized as a canonical decision input for Today, Coach, Activity Review, Weekly Handoff, Trajectory, or Observation during the Beta.

That narrow scope is intentional.

We would rather prove a controlled personalization architecture than imply that Arc has already built an all-knowing personal memory system.

Personalization controls

For supported retained personalization, the Beta can provide controls to:

• see what Arc has retained for coaching;
• understand the source of that information;
• confirm or reject eligible proposed context;
• reconfirm information when appropriate;
• suppress future use;
• retire information that is no longer relevant;
• remove eligible retained personalization;
• export retained-personalization information.

Removing retained personalization is different from merely asking Arc not to use it.

Where supported, Arc treats those actions distinctly.

How Arc learns whether the product is working

Arc needs limited operational information to run the service safely and understand whether important workflows are functioning.

That can include structured evidence about things such as:

• whether a workflow completed;
• whether a request failed;
• whether a safety or validation step ran;
• whether a generated operation was retried;
• whether a user accepted, rejected, or corrected an eligible product outcome;
• whether a background process completed successfully.

Operational telemetry is not intended to become a second unrestricted archive of everything an athlete says or does.

Arc treats different purposes separately.

For example:

• operating the service;
• supporting a user;
• receiving voluntary feedback;
• conducting generalized research;
• improving an AI model;

are not automatically the same purpose.

A new purpose should not silently inherit permission merely because Arc already possesses the information.

Model providers and other service providers

Some Arc features depend on third-party infrastructure and AI providers.

Arc is designed to send the context selected for the supported operation rather than automatically providing every service with a complete copy of everything Arc knows about you.

For the initial Beta, third-party providers support functions such as:

• hosting and infrastructure;
• identity and account authentication;
• AI processing;
• optional weather information.

Those providers have different roles and may have different retention requirements.

Arc's Privacy Notice describes the provider categories and current data-handling arrangements in greater detail.

As Arc adds capabilities, other provider categories may become necessary.

When a new provider materially changes how athlete information is handled, Arc's public disclosures should change with the product.

The Arc Beta does not include an Arc product feature or consent flow that authorizes athlete information for:

• third-party advertising;
• data licensing;
• generalized research;
• generalized model-improvement use.

A materially different future use would require separate product, governance, and privacy review before it became part of Arc.

Your information should serve your coaching — not become the product

Run With Arc LLC does not sell your personal information.

The Arc Beta does not include:

• third-party advertising;
• behavioral-advertising systems;
• retargeting integrations;
• advertising pixels intended to build advertising profiles from your Arc activity.

We do not believe a coaching relationship should depend on turning an athlete's training, questions, or personal context into an advertising asset.

That principle also applies beyond advertising.

New uses of Arc information should not simply appear because they are technically possible.

A materially different use—such as advertising, data licensing, generalized research, or model-improvement use—should require deliberate review before becoming part of Arc.

For more detail about what information Arc handles and why, see the Privacy Notice.

Who can access information

Most Arc processing is intended to happen through automated product systems and the service providers needed to operate them.

Individual user information may sometimes need to be accessed by authorized people for a defined operational purpose, such as:

• customer support;
• security investigation;
• account deletion;
• incident response;
• troubleshooting a specific failure;
• another specifically authorized operational or safety purpose.

Human access should not be treated as the default way Arc provides coaching.

Arc's internal-access practices, provider relationships, retention rules, and applicable safeguards are described more fully in the Privacy Notice and internal Data Governance controls.

Control should be described at its real scope

We want to be precise about the controls Arc actually provides.

The initial Beta includes supported controls for retained personalization, including:

• visibility;
• confirmation and rejection where applicable;
• reconfirmation;
• suppression;
• retirement;
• removal;
• a retained-personalization export.

That export covers retained-personalization information.

It is not a complete export of every piece of information associated with an Arc account.

Arc also contains an engineered account-deletion system.

Self-service account deletion is not enabled for the initial Beta release while external and operational safeguards are completed.

Until that process is activated, privacy or deletion requests can be directed to:

We would rather describe a control narrowly and accurately than imply functionality that does not yet exist.

Retention, deletion, and backups

Different Arc information exists for different purposes and may therefore have different retention requirements.

Account information, coaching records, operational evidence, and backups are not necessarily governed by one universal deletion timeline.

Arc is designed to distinguish between:

• removing information from active product use;
• removing retained personalization;
• deleting account-owned information;
• retaining limited records when legally or operationally required;
• treating information that may temporarily remain in external backups.

The detailed retention and deletion policy belongs in the Privacy Notice.

Arc will not claim a specific backup-deletion period unless that period is supported by the actual backup and restoration process.

Account deletion and subscription cancellation are also separate concepts.

One should not be described as completing the other unless the product has actually verified that outcome.

When Arc gets something wrong

Arc can be wrong.

That may happen because:

• information is incomplete;
• an imported or connected source supplied inaccurate or incomplete data;
• circumstances changed;
• a classification was incorrect;
• an AI interpretation missed something important;
• Arc inferred too much from limited evidence.

The appropriate response depends on the feature.

You may be able to:

• correct an underlying fact;
• clarify activity or movement information;
• add context;
• disagree with a review;
• decline a proposed plan change;
• correct retained personalization;
• reject or suppress retained context;
• remove retained personalization;
• report an incorrect or unsafe coaching response.

A correction does not necessarily rewrite every historical output that used the old information.

Historical coaching is part of what happened at the time.

But corrected or removed information should not silently continue controlling current coaching where the product supports that correction.

Fitness coaching is not medical care

Arc is a running and fitness coaching product.

It can consider information you choose to provide about:

• readiness;
• soreness;
• pain;
• fatigue;
• interruptions;
• other circumstances that may affect training.

That does not make Arc a healthcare provider.

Arc does not:

• diagnose injuries or medical conditions;
• prescribe medical treatment;
• provide medical clearance to train;
• guarantee that training is safe for a particular medical condition;
• replace qualified medical advice, diagnosis, or treatment.

Arc may respond conservatively to information that raises a training concern.

That can include reducing training exposure, holding a progression, or recommending that you seek appropriate professional evaluation.

Arc does not promise to prevent injury or guarantee a particular performance result.

Those are important limits to the product.

Security claims should match reality

Arc includes technical safeguards such as:

• authenticated sessions;
• account-level access boundaries;
• request protections;
• bounded AI context;
• validation around supported AI-generated operations;
• structured data-governance boundaries;
• data-minimization practices in supported operational records.

But security is more than a list of code features.

Hosting, identity systems, service-provider configuration, backups, operational access, monitoring, credentials, and human procedures matter too.

For that reason, Arc does not intend to use vague claims such as:

• “bank-level security”;
• “military-grade security”;
• “completely secure”;
• unsupported regulatory compliance;
• unsupported certification claims.

Public security statements should remain tied to safeguards Arc can actually demonstrate.

How Arc evaluates AI-assisted workflows

AI-assisted features should not be considered finished merely because they produced an answer.

Arc uses combinations of:

• automated tests;
• structured product contracts;
• deterministic validation;
• safety constraints;
• generation and operation traces;
• regression testing;
• release validation.

Those mechanisms help identify problems such as:

• unsupported claims;
• invalid plan structures;
• inconsistent product state;
• repeated generation failures;
• unsafe changes;
• cross-user contamination;
• incorrect assumptions about what the athlete has approved.

That does not mean every AI response is reviewed by a person.

Nor does testing make AI infallible.

The goal is to make AI behavior observable enough that important failures can be detected, investigated, and improved rather than treated as unavoidable mystery.

Known limitations

Arc's usefulness depends on the quality and completeness of the information available to it.

That creates real limits.

For example:

• imported or connected sources can provide incomplete or conflicting information;
• device and provider classifications may differ;
• activity data may be missing;
• readiness or subjective context may not have been provided;
• an AI explanation may be incorrect;
• a training pattern may not contain enough evidence to support a conclusion;
• Beta workflows may not yet cover every training situation;
• individual athletes can respond differently to similar training.

Arc should not hide those limitations behind confident language.

When evidence is insufficient, Arc should be willing to say:

We do not know yet.

Uncertainty can be a useful coaching conclusion.

Arc is still evolving

Arc is an actively developing product.

Some capabilities will become broader over time.

Some current boundaries may change.

Some ideas may never prove useful enough to ship.

Those changes should remain understandable.

When Arc materially changes:

• how information is used;
• what information is retained;
• how personalization works;
• what role AI plays;
• what authority an AI-assisted workflow has;
• what control an athlete has;
• which providers process information;

the public explanation should change with the product.

Transparency should not be a one-time disclosure written at launch.

It should remain part of the product relationship.

Material changes to this page should be dated and reflected in the version history.

The standard we are aiming for

Arc should be able to answer four basic questions clearly:

What information is relevant here?

How is it being used?

What role do Arc's systems or AI have in the decision?

What can I review, correct, or control?

Arc will not always have complete information.

When it does not, it should identify what is missing rather than invent certainty.

That is the standard we intend to design toward.

Coaching for the Long Run should also mean trust for the long run.