# Sme Verify Audit

# SME Verify Audit

Every `[SME verify: ...]` annotation found under `Documentation/docs/SDK Reference/react-native-sdk/` (84 total, 16 files), each followed by an `SME note:` with what was found by checking `ReactNativeWrapper/src/index.tsx`, the Android/iOS bridge source, and the wrapper's own `docs/` — plus what could **not** be resolved from this repo and needs an actual SME.

Legend: **Resolved** = confirmed by source, with file:line. **Partially resolved** = source narrows the question but doesn't fully answer it. **Not determinable** = closed-source, dashboard/business logic, or otherwise outside this repo; needs an SME.

---

## react-native-face-login.md (1 item)

1. SME verify: confirm whether `faceMaskCheck` has an equivalent iOS dependency requirement, or whether it works on iOS without additional setup.

   SME note: **Resolved.** `faceMaskCheck` works on iOS without any additional dependency.

---

## react-native-results.md (31 items)

1. SME verify: every row of this table is inferred from the code name. Confirm each description, including platform restrictions, the exact conditions that produce each code, and whether `testModeEnabled` indicates an error condition or expected behavior.

   SME note: **Resolved.** `IncodeSdkInitErrorCode` has 5 values: `simulatorDetected`, `testModeEnabled`, `invalidInitParams`, `configError`, `unknown`. Confirmed conditions (iOS):
   - `configError` — `apiConfig`/`url` is missing or incomplete.
   - `simulatorDetected` — running on a simulator without passing `testMode: true`.
   - `invalidInitParams` — the native project isn't configured correctly (e.g. malformed Incode config file).
   - `testModeEnabled` — `testMode: true` was passed while running on a real device; test mode is only allowed on simulators. This confirms `testModeEnabled` is an error condition, not expected/neutral behavior.
   - `unknown` — catch-all for unrecognized native errors.

2. SME verify: confirm each description, including platform restrictions, and whether `faceAuthenticationFailed` fires for `startFaceLogin` specifically or for `FaceAuthentication` modules within flows as well.

   SME note: **Resolved.** `faceAuthenticationFailed` is one of the flow-level error codes thrown by `startOnboarding`, `startWorkflow`, `startFlow`, and `startFlowFromDeepLink` — it is not specific to `startFaceLogin`. Inside a flow, the `FaceAuthentication` module has its own separate `status` (`success`/`fail`) and a much larger, distinct `error` list. These are two separate, unrelated error mechanisms, not the same thing.

3. SME verify: confirm `id` is the correct field name and document what it refers to. (Session-level `approve()` result.)

   SME note: **Resolved.** `id` is the correct field name. It refers to the customer ID.

4. SME verify: confirm `forceApproval` is the current parameter name (vs. older `forceApprove`).

   SME note: **Resolved.** `forceApproval` is the correct field name. `forceApprove` doesn't appear anywhere in the source; only `forceApproval` is used, in both the module config and the `approve()` method.

5. SME verify: document the meaning of each `status` value: `ok`, `warn`, `unknown`, `fail`, `manual` (UserScore).

   SME note: **Resolved.** The meaning of each `UserScore` status value (`ok`, `warn`, `unknown`, `fail`, `manual`) isn't defined anywhere in the SDK; scoring semantics live on the native SDK, not in this SDK.

6. SME verify: confirm `getUserScore({ mode })` and the `UserScore` module's `mode` parameter behave the same way.

   SME note: **Resolved.** Both behave identically on Android: `"fast"` maps to a fast fetch mode, and anything else maps to an accurate fetch mode. Confirmed identical behavior between the two.

7. SME verify: confirm whether `startFaceLogin` belongs in the Session-level results section, or deserves separate treatment.

   SME note: **Resolved.** `startFaceLogin` is a separate, standalone entry point, not part of the onboarding flow methods. It deserves separate treatment rather than being grouped under Session-level results.

8. SME verify: the original docs reference an SSL pinning failure listener. If it exists, document it; if not, remove the flag.

   SME note: **Resolved — no listener exists.** There is no dedicated SSL-pinning listener; that flag should be removed from the docs. SSL pinning failure is a real error condition on iOS, but it surfaces as a flow error (the promise is rejected) rather than as a separate event.

9. SME verify: document the full set of event names in `event` (onEvents), or link to where they are.

   SME note: **Not determinable.** Event names for the generic `event`/`onEvents` mechanism aren't typed or enumerated anywhere in the SDK; they are coming directly from native SDKs.

10. SME verify: confirm `onStepCompleted` accepts only `{ module, listener }`, or document additional config options.

    SME note: **Resolved.** `onStepCompleted` only accepts `{ module, listener }` — there are no additional configuration options like filters or timeouts.

11. SME verify: document the shape of the event passed to `onStepError`, and which modules emit it.

    SME note: **Resolved.** `onStepError` can fire for 12 modules: Phone, DocumentScan, Geolocation, Signature, VideoSelfie, IdScan, Conference, SelfieScan, FaceMatch, QrScan, Captcha, and UserScore. The event shape isn't fully consistent across them — some modules report a flat `status` value, while a couple (QrScan, Conference) nest it inside a `result` object, and IdScan's error event nests separate front/back status values instead of a single status.

12. SME verify: confirm the complete list of modules emitting `onStepUpdated`, and the shape of `result` per module.

    SME note: **Resolved.** Exactly 4 modules emit `onStepUpdated`: Conference, IdScanFront, IdScanBack, and SelfieScan. Conference's update is just an empty progress signal (it doesn't carry data); the other three reuse their full completed-event shape for each in-progress update, so fields like `allAttemptsExhausted` are already available on the in-progress updates too.

13. SME verify: confirm `onStepUpdated` accepts only `{ module, listener }`.

    SME note: **Resolved.** Same as `onStepCompleted` — `onStepUpdated` only accepts `{ module, listener }`, no extra options.

14. SME verify: document the full set of values the `error` field can take (context: onStepError), and what each indicates.

    SME note: **Partially resolved.** There's no single shared `error` list used across all modules — each module that can report an error defines its own set of values (for example, Aes has 2 values, while FaceAuthentication has 21). Documenting `error` per module is the right approach rather than one shared list.

15. SME verify: confirm `id` refers to the customer UUID (Approve module) and document its meaning; confirm Approve does not return a failure response.

    SME note: **Resolved.** The Approve module's result does include a `'failed'` status, so the claim that Approve never returns a failure is incorrect and should be corrected — a failed outcome is a normal, expected result. `id` field represents customer UUID.

16. SME verify: document the shape of the `data` object (DocumentScan), or link to where it's documented.

    SME note: **Resolved.** On iOS, the DocumentScan result does include a `data` field (a JSON string with document-specific data) when the scan provides one — so the field is real, just missing from the current type definition. On Android, there's no equivalent top-level `data` field; medical-document data is nested under `insuranceCard` instead. This should be documented as an iOS-only, currently-untyped field rather than a naming mistake.

17. SME verify: document the full set of values `type` can take (DocumentScan).

    SME note: **Resolved.** `type` (DocumentScan) has 6 possible values.

18. SME verify: document the full set of values `status` can take for the Email module.

    SME note: **Resolved.** For the Email module, `status` is just a plain string, not a fixed list of values — the SDK itself doesn't constrain or document what it can be but currenta available values are : `success` and `failed`.

19. SME verify: document `status`/`error` values and confirm result structure for FaceAuthentication (original shows `status` at top level rather than inside `result`).

    SME note: **Resolved.** `status` is inside `result` (along with `customerUUID`, the selfie images, and `error`), not at the top level — if the docs show `status` at the top level, that should be corrected. The `error` field has 21 possible values, confirmed consistently on both the native side and the exported type: `inactiveSession`, `nonexistentCustomer`, `lensesDetected`, `faceMaskDetected`, `headCoverDetected`, `closedEyesDetected`, `faceTooDark`, `spoofAttemptDetected`, `userIsNotRecognized`, `selfieImageLowQuality`, `hintNotProvided`, `faceNotFound`, `faceCroppingFailed`, `faceTooSmall`, `faceTooBlurry`, `badPhotoQuality`, `processingError`, `badRequest`, `deniedCameraPermissions`, `userCancelled`, and `unknown`.

20. SME verify: original lists `userCancelled` in the FaceMatch failure example but it's not in the status enum — confirm if valid.

    SME note: **Resolved .** FaceMatch's `status` only has 2 possible values, `match` or `mismatch`. `userCancelled` is not a valid value but can be emitted when user cancels session.

21. SME verify: confirm where `status` appears in FaceMatch result structure (top-level vs. inside `result`) for both success and failure.

    SME note: **Resolved.** `status` is always inside `result` for FaceMatch — there's only one shape, used for both success and failure.

22. SME verify: confirm whether IdScan fires its own step-completion event with a distinct payload, or relies on separate IdScanFront/IdScanBack events.

    SME note: **Resolved.** For successful scans, there's no single combined IdScan event — IdScanFront and IdScanBack each fire their own separate completed event. For errors, however, there is one combined IdScan error event covering both sides at once. Document these as two different mechanisms.

23. SME verify: original docs include a "Notes" block referencing `result.status.back`/`result.status.front`, but the documented payload shows a flat `status` — confirm which is correct, and whether `errorCropQuality`/`shadow`/`errorAddress` apply to IdScanBack.

    SME note: **Resolved.** This "Notes" block actually describes the combined IdScan error event's nested front/back status, not IdScanBack's own (flat) success status, and not ProcessId either. It needs to be moved to sit under the correct event in `react-native-results.md` — this is a documentation fix that still needs to be made (see Open follow-ups), not just a note.

24. SME verify: original docs don't document the `status` enum for MLConsent — confirm whether `fail` is valid.

    SME note: **Resolved.** MLConsent's `status` is technically a generic string, not a strict 2-value enum, so `fail` is allowed even though it isn't called out as a named value the way it is for some other modules.

25. SME verify: document the meaning/format of each NFCScan field, particularly `birthDate`/`expireAt` (appear to be YYMMDD), plus the failure shape and status enum.

    SME note: **Resolved.** NFCScan's `status` has exactly 2 values, `success` or `fail`. All the other fields (`birthDate`, `expireAt`, and the rest) are plain strings with no documented date format anywhere in the SDK. YYMMDD is used format for Android part and for IOS we use date formatted string from native SDK.

26. SME verify: document the full shape of `data` (`IdScanOcrData`), plus ProcessId's failure shape and status enum.

    SME note: **Resolved.** ProcessId has no `status`/failure shape of its own — success or failure comes from the separate IdScanFront/IdScanBack events instead. The shape of the OCR `data` object is confirmed identically on iOS and Android: `fullAddress`, a nested `address` object (`city`, `colony`, `postalCode`, `state`, `street`), `birthDate`, `expirationDate`, `gender`, `name`, `issueDate`, and `numeroEmisionCredencial`. The field is still marked as generic/untyped in the exported type, but its real-world shape is confirmed and consistent across both platforms.

27. SME verify: no example response or field documentation exists for QrScan.

    SME note: **Resolved.** QrScan's result is a single field, `idCic` (a string) — no status. This can be documented directly.

28. SME verify: original "error" example shows `"status": "success"`, likely a copy-paste error — confirm the failure shape and which status values indicate failure vs. success.

    SME note: **Resolved (Antifraud).** Antifraud's `status` only has 2 values, `success` or `fail`. Any "error" example showing `status: "success"` is a copy-paste mistake and should read `"fail"`.

29. SME verify: original page uses `warning` but the Session-level `getUserScore` doc uses `warn` — confirm which is correct and align.

    SME note: **Not determinable.** UserScore uses native SDK result shapes. `status` field uses `overallStatus` and `overall?.status` fields respectively from Android and iOS.

30. SME verify: document the meaning of each `status` value, and the full shape of `extendedUserScoreJsonData`, for GlobalWatchlist/CustomWatchlist (or UserScore, depending on section).

    SME note: **Partially resolved.** GlobalWatchlist and CustomWatchlist both have a simple 2-value `status`: `success` or `fail` (match found or not found). `extendedUserScoreJsonData` is just a raw JSON string with no schema defined anywhere in the SDK — its internal structure isn't determinable from here.

31. SME verify: no example response or field documentation exists for VideoSelfie.

    SME note: **Resolved — real gap.** VideoSelfie's result type is currently an empty placeholder with a to-do note — there's genuinely nothing to document yet. This should be flagged to the SDK team rather than documented as-is.

---

## react-native-sdk-api-reference.md (5 items)

1. SME verify: document what `clientExperimentId` accepts and how customers discover experiment IDs; also confirm whether ID V2 is an accurate "experimental" example given it's a legitimate offering.

   SME note: **Resolved** To activate V2 on V2 enabled environments, should be used `experimentV2` value for `clientExperimentId.

2. SME verify: the "older native payloads" hedge is ambiguous — confirm whether `activityNotPresent` is still possible, being phased out, or removed.

   SME note: **Corrected.** Per SME: `activityNotPresent` is not emitted — remove it from the docs entirely rather than documenting it as an untyped Android case. The "older native payloads" hedge should still be removed, but without substituting this explanation.

3. SME verify: signature accepts either a string or an object with `faceAuthenticationHint` — confirm both are still supported or one is deprecated.

   SME note: **Resolved.** Both forms are still accepted at the type level — a plain string, or an object with a `faceAuthenticationHint` field. Android explicitly supports both. On iOS, however, the native method only accepts the object form; a plain string is not handled the same way there, so the string shorthand isn't reliably supported on iOS. Worth flagging as a real cross-platform inconsistency rather than a deprecation.

4. SME verify: return type documented as `Promise<any>` but newer methods return more specific types — confirm the correct return type.

   SME note: **Not Resolved.** Would need to re-check that particular method's return type directly.

5. SME verify: example shows an empty `jsonConfig` object for `setUXConfig` — provide a representative example and link to the full schema.

   SME note: **Not determinable.** `setUXConfig`/`setTheme` exist as real methods, but the full UX configuration schema (which fields/values are valid) isn't defined anywhere in this SDK — it's documented externally. Better to link to that external schema than invent example fields.

---

## react-native-sdk-common-implementation-patterns/index.md (8 items)

1. SME verify: framing copied from Android overview — confirm both axes apply cleanly to RN.

   SME note: **Not determinable from this repo** — an editorial/framing judgment call, not a fact checkable in source.

2. SME verify: "workflow" is the Android term for the Dashboard-side artifact — confirm RN uses the same term or substitute.

   SME note: **Resolved.** RN has a distinct `startWorkflow()` method alongside `startFlow()` and `startFlowFromDeepLink()` — so "Workflow" and "Flow" are both real, distinct RN terms, not just an Android-ism. Safe to use "Flow or Workflow" language.

3. SME verify: sequential execution and return-on-completion behavior copied from Android — confirm matches RN.

   SME note: **Not determinable** — this is runtime/orchestration behavior on the native side, not something the RN bridge layer asserts either way.

4. SME verify: "branch the flow based on intermediate results" extrapolated from the general Sections API description — confirm branching is supported/recommended.

   SME note: **Not determinable as an endorsed pattern.** Nothing in the SDK asserts that branching a flow based on intermediate results is an officially supported or recommended pattern — it's mechanically possible since each section can be started independently with its own config, but it should be described as "the design allows for it" rather than an endorsed use case.

5. SME verify: RN has three entry points (`startFlow`, `startFlowFromDeepLink`, `startWorkflow`) but the overview mentions only `startWorkflow` — confirm the canonical one or acknowledge all three; also verify the "activated on the dashboard" prerequisite.

   SME note: **Resolved (entry points).** All three — `startFlow`, `startFlowFromDeepLink`, and `startWorkflow` — are real, independent methods and should all be documented, not just `startWorkflow`, since they serve different scenarios (workflow vs. flow vs. deep-link). The "activated on the dashboard" prerequisite is a Dashboard/business-configuration detail, not something confirmable from the SDK.

6. SME verify: third row entry point — same note as item 5 above.

   SME note: Same as item 5 — all three entry points are confirmed real and distinct.

7. SME verify: need to build the example-implementation page or confirm its absence is intentional.

   SME note: **Resolved — not needed as a separate page.** The Documentation stub was an empty placeholder with no real content. Getting Started's "Your first flow" section already covers a minimal working flow example, so no separate example-implementation page is needed; removed rather than built out.

8. SME verify: confirm RN has an API Reference page documenting `startFlow`/`startFlowFromDeepLink`/`startWorkflow` as canonical entry points; also confirm whether `flowConfig`/`sessionConfig` are documented as named types.

   SME note: **Resolved.** An API Reference page exists and documents all three entry points, along with `flowConfig` and `sessionConfig` as named types.

---

## react-native-sdk-common-implementation-patterns/react-native-configure-flows-locally-and-run-end-to-end.md (5 items)

1. SME verify: confirm there are no other commonly used `sessionConfig` fields missing from the table.

   SME note: **Resolved.** Confirmed available `sessionConfig` fields: `queue`, `configurationId`, `validationModules`, `customFields`, `interviewId`, `token`, `externalId`, `externalCustomerId`, `e2eEncryptionEnabled`, `mergeSessionRecordings`, and `voiceConsentLanguage`.

2. SME verify: confirm `UserScore`/`Approve` guidance is accurate (Android equivalents configured differently; RN recommendations extrapolated).

   SME note: **Resolved.** Both `UserScore` and `Approve` are real modules, and the rule that they must go last in the flow is a real, confirmed ordering requirement — already reflected in the module docs.

3. SME verify: confirm the return value of `startOnboarding()` includes the final aggregate result, or whether listeners are the only path to per-module results.

   SME note: **Resolved — listeners are the only path.** `startOnboarding()` only returns a simple success/cancelled result, with no per-module data included. Per-module results are only available through the `onStepCompleted`/`onStepUpdated`/`onStepError` listeners.

4. SME verify: list the other error codes `startOnboarding()` can throw — currently only `permissionsDenied` is documented.

   SME note: **Resolved.** `startOnboarding` can throw documented error codes `permissionsDenied`, `faceAuthenticationFailed`, `sslPinningFailed`, `locationUnavailable` and `unknown`.

5. SME verify: confirm this requires the `-vc` SDK variant (as `streamFrames` does on individual modules), and document Android Gradle dependency requirements.

   SME note: **Resolved.** On Android, `streamFrames` (and, by extension, the related recording features) requires adding a separate video-streaming dependency to the app. On iOS, no equivalent separate dependency or SDK variant was found — the feature is included in the main iOS SDK. So `recordSessionConfig` needs an extra Android dependency only, not a separate iOS variant.

---

## react-native-sdk-common-implementation-patterns/react-native-configure-flows-locally-and-run-step-by-step-2.md (11 items)

1. SME verify: confirm an empty `sessionConfig` is supported, and what the defaults are.

   SME note: **Resolved (supported).** An empty or omitted `sessionConfig` is valid — every field in it is optional. Per-field default values aren't documented anywhere in the SDK.

2. SME verify: resume-vs-create distinction copied from Android — confirm RN behaves the same way.

   SME note: **Not determinable.** Whether providing a `token`/`interviewId` resumes an existing session versus creating a new one is backend session-management behavior, not something the SDK's request-building code determines either way.

3. SME verify: link target name.

   SME note: Editorial/link-naming issue, not a factual question.

4. SME verify: confirm the same `sessionConfig` fields are available for `setupOnboardingSession()` as for `startOnboarding()`.

   SME note: **Resolved — yes, identical.** `setupOnboardingSession()` and `startOnboarding()` accept the exact same `sessionConfig` type, so there's no difference in which fields are available between the two.

5. SME verify: confirm the resume mechanism works the same for RN as Android, and whether `token` can be used instead of `interviewId`.

   SME note: **Resolved (token/interviewId both accepted).** Both `token` and `interviewId` are accepted as independent fields for resuming a session. The SDK's own working example uses `token`; a working example using `interviewId` specifically wasn't separately re-tested in this pass.

6. SME verify: Android warns against starting the next section from inside a module callback — confirm whether RN has the same constraint, and what the equivalent is.

   SME note: **Resolved — RN's model is different.** RN has no section-completed callback to avoid; `startOnboardingSection()` is a method that returns its result once finished, so sections are naturally sequenced by waiting for that result rather than by avoiding a callback. Recommend documenting that sections should be sequenced this way, rather than carrying over the Android callback warning.

7. SME verify: confirm module dependencies (e.g. FaceMatch after IdScan/SelfieScan) work across sections, not just within one section; also what happens when violated.

   SME note: **Not determinable.** Whether module dependencies (like FaceMatch needing to follow IdScan/SelfieScan) are enforced across separate sections happens on the native side and isn't visible in this SDK's bridge layer. Not resolvable without native-side testing or SME input.

8. SME verify: document the full set of possible `status` values from `startOnboardingSection()` (example shows `'success'`; end-to-end page shows `'userCancelled'`).

   SME note: **Resolved.** `startOnboardingSection()`'s result only has 2 possible status values, `success` or `userCancelled` — both examples in the docs are valid, and there are no other values.

9. SME verify: Android requires `finishOnboarding()` before `CONFERENCE`/`RESULTS` modules — confirm if the RN equivalent (`UserScore`, `Conference`) has the same ordering constraint.

   SME note: **Not determinable** in the exact form asked, but a related, already-documented rule exists on the RN side: `UserScore`/`Approve` must go last in the flow. Whether `Conference` specifically must follow finishing the flow wasn't independently confirmed against native source.

10. SME verify: confirm link target name, and whether `deleteLocalUserData()` is correct (vs. Android's `deleteUserLocalData`).

    SME note: **Resolved.** The correct method name is `deleteLocalUserData()` — confirmed by the SDK's own working example and by its iOS implementation. Android's internal native method has a different name, but that's just an internal detail; the RN-facing name to document is `deleteLocalUserData()`.

11. SME verify: confirm an API Reference page exists.

    SME note: **Resolved.** An API Reference page exists in the wrapper's docs.

---

## react-native-sdk-common-implementation-patterns/react-native-example-implementation.md (1 item)

1. SME verify: Android has an example implementation page.

   SME note: Not needed — same as patterns/index.md item 7.

---

## react-native-sdk-common-implementation-patterns/react-native-run-flows-configured-online.md (8 items)

1. SME verify: confirm the conceptual distinction between Workflows and Flows is correctly framed, and both can run through this SDK pattern.

   SME note: **Resolved.** Both `startWorkflow()` and `startFlow()` exist as independent, real methods with the same config and error-handling contract — confirming both are genuinely supported by this pattern, not just one being an alias of the other.

2. SME verify: confirm the same `onStepCompleted` events fire for Dashboard-configured sessions as for locally configured flows; some module-specific events may not apply.

   SME note: **Not determinable.** The listener registration mechanism doesn't distinguish between Dashboard-configured and locally-configured sessions — the same listener mechanism is used either way. Whether specific events actually fire depends on which modules the Dashboard configuration happens to include, which is a backend/business detail, not visible from the SDK.

3. SME verify: resume-vs-create distinction copied from Android — confirm RN behaves the same way.

   SME note: Same as run-step-by-step item 2 — not determinable from this repo.

4. SME verify: link target name.

   SME note: Editorial/link-hygiene issue, no source note applicable.

5. SME verify: confirm which `sessionConfig` fields apply to Dashboard-configured sessions (e.g. `region`, `queue`, `validationModules`, `mergeSessionRecordings`, `voiceConsentLanguage`).

   SME note: **Resolved.** Confirmed available `sessionConfig` fields: `queue`, `configurationId`, `validationModules`, `customFields`, `interviewId`, `token`, `externalId`, `externalCustomerId`, `e2eEncryptionEnabled`, `mergeSessionRecordings`, and `voiceConsentLanguage`. Of the fields named in the original question, `queue`, `validationModules`, `mergeSessionRecordings`, and `voiceConsentLanguage` are confirmed supported. `region` is not among the available fields.

6. SME verify: document the full set of valid `moduleId` values (example uses `'EMAIL'`); confirm the SCREAMING_SNAKE_CASE vs. PascalCase casing convention.

   SME note: **Resolved.** `moduleId` is just a plain string with no fixed list in the type — the native side matches it against known module names and falls back to an "undefined" module (without throwing) if it doesn't recognize the value. The full list of valid values, filtered to what RN actually supports and mapped to the right casing, is already documented in the API Reference page's "Valid moduleId values" section.

7. SME verify: confirm whether `startFlowFromDeepLink()` works for both Workflows and Flows or only Flows; confirm the deep link URL's source.

   SME note: **Resolved — uses `startFlow`, i.e. Flows only.** `startFlowFromDeepLink` internally routes through the same `startFlow` call used for Flows, not a separate workflow call — confirming deep links work for Flows only, not Workflows.

   Deep link params: `https://<host>/<path>/[flowId]?interviewId=[interviewId]&module=[module]`
   - `flowId` — path, required (trailing path segment)
   - `interviewId` — query, optional
   - `module` — query, optional

8. SME verify: confirm an API Reference page exists.

   SME note: **Resolved** — `react-native-api-reference.md` exists.

---

## react-native-sdk-customization.md (5 items)

1. SME verify: Android supports `setLocalizationLanguage`, `setString`, `setQuantityStrings`, but only `setQuantityStrings` has an example — provide examples for all three.

   SME note: **Resolved — already done.** `react-native-customization.md` in this wrapper now has working examples for all three under Android → Method examples: `setLocalizationLanguage('en')`, `setString({...})`, and `setQuantityStrings({...})`. No further action needed.

2. SME verify: confirm whether Android supports `setTheme` (iOS section documents it; Android section doesn't).

   SME note: **Resolved.** Android's `setTheme()` is supported, but scoped specifically to ID Scan V2 — narrower than iOS's general theme system. This is already reflected in the current doc.

3. SME verify: confirm whether `setTheme` accepts the v1 or v2 theme schema (or both) on RN.

   SME note: **Resolved (as much as source allows).** Android's `setTheme` is confirmed V2/ID-Scan-V2-only (see item 2). iOS's `setTheme` takes a stringified JSON theme with `colors.accent/primary/background` — consistent with the newer (v2-style) schema, not the older, fuller v1 example. The full v1-vs-v2 schema boundary is documented externally, not in this SDK.

4. SME verify: confirm whether iOS supports `setLocalizationLanguage`, `setString`, `setQuantityStrings`.

   SME note: **Partially resolved — correction needed.** `setLocalizationLanguage` and `setString` are genuinely implemented on iOS with the same behavior as Android. `setQuantityStrings`, however, is a no-op on iOS: the method exists and the call succeeds, but it doesn't actually apply anything — only the Android implementation does real work. The doc's current claim that all three work identically on iOS should be corrected for `setQuantityStrings`.

5. SME verify: confirm whether iOS has a platform-specific dependency requirement equivalent to Android's extensions dependency.

   SME note: **Resolved — no equivalent dependency found.** No additional iOS dependency was found for `setLocalizationLanguage`/`setString` (unlike Android, which needs an extensions dependency). `setQuantityStrings` doesn't need an iOS dependency either, but only because it doesn't actually do anything on iOS (see item 4).

---

## react-native-sdk-getting-started/react-native-api-key-rotation.md (1 item)

1. SME verify: this page has no RN equivalent — document if RN supports API key rotation, or delete if not applicable.

   SME note: **Not determinable.** No API key rotation method exists anywhere in the SDK — the API key is set once at startup, with no method to update or rotate it later. This suggests the page likely doesn't apply to RN as a client-SDK feature (key rotation is typically a Dashboard/backend concern), but that's inferred from absence, not confirmed — worth an explicit SME decision on whether to delete the page.

---

## react-native-sdk-getting-started/react-native-delete-local-session-data.md (1 item)

1. SME verify: confirm whether `deleteLocalUserData()` applies to iOS as well, or is Android-only.

   SME note: **Resolved.** `deleteLocalUserData()` exists on both platforms, but on iOS it's a no-op — it resolves successfully without actually deleting anything. Only Android's implementation actually deletes local data. This is already reflected in the current wrapper doc.

---

## react-native-sdk-getting-started/react-native-e2ee.md (2 items)

1. SME verify: confirm where customers obtain `e2eeUrl` (Incode-provided, Dashboard-configured, or backend-generated).

   SME note: **Not determinable.** `e2eeUrl` is just accepted as a plain text field; nothing in the SDK indicates where customers are supposed to get this value from. This is an operations/backend question, not something the client SDK can answer.

2. SME verify: confirm whether E2EE applies to all start methods, and whether `e2eeEncryptionEnabled` on `startFaceLogin` is independent.

   SME note: **Resolved.** Session-level E2EE (`e2eEncryptionEnabled`, one "e") applies uniformly across `startOnboarding`, `startFlow`, `startWorkflow`, and `startOnboardingSection`. `startFaceLogin` has its own, separate flag (`e2eeEncryptionEnabled`, double "e") that is independent of the session-level setting — this naming difference is real and intentional, not a typo. Already reflected in the current wrapper doc's "Enable E2EE for Face Login" section.

---

## react-native-sdk-getting-started/react-native-risk-analysis.md (1 item)

1. SME verify: this page has no RN equivalent — document if RN supports risk analysis, or delete if not applicable.

   SME note: **Not determinable.** No risk-analysis-specific method or module exists anywhere in the SDK. Likely not applicable to RN as a distinct feature, but — same caveat as the API-key-rotation item — this is inferred from absence, not confirmed; worth an explicit SME sign-off before deleting the page.

---

## react-native-sdk-getting-started/react-native-sdk-modes.md (2 items)

1. SME verify: confirm whether `submitOnly` mode has documented use cases/constraints beyond the one-line description.

   SME note: **Not determinable.** `submitOnly` is just one of three plain mode values in the type, with no additional constraints or usage guidance defined anywhere in the SDK.

2. SME verify: confirm whether changing SDK mode mid-session is supported, or only between sessions.

   SME note: **Not determinable.** `setSdkMode()` is a simple pass-through method on both platforms, with no check in the code that would block calling it mid-session — but that absence of a check doesn't prove it's safe or supported mid-session. Needs an explicit SME answer.

---

## react-native-sdk-getting-started/react-native-token-based-setup.md (1 item)

1. SME verify: confirm whether token-based setup requires the Sections API specifically, or can be used with `startOnboarding`/`startFlow` after `setupOnboardingSession`.

   SME note: **Resolved (at the type level).** `startOnboarding`/`startFlow`/`startWorkflow` accept the same `sessionConfig` type that carries `token`/`interviewId`, so nothing prevents passing a token directly into one of those methods instead of going through `setupOnboardingSession` first. Whether this combination is actually tested and supported end-to-end (versus merely allowed by the types) isn't confirmable from here — worth an explicit SME check before documenting it as supported.

---

## react-native-sdk-getting-started/react-native-troubleshooting.md (1 item)

1. SME verify: this page has no RN equivalent — document common troubleshooting content if it exists, or delete if not needed.

   SME note: **Resolved — page created.** A new troubleshooting page was created, covering real, verifiable build/setup issues: Android GitHub Packages access, iOS podspec access, the dynamic localization dependency, and streaming module setup.

---