# Account data for the prototype

Source: examples supplied by Yaya on 2026-09-23, explicitly for this project's
wireframe/high-fidelity prototype. These describe data available for the account
on the web platform; they do not establish endpoint URLs or a complete API contract.

**Messages are inbound only. No compose, reply or outbound-SMS feature.**
Optional forwarding/delivery of incoming SMS to the phone is a separate existing
brief requirement; it does not mean the service supports sending messages.

## SMS payload and interface

| Field | Observed form | Prototype/design handling |
| --- | --- | --- |
| sms_id | String identifier | Preserve as a string; synthetic identifiers in review fixtures. |
| received | Timestamp string, microseconds, no timezone | Newest first; display supplied date/time to seconds and disclose unspecified timezone. Do not silently apply browser-local timezone. |
| source_addr | Shortcode or phone-number string | Sender label; keep as text so shortcodes/leading zeros survive. |
| dest_addr | Phone-number string | Intended recipient, scoped to the selected eSIM. |
| short_message | Arbitrary Unicode text, newlines, URLs, verification-code text | Render as escaped text with preserved line breaks; no automatic HTML or URL activation. Long words wrap. |
| delivered | Timestamp string present in all three supplied examples | Meaning unconfirmed. Do not label Delivered/Failed or claim handset receipt from this alone. |
| dest_imsi | String identifier | Account/eSIM association; keep as a string. |
| dest_tech_addr | String identifier | Retain in fixture contract; no reason to foreground it in the inbox. |
| part_number | Number; all examples are 0 | Multipart grouping semantics are not established. Do not invent concatenation from this field alone. |

Yaya labelled two source examples delivered and one undelivered, yet all three
have a delivered timestamp. The UI therefore says phone delivery is unconfirmed.
Clarify whether that timestamp records receipt, forwarding or an intermediate
handoff before adding delivery filters or success badges. A message's presence
in the website inbox is distinct from its delivery to the phone.

The third message starts with `ԀʹȂps://`. Preserve the received characters. It may
reflect malformed/encoded content, but the payload alone does not prove the cause
or explain failure to reach the handset. Do not automatically repair it into a link.
Messages may contain STOP/reply instructions from senders; the interface must still
make clear that this service cannot send that reply.

The original examples have different recipients and IMSIs. They must not be treated
as one real subscriber's inbox. Local fixtures deliberately substitute the active
sample eSIM's identifiers and synthetic message bodies/URLs/code to demonstrate
layout without reproducing personal messages or usable verification credentials.
Real account scoping must come from authorised data access during integration.

## Subscriber usage payload and interface

Envelope: `usages`, `summary`, `meta`.

- Rows: `Date` is a timezone-unspecified string; `mcc`, `mnc`, `Bytes` are strings;
  `Charge` is numeric; `country` and `network` are strings.
- Sort newest first by supplied timestamp, without inventing a timezone. Parse
  Bytes numerically for display/aggregation; preserve MCC/MNC as identifiers.
- The 50 supplied rows total **954,202,357 bytes** and **0.9272882478551864 charge**.
  Row sums were checked against the supplied summary and match.
- Decimal volume: approximately **954.202 MB**. Binary volume: approximately
  **909.998 MiB**, or **0.888670 GiB**. The API's `total_kb`, `total_mb`, `total_gb`
  use binary division despite their names. Do not label those values MB/GB.
- No currency is supplied. Do not assume USD or add a dollar sign to usage charges.
  Preserve numeric precision internally; the prototype displays six decimal places
  and offers the original value on the row's title. Sum before rounding, not after.
  Small positive charges should not silently look free.
- `meta.rows` and `meta.total_available` are both 50 in this example; do not assume
  every future response is a complete dataset. Keep response/window summary scope
  explicit and avoid double-counting server totals across pages.
- These records span 10–11 September 2026, not a complete 14-day history. The existing
  14-day product requirement remains; the prototype labels this as sample coverage.
- Country/network in the sample: Germany / Telekom Deutschland GmbH, MCC 262, MNC 1.
- The prototype shows a summary and 10 rows per page, with all 50 rows accessible.
  Pagination here is local fixture pagination, not an invented server contract.

## Current implementation and remaining confirmations

Fixtures: `wireframe/sample-account-data.js`. SMS fields mirror the supplied shape
with anonymised content. All 50 usage records and the source summary are retained.
Rendering: `messages()` and `spending()` in `wireframe/app.js`. Data is separated
from rendering for the later high-fidelity prototype and production handoff.
Existing payment examples still use clearly labelled sample USD prices; that is
separate from the unspecified currency in the supplied usage payload.

Before real integration, confirm timestamp timezone, charge currency, delivery
status semantics, multipart association, endpoint scope/authorisation and the
usage filter/pagination/summary contract. These are open contract questions,
not blockers to using the examples for the prototype now. No backend changes.