Coflyr · Requirements split review

ResourceRequirements

What is needed to perform the work.

92 proposed active fields3 dropped retainedUnder development · HTML proposal

Proposed table: Maintenance.ResourceRequirements
Source: Requirements field decisions and split mapping
Backend / database: Unchanged; adoption after complete review.

This proposal has three requirement tables: resources describe what is needed, time rules describe dates/counter limits, and event rules describe triggers/prerequisites. Common identity, context, source citation and audit properties belong independently to each record; no additional shared requirement table is proposed. Existing source types and requiredness remain visible for review. New rows and migrated references require an explicit destination-aware identity map.

← Model index · ResourceRequirements · TimeRequirements · EventRequirements · TimeRequirementLimit

Independent table review · ResourceRequirements

Review direction: Each table has its own records and identity. Relationships between tables will use EntityLinks. Review one table at a time, including its fields and link roles, before backend adoption. This review preserves earlier field decisions; suggested changes below are pending.

Review item	Current fields	Suggested resolution
Readable name	`RecordName` / `RequirementTitle`	Use one readable requirement title after reconciling any distinct legacy values. Review pending.
Requirement identifiers	`RequirementCode` / `RecordCode` / `ShortcutCode`	Use one requirement code unless a separate identifier has a defined purpose. `ResourceCode` identifies a resource and needs separate review. Review pending.
Compliance controls	`IsMandatory` / `InfoOnly` / `ComplianceLevel`	Choose a consistent representation for Mandatory, Recommended, Optional and InformationOnly; avoid contradictory flags. Review pending.
Source classification	`SourceKind` / `SourceType`	Reconcile the two lists before selecting one classification. Existing enum values must be mapped explicitly. Review pending.
Links to timing and events	`TimeRequirementId` / `EventRequirementId`	Represent these associations through EntityLinks. Define the allowed target, applicability and timing-rule precedence before retiring the proposed lookup fields.
Owner, resource and authority references	Task, programme, part, rotable, competency, provider, publication and authority references	Review each relationship and define its EntityLink role, direction, allowed targets, number of links and history rules. Preserve identity and business meaning when replacing a lookup.
Planned need and actual performance	Quantities, effort, installed quantities, planning and completion fields	Keep the resource need distinct from allocation, installation and accomplishment evidence. Review their placement individually; similar numeric types do not make fields duplicates.

Current backend status: ResourceRequirements remains a proposal. No database change or new link definition has been applied by this review.

Resource example

Connector replacement needs two connector kits, a qualified technician and a test bench. ResourceRequirements records these needs. EntityLinks will associate the resource need with a scheduling rule or a task/event activation rule. The earlier direct-lookup proposals below are retained for review history until their link roles are reviewed. Actual reservations, material requests, allocations and execution evidence remain in their WorkStep workflows.

Effort fields such as DurationHours, MinimumHours and TotalHours describe resource/training quantities. They do not define calendar or aircraft-counter deadlines. CompetencyTemplateId remains only here as Reviewed · Future development.

Identity and naming

3 fields

#	Field	Proposed type / source type	Nullability	Business purpose and source
1	`Id`	`Guid`	Required	Stable identifier for this record. Source: `Requirements.Id`. Common metadata retained independently on each proposed table.
2	`RecordName`	`string?`	Nullable	Records record name for this requirements. Source: `Requirements.RecordName`. Common metadata retained independently on each proposed table.
3	`SequenceNo`	`int?`	Nullable	Records sequence no for this requirements. Source: `Requirements.SequenceNo`. Common metadata retained independently on each proposed table.

Relationships and references

21 fields

#	Field	Proposed type / source type	Nullability	Business purpose and source
1	`ClauseReference` Reviewed	`string`	Required	Identifies the exact clause, paragraph or section establishing this requirement within the selected source publication. `PublicationMasterId` selects the document; this field pinpoints the relevant location. Example: “Section 4.2.1” of a Maintenance Procedures Manual. Reviewed HTML decision; backend/database adoption pending complete review. Source: `Requirements.ClauseReference`. Common metadata retained independently on each proposed table.
2	`CompetencyTemplateId` Reviewed · Future development	`Guid?`	Nullable	Nullable UUID lookup to the primary competency training or qualification template associated with this requirement. Example: a practical-assessment requirement linked to an A320 B1 Qualification template. Reviewed for future development; implementation and backend/database adoption remain pending. Retained only on ResourceRequirements as Reviewed · Future development; implementation and backend/database adoption remain pending. Source: `Requirements.CompetencyTemplateId`. ResourceRequirements only; competency is a resource/qualification requirement.
3	`DefaultTrainingProviderBusinessPartnerId`	`Guid?`	Nullable	Selects the related default training provider business partner record. Source: `Requirements.DefaultTrainingProviderBusinessPartnerId`. Assigned to ResourceRequirements.
4	`EffectivityId`	`Guid?`	Nullable	Selects the related effectivity record. Source: `Requirements.EffectivityId`. Common metadata retained independently on each proposed table.
5	`EventDefinitionId`	`Guid?`	Nullable	Selects the reusable shared event definition. For Requirements with Event scope, this is its primary owner. Source: `Requirements.EventDefinitionId`. Retained on ResourceRequirements and EventRequirements; dropped from TimeRequirements.
6	`IpcReference`	`string?`	Nullable	Records ipc reference for this requirements. Source: `Requirements.IpcReference`. Assigned to ResourceRequirements.
7	`MaintenanceProgramMasterId`	`Guid?`	Nullable	Selects the related maintenance program master record. Source: `Requirements.MaintenanceProgramMasterId`. Retained on ResourceRequirements and EventRequirements; dropped from TimeRequirements.
8	`MaintenanceTaskId` Renamed · Merged	`Guid?`	Nullable	Selects the task that owns this requirement. In EventRequirements it is the task B that must be performed; TriggerMaintenanceTaskId selects task A whose occurrence activates or constrains B. EventRequirements links to the applicable timing rule through TimeRequirementId. Preserve the reviewed ComponentMaintenanceTaskId merge and explicitly reconcile legacy TaskCard-to-MaintenanceTask mappings. Source: `Requirements.MaintenanceTaskId`. Retained on ResourceRequirements and EventRequirements; dropped from TimeRequirements.
9	`ManualPageId`	`Guid?`	Nullable	Selects the related manual page record. Source: `Requirements.ManualPageId`. Retained on ResourceRequirements and EventRequirements; dropped from TimeRequirements.
10	`OperationSpecificationId`	`Guid?`	Nullable	Selects the related operation specification record. Source: `Requirements.OperationSpecificationId`. Retained on EventRequirements and ResourceRequirements; dropped from TimeRequirements.
11	`ParentAuthorizationId`	`Guid?`	Nullable	Selects the related parent authorization record. Source: `Requirements.ParentAuthorizationId`. Retained on ResourceRequirements and EventRequirements; dropped from TimeRequirements. ResourceRequirements is the destination for the lookup moved out of TimeRequirements.
12	`ParentCompetencyTemplateId`	`Guid?`	Nullable	Selects the related parent competency template record. Source: `Requirements.ParentCompetencyTemplateId`. Retained on ResourceRequirements and EventRequirements; dropped from TimeRequirements. ResourceRequirements is the destination for the lookup moved out of TimeRequirements.
13	`ParentRequirementId`	`Guid?`	Nullable	Selects the related parent requirement record. Self-reference to a parent row in this same proposed table, for hierarchy. It does not by itself express a task dependency. Re-map legacy parent IDs by destination type; review cross-type parents before adoption. Source: `Requirements.ParentRequirementId`. Common metadata retained independently on each proposed table.
14	`PartId`	`Guid?`	Nullable	Selects the related part record. Source: `Requirements.PartId`. Retained on ResourceRequirements and EventRequirements; dropped from TimeRequirements.
15	`PlanningCompetencyRequirementId`	`Guid?`	Nullable	Selects the related planning competency requirement record. Source: `Requirements.PlanningCompetencyRequirementId`. Assigned to ResourceRequirements.
16	`ProcessOwnerStaffMemberId`	`Guid?`	Nullable	Selects the related process owner staff member record. Source: `Requirements.ProcessOwnerStaffMemberId`. Retained on ResourceRequirements and EventRequirements; dropped from TimeRequirements.
17	`RequirementGroupParentId`	`Guid?`	Nullable	Groups requirement definitions within this same proposed table. Map legacy mixed resource, time and event groups explicitly by destination. Group hierarchy is separate from task/event dependencies. Source: `Requirements.RequirementGroupParentId`. Retained on EventRequirements and ResourceRequirements; dropped from TimeRequirements.
18	`SafetyScopeId`	`Guid?`	Nullable	Selects the related safety scope record. Source: `Requirements.SafetyScopeId`. Retained on EventRequirements and ResourceRequirements; dropped from TimeRequirements.
19	`SourceBusinessPartnerId`	`Guid?`	Nullable	Selects the related source business partner record. Source: `Requirements.SourceBusinessPartnerId`. Common metadata retained independently on each proposed table.
20	`PublicationMasterId` Reviewed	`Guid?` Proposed publication lookup	Nullable	Nullable UUID lookup to PublicationMaster identifying the publication associated with this requirement’s amendment reference. Replaces free-text `AmendmentReference`; display the selected publication number and title. Preserve the existing reference during later reconciliation, including any amendment/version detail the master lookup cannot represent. Reviewed HTML proposal; frontend/backend/database adoption pending complete review. Source: `Requirements.PublicationMasterId`. Common metadata retained independently on each proposed table.
21	`RotableMasterId` Moved · Review pending	`Guid?`	Nullable Optional	In plain language Selects the individual serialized component that owns this counter. A rotable is a tracked component that can be removed, maintained and reused. Real-world situation Maya selects pump P100, serial S123. What this means in practice The usage belongs to that particular pump. Another P100 pump with serial S124 must have its own history. AMOS concept · Coflyr field mapping Master and child counters · lines 175–220 Technical details and original review decision Moved from TimeRequirements to ResourceRequirements by HTML review decision. Nullable Guid lookup; original applicability, example and source definition retained below. Backend/database unchanged; adoption review pending. Detailed design note: Identifies the individual serialised component whose AssetCounter is maintained. PartMasterId identifies a part definition; this link identifies the actual rotable. Selects the related rotable master record. Used by: AssetCounter. Sources: `AssetCounter.RotableMasterId` (AssetCounter; nullable). HTML consolidation; backend/database adoption pending.

Status and controls

13 fields

#	Field	Proposed type / source type	Nullability	Business purpose and source
1	`InfoOnly`	`bool`	Required	Indicates whether info only applies to this requirements. Source: `Requirements.InfoOnly`. Common metadata retained independently on each proposed table.
2	`IsExternallyControlled`	`bool`	Required	Indicates whether externally controlled applies to this requirements. Source: `Requirements.IsExternallyControlled`. Common metadata retained independently on each proposed table.
3	`IsMandatory`	`bool`	Required	Indicates whether mandatory applies to this requirements. Source: `Requirements.IsMandatory`. Common metadata retained independently on each proposed table.
4	`IsPerformableOnShelf`	`bool`	Required	Indicates whether performable on shelf applies to this requirements. Source: `Requirements.IsPerformableOnShelf`. Assigned to ResourceRequirements.
5	`IsRequirementGroupHeader`	`bool`	Required	Indicates whether requirement group header applies to this requirements. Source: `Requirements.IsRequirementGroupHeader`. Common metadata retained independently on each proposed table.
6	`IssuingAuthority`	`string`	Required	Indicates whether issuing authority applies to this requirements. Source: `Requirements.IssuingAuthority`. Common metadata retained independently on each proposed table.
7	`LegalHold`	`bool`	Required	Indicates whether legal hold applies to this requirements. Source: `Requirements.LegalHold`. Common metadata retained independently on each proposed table.
8	`LifecycleStatus`	`PartRequirementLifecycleStatus { New, Active, Inactive, Superseded }` EF: PartRequirementLifecycleStatus	Required	Tracks the lifecycle status of this requirements. Source: `Requirements.LifecycleStatus`. Common metadata retained independently on each proposed table.
9	`PlanningStatus`	`PlanningStatusType? { None, Planned, Completed, Required, Expired, Waived, Other }` EF: PlanningStatusType?	Nullable	Tracks the planning status of this requirements. Source: `Requirements.PlanningStatus`. Common metadata retained independently on each proposed table.
10	`QuantityRequiredForDispatch`	`int?`	Nullable	Records quantity required for dispatch for this requirements. Source: `Requirements.QuantityRequiredForDispatch`. Assigned to ResourceRequirements.
11	`RequiredForCertifyingStaff`	`bool`	Required	Indicates whether required for certifying staff applies to this requirements. Source: `Requirements.RequiredForCertifyingStaff`. Assigned to ResourceRequirements.
12	`RequiredForExternalStaff`	`bool`	Required	Indicates whether required for external staff applies to this requirements. Source: `Requirements.RequiredForExternalStaff`. Assigned to ResourceRequirements.
13	`RequiredPercentage`	`decimal`	Required	Records required percentage for this requirements. Source: `Requirements.RequiredPercentage`. Assigned to ResourceRequirements.

Amounts and measurements

6 fields

#	Field	Proposed type / source type	Nullability	Business purpose and source
1	`DurationHours`	`decimal`	Required	Records duration hours for this requirements. Source: `Requirements.DurationHours`. Assigned to ResourceRequirements.
2	`MinimumHours`	`decimal?`	Nullable	Records minimum hours for this requirements. Source: `Requirements.MinimumHours`. Assigned to ResourceRequirements.
3	`PriceBookCode`	`string?`	Nullable	Records price book code for this requirements. Source: `Requirements.PriceBookCode`. Assigned to ResourceRequirements.
4	`Quantity`	`decimal`	Required	Stores the quantity used by this requirements. Source: `Requirements.Quantity`. Assigned to ResourceRequirements.
5	`QuantityInstalled`	`int?`	Nullable	Records quantity installed for this requirements. Source: `Requirements.QuantityInstalled`. Assigned to ResourceRequirements.
6	`TotalHours`	`decimal`	Required	Records total hours for this requirements. Source: `Requirements.TotalHours`. Assigned to ResourceRequirements.

Descriptions and details

2 fields

#	Field	Proposed type / source type	Nullability	Business purpose and source
1	`RequirementGroupRemarks`	`string?`	Nullable	Records requirement group remarks for this requirements. Source: `Requirements.RequirementGroupRemarks`. Common metadata retained independently on each proposed table.
2	`RequirementText`	`string?`	Nullable	Records requirement text for this requirements. Source: `Requirements.RequirementText`. Common metadata retained independently on each proposed table.

Audit and revision

2 fields

#	Field	Proposed type / source type	Nullability	Business purpose and source
1	`SystemAuditId`	`Guid?`	Nullable	Links to system audit history when this model stores the reference. Source: `Requirements.SystemAuditId`. Common metadata retained independently on each proposed table.
2	`UpdateId`	`Guid?`	Nullable	Links to the preceding revision or update record. Source: `Requirements.UpdateId`. Common metadata retained independently on each proposed table.

Other fields

43 fields

#	Field	Proposed type / source type	Nullability	Business purpose and source
1	`AircraftLocationCode` Moved · Review pending	`string?`	Nullable Optional	In plain language Text saying where on the aircraft or component the requirement applies. Real-world situation Maya enters “Left main landing gear”. What this means in practice A person can identify the relevant area. The text does not calculate a deadline or select a structured location record by itself. Coflyr metadata / proposal · no direct AMOS field definition cited Technical details and original review decision Moved from TimeRequirements to ResourceRequirements. This existing nullable text field is retained independently here and in EventRequirements. HTML review only; backend/database unchanged. Detailed design note: Legacy text identifying an aircraft/component location relevant to requirement applicability. It does not select a structured location record or define elapsed time. Records aircraft location code for this requirements. Used by: RequirementDefinition. Sources: `Requirements.AircraftLocationCode` (original shared metadata); `TimeRequirements.AircraftLocationCode` (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
2	`AircraftModelCode`	`string?`	Nullable	Records aircraft model code for this requirements. Source: `Requirements.AircraftModelCode`. Common metadata retained independently on each proposed table.
3	`AircraftSubTypeCode`	`string?`	Nullable	Records aircraft sub type code for this requirements. Source: `Requirements.AircraftSubTypeCode`. Common metadata retained independently on each proposed table.
4	`AircraftTypeCode`	`string?`	Nullable	Records aircraft type code for this requirements. Source: `Requirements.AircraftTypeCode`. Common metadata retained independently on each proposed table.
5	`Applicability`	`SafetyApplicability { Undetermined, Applicable, NotApplicable }` EF: SafetyApplicability	Required	Records applicability for this requirements. Source: `Requirements.Applicability`. Common metadata retained independently on each proposed table.
6	`ApplicabilityDecision`	`string`	Required	Records applicability decision for this requirements. Source: `Requirements.ApplicabilityDecision`. Common metadata retained independently on each proposed table.
7	`ApplicabilityReviewedAt`	`DateTimeOffset?`	Nullable	Records the applicability reviewed at for this requirements. Source: `Requirements.ApplicabilityReviewedAt`. Common metadata retained independently on each proposed table.
8	`ApplicableFrom`	`DateTimeOffset?`	Nullable	Records applicable from for this requirements. Source: `Requirements.ApplicableFrom`. Common metadata retained independently on each proposed table.
9	`ApplicableUntil`	`DateTimeOffset?`	Nullable	Records applicable until for this requirements. Source: `Requirements.ApplicableUntil`. Common metadata retained independently on each proposed table.
10	`ClassCode`	`string?`	Nullable	Records class code for this requirements. Source: `Requirements.ClassCode`. Assigned to ResourceRequirements.
11	`CompetencyScope` Moved · Review pending	`CompetencyRequirementScope { Template, Module, Examination, Qualification, Global, Organization, BusinessUnit, Department, Designation, StaffMember, Location, Facility, AircraftFamily, AircraftType, AircraftModel, Part, AtaChapter, MaintenanceTask, LearningActivity, Authorization, ExternalProvider }` EF: CompetencyRequirementScope	Required	Review decision: CompetencyScope is managed in ResourceRequirements; dropped from TimeRequirements. In plain language Says which kind of training/qualification context an inherited requirement concerns. Real-world situation A recurrent qualification timing rule concerns an aircraft type, so its scope is AircraftType. What this means in practice This classifies the context. Use this scope together with the qualification template in ResourceRequirements to identify the applicable training or qualification context. Coflyr metadata / proposal · no direct AMOS field definition cited Technical details and original review decision Moved from TimeRequirements into the existing ResourceRequirements field. Preserve this destination’s required enum type and source values. HTML review only; backend/database unchanged. Detailed design note: Inherited Coflyr classification of the training/qualification scope to which a requirement relates. CompetencyScope belongs with competency resource selection in ResourceRequirements and is dropped from TimeRequirements. Records competency scope for this requirements. Used by: RequirementDefinition. Sources: `Requirements.CompetencyScope` (original required enum); `TimeRequirements.CompetencyScope` (former timing proposal; moved). HTML consolidation; backend/database adoption pending.
12	`ComplianceLevel` Moved · Reviewed	`PartRequirementComplianceLevel { Mandatory, Recommended, Optional, InformationOnly }` EF: PartRequirementComplianceLevel	Required	Review decision: ComplianceLevel is managed in ResourceRequirements; dropped from TimeRequirements. In plain language Says whether the requirement is mandatory, recommended, optional or only information. Real-world situation A source instruction is assessed as Recommended under the applicable controlled process. What this means in practice The intended planning treatment differs from a mandatory life limit. This setting must agree with IsMandatory and InfoOnly before enforcement is implemented. AMOS concept · Coflyr field mapping Part requirement classifications · lines 630–675 Technical details and original review decision Moved · Reviewed in the ResourceRequirements HTML proposal. Backend/database unchanged; adoption pending complete review. Moved from TimeRequirements into the existing ResourceRequirements field. Preserve this destination’s required enum type and source values. HTML review only; backend/database unchanged. Detailed design note: Requirement compliance classification, such as Mandatory, Recommended, Optional or InformationOnly. Reconcile it with IsMandatory and InfoOnly during adoption. Records compliance level for this requirements. Used by: RequirementDefinition. Sources: `Requirements.ComplianceLevel` (original required enum); `TimeRequirements.ComplianceLevel` (former timing proposal; moved). HTML consolidation; backend/database adoption pending.
13	`CoverageDefinition`	`string?`	Nullable	Records coverage definition for this requirements. Source: `Requirements.CoverageDefinition`. Common metadata retained independently on each proposed table.
14	`EffectiveFrom`	`DateTimeOffset?`	Nullable	Records effective from for this requirements. Source: `Requirements.EffectiveFrom`. Common metadata retained independently on each proposed table.
15	`Jurisdiction`	`string`	Required	Records jurisdiction for this requirements. Source: `Requirements.Jurisdiction`. Common metadata retained independently on each proposed table.
16	`MinimumAttempts`	`int?`	Nullable	Records the minimum attempts for this requirements. Source: `Requirements.MinimumAttempts`. Assigned to ResourceRequirements.
17	`PerformanceType`	`PartRequirementPerformanceType { OnWing, ClosedLoop, OnShelf, ComponentReplacement }` EF: PartRequirementPerformanceType	Required	Records performance type for this requirements. Source: `Requirements.PerformanceType`. Assigned to ResourceRequirements.
18	`PlanningQualificationType`	`PlanningQualificationType? { None, Skill, Scope, Basic, Type, Continuation, Specialist, Authorization, Other }` EF: PlanningQualificationType?	Nullable	Records planning qualification type for this requirements. Source: `Requirements.PlanningQualificationType`. Assigned to ResourceRequirements.
19	`QualificationOrder`	`int?`	Nullable	Records qualification order for this requirements. Source: `Requirements.QualificationOrder`. Assigned to ResourceRequirements.
20	`QualificationPayloadJson`	`string?`	Nullable	Records qualification payload json for this requirements. Source: `Requirements.QualificationPayloadJson`. Assigned to ResourceRequirements.
21	`RecordCode`	`string?`	Nullable	Records record code for this requirements. Source: `Requirements.RecordCode`. Common metadata retained independently on each proposed table.
22	`RecordRetentionRule`	`string?`	Nullable	Records record retention rule for this requirements. Source: `Requirements.RecordRetentionRule`. Common metadata retained independently on each proposed table.
23	`RegulatoryFramework`	`RegulatoryFramework { None, Easa, Faa, CaaUk, CaaCanada, GcaaUae, DgcaIndia, CasaAustralia, CaasSingapore, Other }` EF: RegulatoryFramework	Required	Records regulatory framework for this requirements. Source: `Requirements.RegulatoryFramework`. Common metadata retained independently on each proposed table.
24	`ReportingBackMessage`	`string?`	Nullable	Records reporting back message for this requirements. Source: `Requirements.ReportingBackMessage`. Common metadata retained independently on each proposed table.
25	`RequirementCode`	`string`	Required	Records requirement code for this requirements. Source: `Requirements.RequirementCode`. Common metadata retained independently on each proposed table.
26	`RequirementGroup`	`RequirementGroupOption? { ETOPS, AD, ALI, CMR, Reliability, Operational, Engineering, Safety, Contractual, Other }` EF: RequirementGroupOption?	Nullable	Records requirement group for this requirements. Source: `Requirements.RequirementGroup`. Common metadata retained independently on each proposed table.
27	`RequirementTitle`	`string?`	Nullable	Records requirement title for this requirements. Source: `Requirements.RequirementTitle`. Common metadata retained independently on each proposed table.
28	`RequirementType`	`CompetencyRequirementType { Other, TrainingRequirement, ExaminationRequirement, PracticalAssessmentRequirement, OjtRequirement, ExperienceRequirement, LicenseRequirement, AuthorizationRequirement, DocumentRequirement, RegulatoryRequirement, SkillRequirement, ToolRequirement, MedicalRequirement, ParentCompetency }` EF: CompetencyRequirementType	Required	Records requirement type for this requirements. Source: `Requirements.RequirementType`. Common metadata retained independently on each proposed table.
29	`RequirementValue`	`string?`	Nullable	Records requirement value for this requirements. Source: `Requirements.RequirementValue`. Assigned to ResourceRequirements.
30	`RequirementValueType`	`string?`	Nullable	Records requirement value type for this requirements. Source: `Requirements.RequirementValueType`. Assigned to ResourceRequirements.
31	`ResourceCode`	`string`	Required	Records resource code for this requirements. Source: `Requirements.ResourceCode`. Assigned to ResourceRequirements.
32	`ResourceType`	`ComponentResourceType { Staff, Tool }` EF: ComponentResourceType	Required	Records resource type for this requirements. Existing Staff/Tool enum retained as the source definition for review. ResourceRequirements also covers parts, facilities and external services; agree the expanded type values and their typed lookups during later field review. Source: `Requirements.ResourceType`. Assigned to ResourceRequirements.
33	`RetainUntil`	`DateTimeOffset?`	Nullable	Records retain until for this requirements. Source: `Requirements.RetainUntil`. Common metadata retained independently on each proposed table.
34	`RetentionCategory`	`string?`	Nullable	Records retention category for this requirements. Source: `Requirements.RetentionCategory`. Common metadata retained independently on each proposed table.
35	`RowVersion`	`UInt32`	Required	Records row version for this requirements. Source: `Requirements.RowVersion`. Common metadata retained independently on each proposed table.
36	`Scope` Moved · Review pending	`ProgramRequirementScope { Program, Task, Effectivity, Competency, Part, ComponentPart, ComponentResource, Deferred, Safety, Event }` EF: ProgramRequirementScope	Required	Review decision: Scope is managed in ResourceRequirements; dropped from TimeRequirements. In plain language Says what broad business context owns the requirement. Real-world situation A requirement is attached to an applicability definition, so Maya chooses Effectivity scope. What this means in practice The scope tells the system what kind of context to expect. EffectivityId must still select the exact saved applicability definition. AMOS concept · Coflyr field mapping Time requirements, inheritance and effectivity · lines 1660–1707 Technical details and original review decision Moved from TimeRequirements into the existing ResourceRequirements field. Preserve the destination type and nullability. HTML review only; backend/database unchanged. Detailed design note: Classifies the owning business context of the requirement, such as Task, Effectivity, Part or Event. It does not replace the actual owner lookup. Records scope for this requirements. Used by: RequirementDefinition. Sources: `Requirements.Scope` (ResourceRequirements source); `TimeRequirements.Scope` (RequirementDefinition; required). HTML consolidation; backend/database adoption pending. Previous ResourceRequirements proposal The previous independent-per-table placement is superseded by this move. Records scope for this requirements. Source: `Requirements.Scope`. Common metadata retained independently on each proposed table.
37	`ScopeCode` Moved · Review pending	`string?`	Nullable	Review decision: ScopeCode is managed in ResourceRequirements; dropped from TimeRequirements. In plain language A text code identifying a scope more specifically in legacy data. Real-world situation The source uses FLEET-A as the code for an aircraft subgroup. What this means in practice The code only makes sense within its defined context. Do not treat an unrelated part named FLEET-A as the same scope. Coflyr metadata / proposal · no direct AMOS field definition cited Technical details and original review decision Moved from TimeRequirements into the existing ResourceRequirements field. Preserve the destination type and nullability. HTML review only; backend/database unchanged. Detailed design note: Legacy textual code further identifying a scope. Resolve it against the chosen scope and structured links before using it for applicability. Records scope code for this requirements. Used by: RequirementDefinition. Sources: `Requirements.ScopeCode` (ResourceRequirements source); `TimeRequirements.ScopeCode` (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending. Previous ResourceRequirements proposal The previous independent-per-table placement is superseded by this move. Records scope code for this requirements. Source: `Requirements.ScopeCode`. Common metadata retained independently on each proposed table.
38	`ShortcutCode`	`string?`	Nullable	Records shortcut code for this requirements. Source: `Requirements.ShortcutCode`. Common metadata retained independently on each proposed table.
39	`SourceDocument`	`string`	Required	Records source document for this requirements. Source: `Requirements.SourceDocument`. Retained on EventRequirements and ResourceRequirements; dropped from TimeRequirements.
40	`SourceEdition`	`string`	Required	Records source edition for this requirements. Source: `Requirements.SourceEdition`. Retained on EventRequirements and ResourceRequirements; dropped from TimeRequirements.
41	`SourceKind`	`SafetyRequirementSourceKind { Unclassified, IcaoStandard, IcaoRecommendedPractice, Regulation, Guidance, InternalPolicy }` EF: SafetyRequirementSourceKind	Required	Records source kind for this requirements. Source: `Requirements.SourceKind`. Retained on EventRequirements and ResourceRequirements; dropped from TimeRequirements and merged there into SourceType.
42	`SourceType`	`ProgramRequirementSourceType { Regulatory, Publication, OperatorPolicy, Reliability, Contractual, InternalEngineering, TrainingProvider, InternalCompliance, Other }` EF: ProgramRequirementSourceType	Required	Records source type for this requirements. Source: `Requirements.SourceType`. Retained independently here. TimeRequirements separately merges SourceKind into its reviewed SourceType proposal.
43	`SourceUrl`	`string?`	Nullable	Records source url for this requirements. Source: `Requirements.SourceUrl`. Common metadata retained independently on each proposed table.

New links and trigger fields · detailed review pending

#	Field	Proposed type	Nullability	Business purpose
1	`TimeRequirementId` Proposed	`Guid?`	Nullable	Optional link to the TimeRequirements rule governing when this resource is needed. General resource needs may leave it empty. Select a RequirementDefinition-role TimeRequirements row that matches the owning task/template and applicability context; counter, limit and snapshot rows are not valid timing-rule selections. Task/event activation is selected separately through EventRequirementId; this lookup does not itself define a trigger. If both links are supplied, reconcile them with the event rule’s TimeRequirementId so there is one authoritative timing rule.
2	`EventRequirementId` Proposed	`Guid?`	Nullable	Optional lookup to EventRequirements when this resource need applies to an event-triggered or prerequisite task. Example: a replacement-completion event requires a functional test using a test bench. The selected rule must match the owning task/template and applicability. This references the reusable event rule, rather than a recorded event occurrence, reservation or fulfilment request.

Dropped fields · retained for review

#	Former field	Source type	Nullability	Decision
1	`AmendmentReference` Dropped	`string?`	Nullable	Replaced by the reviewed `PublicationMasterId` lookup. Retained here for review history. Reconcile existing amendment-reference text to publication records during later adoption; ambiguous or unmatched values require explicit review. HTML decision only; backend/database adoption pending. Source: `Requirements.AmendmentReference`. Assigned to ResourceRequirements.
2	`ApplicabilityReviewedByStaffMemberId` Dropped	`Guid?`	Nullable	Former staff lookup identifying who reviewed applicability. Dropped from the proposed Requirements model; retained here for review history. HTML decision only; backend/database removal pending. Source: `Requirements.ApplicabilityReviewedByStaffMemberId`. Assigned to ResourceRequirements.
3	`ComponentMaintenanceTaskId` Dropped · Merged	`Guid?`	Nullable	Renamed to `MaintenanceTaskId` and merged with the existing field of that name in the HTML proposal. Original name retained for review history. The legacy component reference currently targets TaskCard; resolve it explicitly to the intended MaintenanceTask record during adoption and review conflicting values when both old fields are populated. Do not assume that their UUIDs are interchangeable. Backend/database adoption pending complete review. Source: `Requirements.ComponentMaintenanceTaskId`. Assigned to ResourceRequirements.