Objects vs. Object Types: Blueprint vs. Instance

A fundamental guide for architects on the crucial difference between Object Types (the design blueprint) and Objects (the live data instance).

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.

The Analogy: The Cookie Cutter & The Cookie

Imagine you are a baker.

The Cookie Cutter is the Object Type

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 Object

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:

Feature	Object Type (The Blueprint)	Object (The Instance)
What it is	A reusable template or a class definition.	A unique data record.
Where it lives	Designed and managed inside a 📋 Function.	Created and managed inside a ⏹️ Space.
What it contains	A Workflow, Data Fields, and Screen Layouts.	Specific values for those fields (e.g., “John Doe”, “$5000”).
Example	The “Sales Deal” blueprint.	The “Q3 Acme Corp Deal” with a value of $50,000.
Quantity	One per business concept in a Function.	Potentially thousands created from one Object Type.
Analogy	The 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.

• Ready to build your first blueprint? → [Learn How to Create and Manage Object Types](/en/02-platform/platform-overview/universal-object/creating-object-types