Central Architecture

Why a shared platform

The hard part of reuse is rarely a single utility. It is how capabilities affect each other. A purchase changes what someone may open. Consent changes what analytics and advertising may do. Going to the background changes how sensitive data is handled. An unavailable update must not lock anyone out of an app that still works.

When these decisions are scattered across screens and vendor integrations, every product has to solve them again. CentralArchitecture gives them one home: thirteen foundation services for the operational and policy behaviour, and six add-on engines: AI inference, provider cascade, text input, OCR, speech and assessment.

Shared infrastructure, product freedom

The principle is simple: invest deeply in what products share, and leave products free where they differ. A document app and a learning app can share the same consent and entitlement rules without sharing a screen, a content model or a workflow.

The foundation works with generic identifiers, grants, purposes and usage units, and each product supplies the meaning. Access policy decides whether an action is allowed; the app decides whether that action is opening a premium document or starting a lesson. Paywalls, navigation and branding stay in the product.

Six rings keep it coherent

Responsibilities sit in six rings. Services depend only on lower rings, and the outer runtime builds and connects them, so ownership is visible in both the design and the build.

Ring 0 · Kernel

Shared values and vocabulary: outcomes, errors, namespaces, versions, locale.

Ring 1 · Ports

Contracts for outside capabilities: storage, cryptography, network, clocks.

Ring 2 · Substrate

Shared stateful services: secure storage, integrity, configuration, locale, telemetry.

Ring 3 · Policy

Decisions over state: consent, entitlements, access policy, lifecycle.

Ring 4 · Delivery

Content and commercial orchestration: content delivery, commerce, promotion, updates.

Ring 5 · Runtime

Explicit construction: the runtime wires everything together, with no hidden service locator.

Shared logic is written once in Kotlin. Android uses native Kotlin adapters and Apple platforms use Swift adapters, while each app keeps its own native interface.

Privacy without breaking the design

Telemetry sits below consent, yet sending telemetry depends on consent. Instead of reversing the dependency, the runtime connects consent to a restricted telemetry control. The public event interface cannot give itself permission to send data. Higher-level policy governs a lower-level capability without the two being tied together.

Thirteen foundation services

Secure storage

Encrypted, namespaced storage with schema migration, export and erasure.

Integrity

Checksums and signatures prove an artifact is intact and from a trusted publisher.

Configuration

Bundled defaults, cached values and signed remote updates, adopted atomically.

Locale

Shared catalogue lookup, plurals, fallback, right-to-left layout and exact number formatting.

Consent

Consent by purpose, policy version and region; non-essential purposes default to off.

Entitlements

One grant model for ownership, source, expiry and revocation.

Access policy

One decision chain for kill switches, entitlements, trials and preview quotas.

Lifecycle

Foreground, background, idle and re-authentication under one privacy policy.

Telemetry

Consent-gated analytics: withdrawal stops dispatch and clears what was buffered.

Content delivery

Signed, versioned content installed atomically, with rollback and an optional protected profile.

Commerce

Purchases and restores, where only a validated receipt can grant access.

Promotion

Advertising only when consent, ad-free ownership, caps and cooldowns allow it.

Updates

Run, warn or force, and never a forced block offline or on an untrusted clock.

Six add-on engines

Each app adds only the engines it needs, and the foundation does not depend on any of them. An excluded engine leaves no SDK or code behind in the app.

AI inference

Model-backed tasks with a provider registry and explicit tier policy.

Provider cascade

Ordered fallback across providers, within health, backoff and budget limits.

Text input

Turns supported documents into text and pages through one common boundary.

OCR

Text recognition with quality thresholds, so a usable result matters, not just a response.

Speech

Text to speech through selected voices and providers.

Assessment

Scores and explains answers without tying the engine to one curriculum.

Combined, they make the product: text input and OCR for documents, inference for model-backed work, speech for listening, assessment for evaluation. The app owns the customer journey; AI is a capability inside it, not the whole product.

Decisions that make reuse dependable

Every asynchronous call has one owner.

The foundation owns deadlines and cancellation, picks one result and drops late duplicates.

Remote control stays inside trusted limits.

Signed configuration can change values, never add code or widen the app's trust.

The backend is used only where it must be.

Most decisions run on the device; servers are kept for receipt validation and protected content keys.

Failure policy follows the consequence.

A forged file is never trusted and an unvalidated purchase never grants access, but an unreachable update policy never blocks launch.

The architecture can be inspected.

An Inspector shows each service's decisions, including rejections, with fake adapters for hard-to-reproduce conditions.

Apps, the foundation, configuration and content each have their own version line, so products can move at different speeds. Knowledge about privacy, transactions and failure recovery has a lasting home across every app built on it.