​
The Critical Distinction

To successfully architect solutions in Luklak, you must master one of the platform’s most fundamental concepts: the distinction between an Object Type and an Object. Confusing the two is a common pitfall, but understanding their relationship is the key to designing scalable and maintainable systems.
In the simplest terms:
  • An Object Type is the design or blueprint.
  • An Object is the live data instance created from that blueprint.
Imagine you are a baker. The cookie cutter is the tool you design and create.
  • It defines the shape of the cookie (e.g., a star). This is its Workflow.
  • It defines what decorations you can add (e.g., sprinkles, icing). These are its Data Fields.
  • You design the cookie cutter once in your workshop (the 📋 Function).
  • The cutter itself is not a cookie. You can’t eat it. It contains no dough (no live data).
The cookie is the actual, edible thing you produce using the cookie cutter.
  • It’s a real instance with unique characteristics (e.g., this specific cookie might be slightly browner than the next).
  • It has specific data (e.g., it has red sprinkles, while another has green).
  • You can bake thousands of unique cookies using the same single cutter.
  • The finished cookies are placed on the cooling rack to be managed and sold (the ⏹️ Space).

​
Side-by-Side Comparison

Here is how this distinction applies directly within the Luklak platform:
FeatureObject Type (The Blueprint)Object (The Instance)
What it isA reusable template or a class definition.A unique data record.
Where it livesDesigned and managed inside a 📋 Function.Created and managed inside a ⏹️ Space.
What it containsA Workflow, Data Fields, and Screen Layouts.Specific values for those fields (e.g., “John Doe”, “$5000”).
ExampleThe “Sales Deal” blueprint.The “Q3 Acme Corp Deal” with a value of $50,000.
QuantityOne per business concept in a Function.Potentially thousands created from one Object Type.
AnalogyThe Cookie Cutter.The actual Cookie.

​
Why This Matters for Architects

  • Standardization: By perfecting the Object Type blueprint, you ensure every Object created from it is consistent. This is essential for reliable reporting, filtering, and automation.
  • Scalability: A single, well-designed Object Type can be used to generate millions of Objects across hundreds of Spaces, all without any additional design work.
  • Maintainability: If a business process needs to change, you simply edit the Object Type in its Function. This single change can then be propagated to all live Objects, saving countless hours of manual updates.

​
What’s Next?

Now that you can clearly distinguish the blueprint from the instance, the next logical step is to learn how to create your own blueprints.