Pin JSON-LD Context Loading for Local Android AI

Direct answer

Valid JSON is syntax, not JSON-LD processing. A JSON-LD processor interprets `@context`, expands terms, resolves references, and can invoke a document loader. An imported file or generated payload may therefore cause a remote context lookup or further loading through `@import`. That hidden dependency changes reproducibility and data flow for an offline task. Confirm the feature needs JSON-LD semantics; for a fixed object, a bounded JSON parser and application schema may be sufficient. The W3C JSON-LD 1.1 syntax and processing API define remote contexts, imported contexts, base-URL handling, and processor errors. Its document-loader callback lets an implementation control retrieval; it does not define an Android library or networking stack. A context may reference another remote context, with relative URLs resolved against the containing context document URL. JSON-LD 1.1 processes an `@import` context before its wrapper; if the imported context itself contains `@import`, that is an invalid context entry, not an arbitrary import chain. Inspecting only the top-level `@context` does not reveal the full load graph. For strict offline processing, use the exact shipped JSON-LD processor and resolved version, then configure its supported loader hook with a local allowlist. Map each permitted absolute URL to reviewed bytes, a version label, and a digest. Reject unmapped URLs; never fall back to HTTP, a default loader, DNS, or a browser cache. If the library cannot control its default loader, offline behavior remains unknown. A digest confirms byte identity with the selected record; it does not certify context semantics, safety for every input, or endorsement by a vocabulary owner. Treat the load graph as input. Record requested and final document URLs, content type, digest, and loader decision. A strict offline policy can reject redirects and serve only pinned artifacts. JSON-LD 1.1 ignores `@base` when processing a remote context; preserve its original document URL and base metadata when serving local bytes, since substituting a local path can change relative-reference resolution. Bound total bytes, loader calls, distinct documents, processing depth, elapsed time, and expanded nodes. The API applies a processor-defined limit to remote-context tracking entries and reports context overflow; it does not set product byte or time budgets. Test the actual processor instead of assuming common defaults. Do not call every remote-context revisit a cycle error. JSON-LD 1.1 replaced an earlier recursive-inclusion error with `context overflow`, because scoped contexts can legitimately reload. The algorithm tracks remote-context entries and enforces a processor-defined limit; the array is not guaranteed to count unique URLs only. A separate `cyclic IRI mapping` error concerns term-mapping dependencies. A stricter closed-graph rule is valid as product policy, not a W3C requirement. Preserve the document URL and base metadata when serving pinned local bytes. Bound calls, unique documents, response bytes, depth, time, and expanded output; a URL-entry cap alone is insufficient. A digest change requires a deliberate context-version update and fixture rerun. Validate expanded or compacted output against the application fields. A valid context does not authorize a command, path, network destination, or model action. Preserve source identity and loader trace without logging private payloads. Missing or mismatched bytes, unknown URLs, exceeded limits, and malformed documents should fail visibly without network retry. A cached context supports an offline run only if the required graph is complete and the configured processor actually uses that cache. This guide describes a verification contract, not a Cove feature. It does not establish which JSON-LD library, document-loader callback, context set, or remote-fetch behavior exists in Cove. W3C processor semantics are not proof that a particular Android package exposes a suitable hook. Record the dependency coordinates and resolved version, inspect the exact API surface, and test the shipped build with network access denied and loader instrumentation. If that evidence is unavailable, report the behavior as unknown and keep any offline claim out of product copy.

A local import contains an unfamiliar context URL

A user selects a JSON-LD document that references a context hosted outside the app. A previous online test completed, but a travel test with radios disabled fails before the application can validate the expanded fields. The team does not know whether the resolved Android processor uses an injectable loader or silently retains a default network loader.

Decision

Identify the exact processor version, enumerate its context graph, and either satisfy the document through a versioned local allowlist or reject it without a network fallback.

Expected outcome

The import has a deterministic result tied to specific context bytes, or a visible unsupported-context failure; neither result implies that Cove currently implements this import path.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Resolved processor and loader contract
• Versioned context-byte identities
• Offline unknown-URL and recursion fixtures

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Decide whether JSON-LD semantics are needed. Document the accepted input purpose and fields. If the workflow only consumes a fixed JSON shape, parse bounded JSON and validate the app schema rather than adding vocabulary expansion and remote-context behavior.
2. Pin the actual processor and loader API. Record dependency coordinates, resolved version, Android API range, and the exact document-loader hook. Verify that the hook replaces default retrieval. If no controllable loader exists, classify offline behavior as unknown and reject the claim.
3. Build a closed, versioned context map. For each permitted absolute URL, store reviewed context bytes, a version identifier, and a digest. Resolve relative references according to processor rules, reject unlisted URLs and redirects, and never silently download replacements.
4. Bound the complete recursive load graph. Set and test limits for total bytes, loader calls, distinct contexts, processing depth, expanded nodes, duration, and cancellation. Cover nested remote contexts, scoped-context reloads, processor context overflow, cyclic IRI mappings, the invalid nested-`@import` case, duplicate URLs, oversized bodies, and malformed JSON.
5. Validate results and prove the offline path. Check expanded output against the application schema and permission policy. Run the exact packaged build with network access blocked and loader tracing enabled; require every requested document to resolve from the pinned map or fail closed.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The resolved processor and controllable loader API are recorded; an unknown default loader is never described as offline.
• Every accepted URL maps to versioned bytes and a verified digest, with a tested redirect and unknown-URL policy.
• Nested references, `@import`, cycles, processor overflow, byte limits, cancellation, and malformed contexts have explicit tested outcomes.
• JSON syntax, JSON-LD expansion, application validation, authorization, and model behavior remain separate claims.

Decision table

Failure patterns to prevent

• Assuming JSON parsing disables context dereference
• Falling back to a default network loader
• Calling context digests a semantic safety guarantee

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• W3C — JSON-LD 1.1 Syntax
• W3C — JSON-LD 1.1 Processing Algorithms and API
• IETF — RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions