TABLE OF CONTENTS

• Introduction
• ILAP Terms Across Different Contexts
• Content Control and Ontological Maturity
• Host-Specific ILAP Terms (A Hidden Third Type)
• Configuration and Default Mappings

Introduction

The most fundamental information about an activity includes its planned manhours, the calendar it uses, and the start and finish dates assigned by the scheduling engine (based on its links to other activities in the network). These are often referred to as core fields.

What is not included in these core fields is metadata — information that helps classify or describe the activity in different ways.

Typical examples of such metadata include:

• Location (where the activity takes place)
• Discipline (what domain of work: e.g. Electrical)
• Work Breakdown Structure (WBS)
• ...and any other classification attributes

In IDE, we refer to this type of metadata as an ILAP Term.

ILAP Terms Across Different Contexts

The possible number of ILAP Terms is, philosophically speaking, unlimited. Different industries have very different metadata requirements — for example, the automotive industry may require completely different classifications than the oil and gas industry.

To support this flexibility, we provide a structured way to define and manage ILAP Terms.

1. Level Context

The first distinction is the level at which the metadata applies. IDE currently supports three levels:

• Schedule level
• Activity level
• Resource Assignment level

Each ILAP Term must belong to one of these levels.

2. Scope Context

In addition to level, ILAP Terms are defined within one of two scopes:

Globally Available ILAP Terms

These are created by a System Admin.
They are available to all tenants, although each tenant can decide whether the term should be visible in their own list of ILAP Terms.

Tenant-Specific ILAP Terms

These are created by a Tenant Admin, typically when a required term does not exist in the global list.

A System Admin may later choose to promote a tenant-specific ILAP Term to the global level.

Content Control and Ontological Maturity

Even when an ILAP Term is defined as a Global ILAP Term, it can still be classified according to its level of ontological maturity.

In practical terms, this determines how strictly the values of the term are controlled.

System-Level Terms

A term can be classified as a System-level term, meaning its values are governed by an external standard.

For example:

• Country Codes defined by ISO 3166

In such cases, the ILAP Term should preferably include the standard in its name, for example: ISO3166_Country.

This indicates that the valid values must comply with the ISO standard.

Template or Tenant-Level Terms

Alternatively, an ILAP Term can be classified as:

• Template-level, where valid values are controlled within a specific template
• Tenant-level, where valid values are controlled at Tenant level by the Tenant Admin

This provides flexibility while maintaining structured governance.

Host-Specific ILAP Terms (A Hidden Third Type)

When creating a template, you can select ILAP Terms from:

• The Global list
• Your Tenant-specific list

However, in certain advanced scenarios, you may need more detailed control — for example, when managing how data flows:

• From one Safran schedule to another
• From one P6 schedule to another
• Or between two schedules within the same scheduling tool

In these cases, you can select from a predefined list of Host-Specific ILAP Terms. These terms correspond directly to fields in the API of the relevant scheduling tool and allow very detailed control of data mapping.

Configuration and Default Mappings

When creating a configuration for a template that includes Host-Specific ILAP Terms:

• Default mappings to the corresponding API fields are automatically provided
• These mappings can be overridden if necessary

This ensures both ease of setup and full flexibility where required.