AENET ecosystems PUBLIC GATEWAY
Request a Pilot
GATEWAY READY
EN ไทย 中文
system-detail K.PUBLIC.SYSTEM

SYS.INF.04 D04 visit-memory

Visit Memory

Device-local continuity for AENET visitors: preferred locale, last route, visit count and read progress — stored in the browser only and never identifying a person.

Domain: Infrastructure STATUS: active Public boundary: OBSERVATION ONLY Last updated: 2026-08-16
KAP-GRID K.PUBLIC.SYSTEM.C03

System ID

visit-memory

Status

active

Architecture layers

  • L2 Public Application (browser)

Inputs

  • Visitor device state (localStorage)

Outputs

  • Welcome-back / continue offers in the UI

Public interfaces

  • contracts/public-visit-memory.contract.json
  • ui-contract/schemas/visit-memory.schema.json

Connected systems

Security boundary

Never contains name, email, phone, IP, location, fingerprints, account id, private content, keystrokes or clipboard. The two layers (local memory vs server observation) are never joined.

Data direction

Device → localStorage → UI offers. Never to the server, never to the core.

Security

Never contains name, email, phone, IP, location, fingerprints, account id, private content, keystrokes or clipboard. The two layers (local memory vs server observation) are never joined.

What

Make returning to the gateway feel continuous ("Welcome back / Continue →") without ever building an identity.

Why

Personalization usually means tracking. Visit Memory solves this by remembering only preference and continuity on the device, with an explicit forbidden-field list and no server-side identity.

How

Device → localStorage → UI offers. Never to the server, never to the core.

  • Store preferredLocale, lastRoute, lastVisitAt, visitCount
  • Store lastArticleSlug, lastReadPosition, dismissedNotices, uiContractVersion
  • Drop unknown or forbidden fields on read and write
  • Offer continuity — never auto-redirect
  • Stay separate from server observation (Layer B)

Example

A returning visitor sees a "welcome back" or continue offer based on locale and reading position stored locally — no server-side identity.

Inputs

  • Visitor device state (localStorage)

Outputs

  • Welcome-back / continue offers in the UI

Dependencies

aenet-cloud-publicui-contract

Lifecycle

  • Layer A local visit memory
  • Layer B server observation (separate, anonymous)

Use cases

  • A returning visitor sees a continue offer
  • The UI restores locale and reading position locally

Limitations

  • Device-local only — cleared with browser data
  • Never joins with server observation
  • Not an identity system

Connected systems

  • AENET Cloud Public — The public-facing entrance and observation layer for the AENET ecosystem. It publishes sanitized snapshots, static pages, a public API and an anonymous traffic channel — nothing more.
  • AENET Memory — A private AENET Core system for memory. Public evidence is limited to its presence as a private, unreachable topology node (core-memory).
  • UI Contract — The single source of truth for the public UI structure — pages, navigation, components, coordinates, states, motion, colors, typography and locales — consumed by both the web and Swift renderers.

Related research

  • The Public Observation Model — Why the public side is an observation layer, and how anonymous traffic becomes a sanitized signal without becoming a control surface.

Questions people ask

These questions are answered by the content on this page.

  • What is AENET Visit Memory?
  • Is Visit Memory an identity system?
  • What does Visit Memory store?
  • How is Visit Memory kept private?

Evidence

Verified states only — nothing on this page is a prediction.

  • contracts/public-visit-memory.contract.json
  • web/assets/js/visit-memory.js
  • docs/VISIT_MEMORY.md

Next step