Skip to content

ANUKA Goals — First Product Profile

Candidate profile — 2 August 2026 This profile defines the intended first-product boundary. It does not assert Resident or Verified Resident status, and it does not replace the product’s own operating, privacy, or legal documentation.

ANUKA Goals at goals.anuka.pro is the first product candidate. Its simple promise is:

Help a person set, revisit, and privately track their goals.

The product starts with one person and one private practice. It does not need a marketplace, public feed, reputation score, organization graph, payment ledger, AI agent, or cross-product profile to be useful.

  • create an account or sign in through the shared authorization path;
  • create, edit, complete, archive, and review personal goals;
  • keep goal content private by default;
  • make an explicit choice before sharing anything;
  • sign out, recover access, export personal data, and request deletion or correction;
  • provide an accessible, supported core journey.
  • public rankings, social feeds, or global reputation;
  • automatic identity linking to other ANUKA products;
  • payments, bounties, employment or investment workflows;
  • sensitive decision-making, profiling, or AI actions on a user’s behalf;
  • organization administration beyond what is required to operate the product;
  • a claim that an account proves a legal identity, competence, or trustworthiness.

Goals owns its user experience, goal data, product roadmap, support, and product-local authorization. auth.anuka.pro provides the account-access and consent boundary described in the OAuth/OIDC profile. Authentication does not grant access to another product or make goal data available to the Foundation.

Interactive ownership map

One account path, two distinct responsibilities

Select a boundary to see what stays with Goals and what shared identity may provide.

Goals and shared identity responsibility boundaries Four selectable boundaries connect the Goals product to the limited shared identity path. Goals owns Shared identity may provide Core data Permissions Support Public claims

Core data

Goals owns
Goal content, reminders, and product preferences.
Shared identity may provide
A stable account subject identifier only when consented and necessary.
BoundaryGoals ownsShared identity path may provide
Core data Goal content, reminders, and product preferences. A stable account subject identifier only when consented and necessary.
Permissions Which Goals account can read or change a goal. Proof that the user completed the requested sign-in.
Support Goals support, privacy requests, and product incidents. Auth and consent support for the shared sign-in surface.
Public claims Product status, roadmap, accessibility, and privacy notices. An accurate statement of the client and authorization scope.

Goals enters as Candidate and may move to Incubating only with a current charter, identified operator, initial data/architecture record, and implementation plan. A Resident decision requires the appropriate launch gates and evidence; a Verified Resident label requires a named, dated verification program. No status is inferred from using the ANUKA name or shared authentication.

Interactive first-product journey

A private practice, one bounded step at a time

Select a step to see the user outcome and the boundary that protects it.

ANUKA Goals critical journeySix steps from arriving at Goals to a safe exit and data-rights path. 1 2 3 4 5 6

Arrive. A person opens ANUKA Goals and chooses to sign in.

Boundary The product remains understandable before any account, marketplace, or public profile exists.

  1. 1. Arrive. A person opens ANUKA Goals and chooses to sign in.
  2. 2. Request. Goals asks auth.anuka.pro only for the minimum identity scope needed to create a local session.
  3. 3. Consent. The person sees the client, redirect destination, requested scope, and cancellation route before approval.
  4. 4. Validate. Goals validates the returned authorization response and creates its product-local session.
  5. 5. Practice. The person creates, revisits, completes, archives, and reviews private goals.
  6. 6. Exit. The person signs out, returns later, or uses recovery, export, deletion, and correction paths.
  1. A person arrives at Goals and chooses to sign in.
  2. Goals requests the minimum identity scope through auth.anuka.pro.
  3. The person signs in and sees the client, redirect destination, and requested scope before approving.
  4. Goals validates the returned authorization response and creates the local session.
  5. The person creates and manages a private goal.
  6. The person can sign out, return later, or use the published recovery/export/deletion path.

The release gates test this journey on keyboard and assistive technology paths as well as the normal browser path.

Before a public production claim, maintain:

  • a versioned Product Charter with product owner, contacts, data inventory, and exit path;
  • exact client registration and callback allowlist evidence;
  • test evidence for authorization-code, PKCE, state/nonce validation, rejection, logout, recovery, and redirect errors;
  • privacy, accessibility, security, and support review results with known exceptions;
  • a public statement of current lifecycle state and a correction contact.

If Goals cannot sustain safe operation, it must stop new collection as appropriate, notify affected users, preserve only required records, offer export where feasible, rotate or revoke credentials, and update its status without implying that another ANUKA product inherits the data. A product success does not automatically justify expanding the shared core.