Core concepts

Mobioos rests on one chain. Learn it once and every screen makes sense. Every term is also in the Glossary.

From intent to code, in five links

Ontology → Domain Context → Context Object → Code Parcel → Codebase

This chain connects a business model to concrete locations in your code. It describes meaning and mappings. It does not generate code.

Ontology. The semantic structure of a domain: its concepts and how they relate. Orders, returns, refunds and discounts, and the rules that tie them together. Ontologies are managed in Mobioos Fusion.

Domain Context. An instance of an ontology, applied to your project. It is the working unit you open in a tab, and it holds everything else: context objects, contents, members, statistics and versions.

Context Object. The meeting point between business meaning and code. A context object gathers information around one concept, even when that information uses different words or lives in different tools.

Code Parcel. The code associated with a context object, treated as one unit. A parcel can be a word, a line, a block, a file or a folder, and it can span several repositories and branches within the same project. Your folder structure does not have to mirror your business model.

Codebase. Your code keeps its technical structure. Mobioos adds a business reading on top of it.

Two ways to build a Code Parcel

Inference. The process by which Mobioos AI selects code to form Code Parcels. During scanning in Forge, the ontology behind the Domain Context guides what the AI looks for.

Markers. Code you select by hand and attach to a context object.

They work together. One Code Parcel can combine inferred selections and Markers, and you can correct or refine any inference. The AI accelerates discovery; your team has the final word.

Polarization

Mobioos Fusion captures data from your software factory through connectors, then polarizes it: it filters out the noise and projects what matters onto the semantic structure of your ontologies. That is how a customer ticket and a line of code end up attached to the same business concept.

Polarized information comes in two kinds, and the distinction depends on the information itself, not only on the tool it comes from:

• Endogenous information describes the implementation: a diagnostic tied to a code location, a defect in a function.

• Exogenous information describes usage and intent: a customer ticket, a functional rule, feedback on behavior. Users describe what they see, not which function is involved.

A single ticket can carry both a business symptom and a technical diagnosis.

IP Proof

Business context lives in Fusion. Code mapping runs in Forge, on the developer's machine. Source code is never sent to the Mobioos Fusion SaaS.

How things are organized

Organization
  Teams and members
  Contextualized Project
    Statistics              <- across the project's Domain Contexts
    Repositories            <- a Code Parcel can span them
    Domain Context          <- an instance of an ontology, opened in a tab
      Context Objects
      Contents
      Members
      Statistics
      Versions

A Contextualized Project groups one or more Domain Contexts with the settings they inherit: service connections and Forge scanning configuration.

Feature models, not folder trees

Every context object is typed, Core for the root of the domain and Functionality for what the product does, and carries two rules:

• Rule, whether the element is mandatory or optional

• Children rule, how its children combine, for example All (And)

That lets a Domain Context express variability and obligation, not just hierarchy. Details in Domain Context.