Public Architecture And OSS Boundary¶
Mozaiks is intentionally layered around one public canonical application model:
AG2
-> Mozaiks OSS framework and canonical app contracts
-> factory_app as the OSS reference canonical app
-> proprietary canonical apps such as App Zero
-> optional operator and learned-intelligence layers
The public framework must remain useful without a BlocUnited-hosted service. A self-hosted developer should be able to understand, generate, validate, refine, run, and extend one canonical application from local source and public contracts.
Core Invariants¶
- Different intelligence, same canonical app.
- OSS remains genuinely useful and self-hostable.
factory_appremains capable of generating useful apps without BlocUnited services.- Proprietary canonical apps consume the public
mozaikspackage instead of a private framework fork. - Community improvements to generic framework behavior benefit every canonical app when it advances its OSS dependency.
- Operators may keep accumulated knowledge, learned strategy, eval evidence, production operations, and managed-service implementations outside OSS.
- Dynamic AI reasoning is bounded by deterministic canonical application contracts.
What Canonical Means¶
Canonical does not mean an app was generated byte-for-byte by Factory. It means the app conforms to Mozaiks public runtime and artifact contracts:
- app manifest and app bundle declaratives
- module/action contracts
- page and shell contracts
- workflow contracts
- data, secret, auth, and capability contracts
- event/reaction contracts and provenance
- validation and generated-bundle contracts
- public app-local dispatch contracts
The canonical structure is documented in Canonical App Structure.
Dogfood Applications¶
factory_app is the OSS reference canonical application. It proves the public framework can host a serious builder application locally using the same workspace shape, modules, pages, workflows, build contexts, validation, and runtime contracts available to other apps.
App Zero, the proprietary Mozaiks application, is also a canonical application. It may contain proprietary modules, workflows, provider execution, business logic, production credentials, and operator intelligence, but its generic framework needs should flow through stable public contracts in mozaiks.
Framework, Application, Operator¶
| Layer | Owns |
|---|---|
| Framework | Runtime hosts, canonical contracts, validation, baseline Factory, App Intelligence, AG2 adapters, provider-neutral capability contracts |
| Canonical application | App-owned modules, pages, workflows, data, config, services, overlays, and business behavior |
| Operator or hosted platform | Production execution, credentials, managed-provider implementations, cross-customer learning, commercial operations, and stricter policy |
Framework contracts must be strong enough that applications can remain portable. Operator layers may add stricter policy or better strategy, but they should not silently fork generic framework behavior.
Public Extension Rule¶
OSS opens the ability to understand and build one application. Publication of what an operator learns from understanding or operating many applications requires deliberate review.
That means generic mechanisms can be open while accumulated datasets, evaluation results, learned rankings, production outcome correlations, and customer-derived heuristics remain operator-owned unless explicitly approved for publication.
Community Flywheel¶
Keeping the baseline strong is intentional. Contributions to runtime behavior, schemas, validators, AG2 adapters, build-context contracts, baseline Factory, App Intelligence, provider-neutral capability contracts, and workflow patterns should improve all canonical apps. Proprietary canonical applications should get those improvements by advancing their public OSS dependency pin, not by carrying a private framework fork.