Backend table independence applied: All seven TimeRequirements lookup relationships use EntityLinks; stored IDs support existing screens and APIs. Open all-table review. TimeRequirements is first; other tables await individual review.

Coflyr · Independent timing and counters

TimeRequirements

An independent table for timing rules, limit definitions, applied due limits and counter records. Owners and consumers will connect through EntityLinks.

63 reviewed active fields142 dropped retained9 row typesBackend adopted · Independent local table

Not reviewed 0

All active fields have been reviewed.

    Independent table
    Maintenance.TimeRequirements
    Stored fields
    56 database columns and 7 NotMapped fields; all 63 active fields reviewed.
    Inheritance
    RemarkableEntity; one physical table with explicit RecordKind.
    Backend / database
    Created and verified in the local database on 11 October 2026. Existing Requirements, TimeRequirementLimits, MaintenanceEventDueLimits and CounterRecords remain unchanged.
    Associations
    Events, resources, assets and execution contexts will link through EntityLinks. Reviewed unit, authority, publication and effectivity lookups remain; ParentTimeRequirementId is the internal hierarchy.

    Current adoption decision: keep TimeRequirements independent and add owner/consumer EntityLinks later. The backend includes role validation, hierarchy and recurrence checks, approved unit/category mappings, and audited API operations. NotMapped forecast/reading values remain unset until a linked operational context supplies them. Technical details below retain the original review history; earlier “backend/database unchanged” and consolidation notes describe that earlier stage and are superseded by this adoption status.

    ← Model index · ResourceRequirements · EventRequirements · Dropped source catalogs

    Start with one everyday maintenance job

    Maya is the maintenance planner. Ravi is the technician. They manage the filter inspection for aircraft VT-ABC. For this fictional example, the approved instruction says: inspect every 500 flying hours or every six months, whichever comes first.

    Ravi last completed the inspection on 1 January 2026, when the aircraft had 1,000 total flying hours. On 1 May, the aircraft has 1,200 hours. Maya expects it to fly about five hours a day.

    The instruction: how often?

    500 more hours

    Amount = 500 and Dimension = FH say to count 500 additional flying hours from the agreed starting point.

    A separate limit says Amount = 6 and Dimension = MO: six calendar months.

    The deadline: at what total?

    1,500 total hours

    Start at the last inspection’s 1,000 hours. Add 500. The inspection is due at 1,500 aircraft hours.

    The separate calendar deadline is 1 July 2026, six months after 1 January.

    Today: how much is left?

    300 hours left

    Due at 1,500 minus today’s 1,200 leaves 300 flying hours.

    At five hours a day, that is about 60 days, around 30 June. Flying more or less changes this estimated date, not the 1,500-hour limit.

    You use the fields for the relevant record type

    The independent table supports nine kinds of record. A main inspection rule, a limit, an aircraft counter and a historical reading are still separate saved records. Each kind uses only its relevant fields. RecordKind says which kind it is.

    For the example above, Maya saves the main “Filter inspection” rule and two limit records. The calculation needs VT-ABC’s usage. The aircraft and maintenance occurrence will associate through EntityLinks in the later linking work; no automatic calculation or legacy synchronization is introduced by creating this table. Ravi’s individual readings remain separate history records.

    How each field explanation works

    In plain language tells you what the field is for. Real-world situation shows what someone enters, selects or encounters. What this means in practice explains why the value matters. For a dropped field, the example explains its former use and does not bring it back.

    These are fictional examples explaining the data, not actual inspection instructions for a particular aircraft. AMOS links support the documented concepts. Coflyr-specific fields and proposed behavior are labelled separately. Expand Technical details and original review decision only when you want the model mapping and previous design notes.

    Words used below: hours, cycles, counter, baseline, snapshot and ID
    Flight hour / FH
    A unit of flying time under the approved counter definition. A five-FH increase means five more flying hours.
    Flight cycle / FC
    A unit in the aircraft’s flight-cycle counter. Use the approved counter definition; the field must not guess what counts as a cycle.
    APU
    Auxiliary power unit. APU running hours are a different usage total from aircraft flying hours.
    Calendar month / MO
    A month on the calendar. Six months from 1 January is 1 July; it is not automatically a fixed number of days.
    Counter
    A saved usage total, like an aircraft’s flying-hours record. It can come from flight data or from a physical meter, depending on its setup.
    Reading / readout
    A particular recorded value at a particular occasion, such as “VT-ABC had 1,200 hours at this observation”.
    Baseline
    The starting point. In our example, it is the last inspection at 1,000 hours on 1 January.
    Threshold
    When the first inspection/action is due. Example: first inspect at 5,000 cycles.
    Interval
    How much more time/usage is allowed between repeat actions. Example: repeat every 500 additional cycles.
    Due
    The approved date or usage total at which work must be performed under its rule.
    Expected / forecast
    An estimate of when a usage deadline will be reached. It can change with the aircraft’s daily use.
    Snapshot
    A saved calculation showing the values used at that time. It is like keeping a copy of the calculation sheet, not a live meter reading that keeps changing.
    Definition / template
    A reusable description or setup. “Flight hours” describes what is counted; VT-ABC’s own counter holds that aircraft’s value.
    ID / UUID / lookup
    The computer’s unique identity for a saved record. A field ending in Id usually means “select that existing record”; normally you select a name/code rather than type a long UUID.
    Nullable / optional
    The value can be empty at the shared-table level. “Required for” means it must be supplied for the listed kind of record.
    UTC
    A common time standard used to store timestamps consistently. A date-only field has no time of day.
    Report back / accomplishment
    Record valid evidence that the work was actually performed, including the relevant time and usage values.

    Existing design issues remain for later implementation. AMOS calls AH APU hours and OD operational days; current Coflyr OD behavior differs. Coflyr does not automatically apply the documented tolerances, and its resets differ from AMOS fixed-value resets. GroupNumber remains dropped, so a replacement for its grouping identity still needs review.

    Start field review · Dropped fields explained · AMOS reference passages

    The nine kinds of saved record

    RecordKindPurpose
    RequirementDefinitionThe main saved instruction: “Inspect the filter every 500 flying hours or six months”. It owns its timing limits.
    LimitDefinitionOne saved limit belonging to the instruction: “500 flying hours” is one record; “six months” is another.
    DueLimitSnapshotThe saved calculation for a particular inspection occurrence: starting hours, observed hours, due total and forecast date at calculation time.
    CounterDefinitionDescribes what is counted: for example “Flight hours”. It is not a particular aircraft’s current total.
    CounterTemplateGroupA reusable bundle of counter setups: for example aircraft hours and cycles together.
    CounterTemplateGroupAssignmentSays which aircraft type or part number receives that bundle of counter setups.
    CounterTemplateThe reusable setup for one counter: for example how a component follows aircraft hours while installed.
    AssetCounterThe actual usage total for one aircraft/component: for example VT-ABC’s flight-hours counter currently showing 1,200.
    CounterReadingOne historical recorded value: for example VT-ABC’s hours reading of 1,200 on a particular occasion.

    Retire the three source tables only during a later reviewed migration. Remap all incoming references, source IDs and typed self-references explicitly, including ID collisions between old tables. Preserve existing counters/readings, snapshot provenance, constraints, role-specific defaults, precision, uniqueness and deletion behavior. No physical tables have been dropped by this HTML review.

    Timing and counter example

    A RequirementDefinition says “inspect every 500 flight hours or six months”. Two child LimitDefinition rows hold the hour and calendar limits. An AssetCounter row holds the aircraft’s current flight hours; CounterReading rows preserve its recorded readings. DueLimitSnapshot rows capture the approved limits and counter values for a particular MaintenanceEventMaster occurrence.

    The live counter may change while an earlier calculation keeps its captured values. Recurring completion uses actual accomplishment evidence and the approved next-due strategy. Task/event activation stays in EventRequirements, which can select a RequirementDefinition through TimeRequirementId. ResourceRequirements also selects a RequirementDefinition, rather than a counter or limit row.

    HoursLimit, CyclesLimit, DaysLimit and TimeThresholdValue are dropped as separate fields and retained in history. Structured LimitDefinition rows provide the authoritative limits: Amount holds the numeric value, Dimension identifies what is measured, LimitType distinguishes Threshold from Interval, and the approved baseline identifies the starting point. Reconcile legacy values explicitly during adoption.

    DueDate/ExpectedDate remain date-only requirement fields; DueAt/ExpectedAt retain timestamp-based applied-limit meanings. CounterValueDimension and maintenance-limit Dimension use different enums and remain distinct. Required enum values/defaults must be mapped explicitly; numeric enum values are not interchangeable.

    Identity and naming

    2 fields
    #FieldProposed typeNullability / required row typePlain explanation, practical example and source
    1Id
    Reviewed
    GuidRequired
    Required for: All row types

    In plain language The computer’s permanent identity number for this saved record. You normally do not type it.

    Real-world situation

    Maya creates “Inspect the hydraulic filter”. Coflyr gives that record its own ID automatically.

    What this means in practice Another record can select this exact inspection even if Maya later changes its title. Each inspection rule, limit and meter reading gets a separate ID.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Permanent UUID identifying one row, regardless of its role. A requirement, its limit and each reading have different IDs; a business code is not this database identity.

    Stable identifier for this record.
    Used by: All, LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirements.Id (All; required); TimeRequirementLimit.Id (LimitDefinition; required); MaintenanceEventDueLimit.Id (DueLimitSnapshot; required); CounterRecord.Id (All; required). HTML consolidation; backend/database adoption pending.
    2SequenceNo
    Reviewed
    int?Nullable
    Required for: LimitDefinition, CounterTemplate

    In plain language The position of an item in a list: first, second, third and so on.

    Real-world situation

    Maya enters 1 for the hours limit and 2 for the calendar limit.

    What this means in practice The screen can show hours first and months second. These numbers do not mean one hour or two months.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Orders sibling limits or counter templates. It helps present or evaluate a set consistently; it is not an interval amount or a group identifier.

    Display/evaluation order on the owning row. Merges TimeRequirements.SequenceNo, TimeRequirementLimit.Sequence and CounterTemplate.Sequence. Required and nonnegative for LimitDefinition and CounterTemplate rows; nullable where the source allowed it. Preserve unique limit ordering within parent, limit type, group and dimension.
    Used by: RequirementDefinition, LimitDefinition, CounterTemplate.
    Sources: TimeRequirements.SequenceNo (RequirementDefinition; nullable); TimeRequirementLimit.Sequence (LimitDefinition; required); CounterTemplate.Sequence (CounterTemplate; required). HTML consolidation; backend/database adoption pending.

    Relationships and references

    5 fields
    #FieldProposed typeNullability / required row typePlain explanation, practical example and source
    1ClauseReference
    Reviewed
    string?Nullable
    Required for: RequirementDefinition

    In plain language The exact paragraph in the document that tells you to do the work.

    Real-world situation

    Maya selects a maintenance-programme document and enters “Task 29-10-00, paragraph 3”.

    What this means in practice When someone asks why this inspection exists, they can open the document and find the paragraph instead of searching the whole manual.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Pinpoints the paragraph or clause in the selected source publication. PublicationMasterId selects the document; this text identifies the location within it.

    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.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ClauseReference (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    2EffectivityId
    Reviewed
    Guid?Nullable
    Required for: Optional

    In plain language Selects the saved list or rule saying which aircraft or components this requirement applies to. “Effectivity” means applicability.

    Real-world situation

    The inspection applies only to aircraft fitted with pump P100. Maya selects the applicability record for those aircraft.

    What this means in practice The intended rule covers those aircraft. Aircraft with a different pump should not receive it just because they belong to the same fleet; adoption must enforce this link.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    HTML review decision: Applicability, its decision, review timestamp and applicability window are managed through Effectivity via this EffectivityId lookup; the separate Applicability, ApplicabilityDecision, ApplicabilityReviewedAt, ApplicableFrom and ApplicableUntil fields are dropped. Backend/database unchanged.

    Detailed design note: Selects the applicability definition determining which aircraft, components or configurations receive the requirement. AMOS permits time requirements on an item or on an effectivity; this UUID is Coflyr’s proposed link.

    Selects the related effectivity record.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.EffectivityId (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    3ParentTimeRequirementId
    Reviewed · Renamed
    Guid?Nullable
    Required for: LimitDefinition, DueLimitSnapshot

    In plain language Selects the main timing rule to which this smaller item belongs.

    Real-world situation

    Maya creates the main “Filter inspection” rule. On both its 500-hour limit and its six-month limit, she selects “Filter inspection” as the parent.

    What this means in practice Both limits belong to the same inspection. This does not mean one task must happen before another; it organizes the timing records.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Links a row to its parent in this unified table. LimitDefinition and DueLimitSnapshot must select their owning RequirementDefinition. A hierarchy link alone does not mean “perform after this task”.

    Nullable self-reference for requirement hierarchy. Required on LimitDefinition and DueLimitSnapshot rows, where it selects their RequirementDefinition row and replaces the former RequirementId. For a snapshot, this parent must match the parent of its SourceLimitId. Retain hierarchy separately from typed counter/template references and prevent self-parenting and cycles. Preserve the earlier ParentRequirementId rename; map every legacy identity explicitly.
    Used by: RequirementDefinition, LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirements.ParentTimeRequirementId (RequirementDefinition; nullable); TimeRequirementLimit.RequirementId (LimitDefinition; required); MaintenanceEventDueLimit.RequirementId (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    4PublicationMasterId
    Reviewed
    Guid?Nullable
    Required for: Optional

    In plain language Selects the manual or other controlled document that contains the requirement.

    Real-world situation

    Maya selects “Operator Maintenance Programme — Revision 12”.

    What this means in practice The requirement points to a real document record instead of just typed text. Historical work must keep the version that was used, even when Revision 13 is issued.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Selects the controlled publication underlying the requirement and replaces the old amendment-reference text in this proposal. The adopted design must preserve the exact edition used historically.

    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.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.PublicationMasterId (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    5MeasurementUnitId
    Reviewed · Unit lookup
    Guid?
    Lookup: MeasureUnit
    Nullable
    Required for: CounterDefinition

    Resolved unit/category design: MeasurementUnitId selects the concrete saved unit. CounterValueDimension supplies the explicit controlled counter category. Keep both; MeasureUnit.UnitCategory is currently nullable free text and is not an authoritative enum mapping.

    In plain language Selects the saved measurement unit used by this counter, rather than typing a counter-code string.

    Real-world situation

    For an hours counter, Maya selects the existing “Hours” unit. For a cycles counter, she selects the existing “Cycles” unit.

    What this means in practice The record stores the selected unit’s ID and shows its code/name or symbol. Users choose a recognizable unit from a dropdown; they do not type a UUID. The unit says what the number is measured in, not which aircraft owns it.

    Coflyr lookup proposal · the AMOS counter-code concept is retained in the dropped-field history

    Technical details and original review decision

    Reviewed compatibility rule: CounterDefinition requires a saved unit and an explicit counter category with different responsibilities. During adoption, validate the pair using an approved mapping from saved unit identities to allowed CounterValueDimension values; reject incompatible pairs and require explicit mapping for unclassified units. Hours units may serve aircraft or APU counters; their specific identity/purpose must still agree with the selected limit. Do not cast enum values or guess categories from names, symbols, UnitCategory or UnitGroup text. Retain CounterValueDimension as mapped until a controlled, complete unit-category mapping exists. This is the HTML design requirement; backend/database enforcement is unchanged.

    Reviewed as a lookup to MeasureUnit.Id in the TimeRequirements HTML proposal. Replaces CounterCode; preserve the selected unit type and source mapping. Backend/database unchanged.

    Nullable UUID lookup to MeasureUnit (MasterData.MeasureUnits), using MeasureUnit.Id. Replaces CounterCode in the TimeRequirements HTML proposal. Required for CounterDefinition rows; nullable across other row types. Display the selected unit’s Code, Name and configured Symbol. Resolve existing counter codes to valid saved unit records explicitly; do not copy text into a Guid.

    Mapping to preserve: Hours can measure both aircraft flight time and APU running time. Unit selection alone does not distinguish those counter purposes. Preserve their identities and counting rules, and explicitly map legacy H/C/OD/AH codes, formula references and reserved-code behavior during adoption. DisplayUnit and other retained fields are not automatically merged by this decision.

    Used by: CounterDefinition.
    Replaces: CounterDefinition.CounterCode (string; required). Target: MeasureUnit.Id. HTML proposal only; backend/database adoption pending.

    Status and controls

    12 fields
    #FieldProposed typeNullability / required row typePlain explanation, practical example and source
    1InfoOnly
    Reviewed
    bool?Nullable
    Required for: RequirementDefinition

    In plain language Marks information intended to be read rather than treated as a mandatory maintenance deadline.

    Real-world situation

    Maya marks an advisory inspection note as information only.

    What this means in practice The note remains useful to planners. This flag’s relationship to mandatory/compliance settings must be resolved before software uses it to suppress scheduling.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Marks requirement information intended for reference. Its relationship to ComplianceLevel.InformationOnly and actual scheduling enforcement must be reconciled during adoption.

    Indicates whether info only applies to this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.InfoOnly (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    2IsExternallyControlled
    Reviewed
    bool?Nullable
    Required for: RequirementDefinition

    In plain language Says another organization controls the requirement’s content.

    Real-world situation

    The manufacturer controls a pump life-limit instruction. Maya marks it externally controlled.

    What this means in practice The team knows changes come from the manufacturer. The flag does not download revisions or approve changes automatically.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Records that control of the requirement rests with an external source. This is metadata; the flag alone does not implement document synchronization or change approval.

    Indicates whether externally controlled applies to this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.IsExternallyControlled (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    3IsMandatory
    Merged · Reviewed
    bool?Nullable
    Required for: RequirementDefinition, CounterDefinition, CounterTemplate

    In plain language Says the requirement or counter represented by this row is mandatory. On RequirementDefinition rows, the maintenance requirement must be complied with. On CounterDefinition and CounterTemplate rows, the counter must exist and be maintained.

    Real-world situation

    A component has an approved mandatory retirement limit. Maya marks the requirement mandatory.

    For a counter definition or template, the aircraft setup requires flying-hours and cycles counters; IsMandatory marks those counters as required.

    What this means in practice The intended workflow treats the applicable row as mandatory. On requirement rows, reconcile the flag with ComplianceLevel. On counter rows, it governs the counter obligation. The flag alone does not implement enforcement.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Merged · Reviewed. Mandatory is consolidated into IsMandatory for RequirementDefinition, CounterDefinition and CounterTemplate. Use the row role to preserve each source meaning. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Single nullable Boolean merging IsMandatory and Mandatory. RequirementDefinition uses maintenance compliance semantics; CounterDefinition and CounterTemplate use required-counter semantics. Preserve source values and owning row roles in the migration mapping; reconcile conflicts explicitly if multiple source values map to one row.

    Indicates whether the maintenance requirement or counter is mandatory for this row role.
    Used by: RequirementDefinition, CounterDefinition, CounterTemplate.
    Sources: TimeRequirements.IsMandatory (RequirementDefinition; required); CounterDefinition.Mandatory (CounterDefinition; required; merged); CounterTemplate.Mandatory (CounterTemplate; required; merged). HTML consolidation; backend/database adoption pending.
    4RecurrenceMode
    Merged · Reviewed
    TimeRequirementRecurrenceMode? { OneTime, Repetitive, NonPeriodic }Nullable
    Required for: RequirementDefinition

    Resolution: One recurrence mode replaces IsOneTimeOnly and TimeIsRepetitive. A nonperiodic requirement remains distinct from a one-time requirement.

    In plain language Says whether the requirement applies once, repeats under an interval rule, or has no periodic recurrence and is not explicitly limited to one accomplishment.

    Real-world situation

    A one-time modification inspection uses OneTime. A filter inspection every 500 flying hours uses Repetitive. A requirement with neither old flag set uses NonPeriodic once its source meaning is confirmed.

    What this means in practice OneTime prevents automatic repetition for the same applicable subject/context. Repetitive uses structured Interval limits and the approved next-due strategy. NonPeriodic does not automatically schedule repeats or impose a once-only restriction; any independent event activation is defined by the linked event rule.

    Coflyr consolidation proposal; enum choices express the resolved recurrence design

    Technical details and original review decision

    Merged · Reviewed: RecurrenceMode replaces the two independent flags on RequirementDefinition rows. Nullable across the unified table; required for RequirementDefinition. Map explicit legacy pairs (IsOneTimeOnly, TimeIsRepetitive): (true, false) → OneTime; (false, true) → Repetitive; (false, false) → NonPeriodic. (true, true) is contradictory and requires reconciliation. Null/unknown legacy values require explicit resolution before adoption; never treat null as false. Preserve original values and applicable subject/occurrence scope. A threshold followed by intervals remains Repetitive; Threshold is not synonymous with OneTime. NonPeriodic is not inferred to mean unlimited or event-driven. Prevent repetitive mode without the applicable approved interval and next-due strategy; do not infer recurrence solely from a child row's existence.

    Sources: TimeRequirements.IsOneTimeOnly (RequirementDefinition; required); TimeRequirements.TimeIsRepetitive (RequirementDefinition; nullable). Original definitions retained in dropped history. HTML review only; backend/database unchanged.
    5IsProRataCalculation
    Reviewed
    bool?Nullable
    Required for: RequirementDefinition

    In plain language Says an approved adjustment rule is used when consuming a component’s allowed life.

    Real-world situation

    For illustration, an approved operating-category rule counts 100 actual hours as 120 life-consumption hours.

    What this means in practice The adjustment rule supplies the factor. Selecting Yes alone does not tell Coflyr to multiply by 1.2; AMOS describes this in life-limit workflows.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Marks use of approved pro-rata life-limit treatment. AMOS describes this for life limits with rating-category rules; the Boolean does not itself supply a factor or formula.

    Indicates whether pro rata calculation applies to this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.IsProRataCalculation (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    6IssuingAuthorityBusinessPartnerId
    Renamed · Merged · Reviewed
    Guid?
    BusinessPartner lookup
    Nullable
    Required for: RequirementDefinition

    Merge decision: SourceBusinessPartnerId is merged into IssuingAuthorityBusinessPartnerId, the single BusinessPartner lookup for the organization supplying or issuing the requirement. The separate SourceBusinessPartnerId field is dropped.

    In plain language Selects the BusinessPartner representing the authority or organization supplying or issuing the requirement, consolidating the former SourceBusinessPartnerId lookup.

    Real-world situation

    The pump manufacturer issued the inspection instruction. Maya selects that manufacturer’s BusinessPartner record as the issuing organization.

    What this means in practice A reviewer sees the selected organization’s name, while the field stores its BusinessPartner identifier. Selecting the issuer does not itself confirm approval.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Merged · Reviewed: SourceBusinessPartnerId → IssuingAuthorityBusinessPartnerId. Keep the nullable Guid lookup to BusinessPartner.Id and the existing RequirementDefinition role requirement. During later adoption, retain the valid issuer lookup; use the source partner when the issuer is missing and the partner represents the supplying or issuing organization. Resolve the original IssuingAuthority text explicitly to a saved BusinessPartner. If the source partner and resolved issuer differ, preserve both source values and reconcile them explicitly before migration; do not silently overwrite or discard either. Original SourceBusinessPartnerId definition remains in dropped history. HTML review only; backend/database unchanged.

    Renamed · Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.
    Reviewed HTML rename: IssuingAuthority → IssuingAuthorityBusinessPartnerId. Replace the original string? with a nullable Guid? lookup to BusinessPartner. Preserve and reconcile existing issuer text to the selected partner before later adoption. Original definition retained below for history. Backend/database unchanged; adoption pending complete review.

    Original design note (superseded): Text identifying the authority associated with issuing the requirement. Despite an old generated description beginning “Indicates whether”, this is a string, not a Boolean.

    Indicates whether issuing authority applies to this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.IssuingAuthority (RequirementDefinition; required; renamed to BusinessPartner lookup); TimeRequirements.SourceBusinessPartnerId (RequirementDefinition; nullable; merged). HTML consolidation; backend/database adoption pending.
    7LegalHold
    Reviewed
    bool?Nullable
    Required for: RequirementDefinition

    In plain language Says the record must be preserved for a records-management reason.

    Real-world situation

    An investigation requires keeping an inspection history record. The responsible user marks it on hold.

    What this means in practice The intended retention workflow preserves it. This does not change when the inspection is due; actual retention enforcement still needs implementation.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Coflyr records-retention flag indicating that associated records require preservation. It is not a maintenance interval or an automatic extension of a compliance deadline.

    Indicates whether legal hold applies to this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.LegalHold (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    8TimeIsUnlimited
    Reviewed
    bool?Nullable
    Required for: Optional

    In plain language Says there is no numeric time/usage limit for the selected timing configuration.

    Real-world situation

    A source defines a particular requirement as having “No Limit”.

    What this means in practice Do not enter zero to mean unlimited. AMOS distinguishes unlimited first and repeat limits; this single field still needs an explicit mapping.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Records an unlimited timing configuration. AMOS distinguishes unlimited thresholds and intervals; this single flag needs a role-specific mapping rather than treating zero as unlimited.

    Indicates whether time is unlimited applies to this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.TimeIsUnlimited (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    9ApplyTolerance
    Reviewed
    bool?Nullable
    Required for: LimitDefinition

    In plain language Says an approved early/late allowance should be considered for this limit.

    Real-world situation

    A source gives a nominal 12-month interval with a specified approved allowance.

    What this means in practice The allowed window can be shown only according to the approved rule. Current Coflyr calculations do not apply these tolerances automatically.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: States whether the approved tolerance settings apply to a limit. It does not grant an unsupervised extension. The current Coflyr calculator does not automatically apply tolerances.

    Indicates whether apply tolerance applies to this time requirement limit.
    Used by: LimitDefinition.
    Sources: TimeRequirementLimit.ApplyTolerance (LimitDefinition; required). HTML consolidation; backend/database adoption pending.
    10TerminatesInterval
    Reviewed
    bool?Nullable
    Required for: LimitDefinition

    In plain language Says this item ends a sequence of repeated inspections under the approved rule.

    Real-world situation

    A source requires repeated crack checks until a permanent modification is completed.

    What this means in practice The completed terminating action ends that inspection sequence where approved. It must not stop unrelated inspections.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Marks termination of an interval sequence where the approved definition allows it. AMOS advanced recurring groups can end with a terminated group; detailed mapping remains to be implemented.

    Indicates whether terminates interval applies to this time requirement limit.
    Used by: LimitDefinition.
    Sources: TimeRequirementLimit.TerminatesInterval (LimitDefinition; required). HTML consolidation; backend/database adoption pending.
    11IsControlling
    Merged · Reviewed
    bool?Nullable
    Required for: DueLimitSnapshot

    In plain language Says which limit currently determines when the work is due.

    Real-world situation

    The hours limit is expected on 30 June; the calendar limit is 1 July. The rule says whichever comes first.

    What this means in practice The hours limit controls because it is earlier. If utilization changes, the calendar limit may become the earlier one instead.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Merged · Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Indicates which applied limit currently controls the occurrence’s overall due result under the chosen logic. This is a calculation result, not a freely selected preference.

    Indicates whether controlling applies to this maintenance event due limit.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.IsControlling (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    12AllowsReset
    Reviewed
    bool?Nullable
    Required for: CounterDefinition

    In plain language Says Coflyr permits its reset operation for this kind of counter.

    Real-world situation

    A shop process counter is allowed to restart after an approved reset event.

    What this means in practice The reset operation may be permitted. It must not be used simply to erase aircraft total hours or make an overdue inspection disappear.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Coflyr permission/configuration flag allowing its reset operation for this counter definition. AMOS also has reset readouts, but its fixed-value reset semantics require explicit reconciliation with Coflyr.

    Indicates whether allows reset applies to this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.AllowsReset (CounterDefinition; required). HTML consolidation; backend/database adoption pending.

    Dates and timing

    10 fields
    #FieldProposed typeNullability / required row typePlain explanation, practical example and source
    1DueDate
    Reviewed
    DateOnly?Nullable
    Required for: Optional

    In plain language The date by which the applicable work is due, stored without a time of day.

    Real-world situation

    A six-month inspection starting on 1 January 2026 is due on 1 July 2026.

    What this means in practice A planner sees 1 July as the deadline. If an exact time matters, the timestamp field and the agreed calendar/timezone rule are also needed.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Date-only due result on the requirement header. Calendar or counter rules determine it; converting a timestamp to this date requires an agreed timezone and cutoff rule.

    Due date for the applicable timing occurrence. Calendar/counter rules calculate it using their approved baseline. A linked EventRequirements rule may supply a matched event/task timestamp as the baseline; the trigger belongs to that event rule. Preserve the distinction between the reusable definition and its execution due-date snapshot.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.DueDate (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    2ExpectedDate
    Reviewed
    DateOnly?
    Not mapped · no database column
    Nullable
    Required for: Optional

    Review remark: Not mapped field. No database column required; calculate the expected date for display from the remaining usage and utilization forecast.

    In plain language The estimated date when a usage-based limit will be reached.

    Real-world situation

    An aircraft has 300 flying hours left and usually flies five hours per day.

    What this means in practice The estimate is about 60 days away. If it starts flying less, this estimate changes; the approved hours limit does not.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed as a non-mapped field in the TimeRequirements HTML proposal. ExpectedDate does not require a database column. Original source definition retained below for review history; backend/database unchanged.

    Detailed design note: Date-only forecast of when a usage-driven limit is likely to be reached. It can move when utilization changes even though the fixed counter limit remains unchanged.

    Records the expected date for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ExpectedDate (RequirementDefinition; nullable). Original source mapping retained for history. Current HTML decision: not mapped; no database column required. Backend/database unchanged.
    3ExpiryBasis
    Reviewed
    ExpiryBasis? { FromDeferralDate, FromDiscoveryDate, FromNextFlight }Nullable
    Required for: RequirementDefinition

    In plain language Says which starting event is used to calculate a deferral-related expiry.

    Real-world situation

    The approved rule says count from the deferral date, so Maya selects FromDeferralDate.

    What this means in practice The calculation must use that recorded date rather than discovery time. Whether this field is needed for other kinds of timing records still needs review.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Selects the starting context for a deferral-related expiry calculation: discovery, deferral or next flight. Its existing requiredness needs review for non-deferral timing rows.

    Records the expiry basis for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ExpiryBasis (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    4TimeBaselineType
    Reviewed
    TimeRequirementBaselineType? { Manufacture, Delivery, Installation, LastAccomplishment, FixedDateOrCounter, ParentEvent, CurrentCounter }Nullable
    Required for: DueLimitSnapshot

    In plain language Says where counting starts: manufacture, installation, last completion or another allowed starting point.

    Real-world situation

    Maya chooses LastAccomplishment for a 500-hour repeat inspection completed at 1,000 aircraft hours.

    What this means in practice Start counting from 1,000, so the next counter deadline is 1,500 hours. Choosing Installation would require the installation reading instead.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Selects the event, date or counter value from which a threshold/interval is calculated. A snapshot captures the resolved baseline; AMOS baseline concepts support this design, but enum values are Coflyr’s mapping.

    Shared baseline classification on requirement, limit-definition and applied-limit rows. A limit definition may override the requirement default. DueLimitSnapshot must store the resolved baseline classification so later definition edits do not alter historical calculations. Merges former BaselineType properties; retain original enum meanings.
    Used by: RequirementDefinition, LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirements.TimeBaselineType (RequirementDefinition; nullable); TimeRequirementLimit.BaselineType (LimitDefinition; nullable); MaintenanceEventDueLimit.BaselineType (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    5TimeLogic
    Reviewed
    CalculationLogic? { WhicheverComesFirst, WhicheverComesLater, AllLimitsMustBeMet, AnyLimitCanTrigger, PrimaryCounterOnly, CalendarOnly, ManualPlanning }Nullable
    Required for: DueLimitSnapshot

    In plain language Says how to combine timing limits within a group and the results of separate timing groups. This single field includes the former TimeGroupLogic behavior; its owning row identifies the calculation scope.

    Real-world situation

    The source says inspect after 500 flying hours OR six months, whichever comes first.

    For separate groups, if group A gives a June deadline and group B gives a September deadline, WhicheverComesFirst selects June.

    What this means in practice Plan for the earlier deadline. Do not wait until both limits are exceeded. Other logic choices need explicit approved rules and implementation support.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed · TimeGroupLogic merged into TimeLogic in the HTML proposal. TimeGroupLogic is retained as dropped history. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Combines dimensions within a limit group and results across groups, consolidating TimeGroupLogic and former GroupLogic. Preserve the owning row and hierarchy to distinguish these scopes. AMOS First/Later concepts support common earliest/latest cases; the broader Coflyr enum requires implementation review.

    Single calculation-logic field combining dimensions within a limit group and the results of separate groups, merging TimeGroupLogic and former GroupLogic. RequirementDefinition provides the default, LimitDefinition may override it, and DueLimitSnapshot stores the resolved value. Identify each calculation scope through the owning row and retained group hierarchy. Reconcile differing legacy TimeLogic and TimeGroupLogic values explicitly before adoption; one merged field must not silently discard a distinct rule. Event trigger/enforcement logic remains in EventRequirements.
    Used by: RequirementDefinition, LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirements.TimeGroupLogic (RequirementDefinition; nullable; merged); TimeRequirements.TimeLogic (RequirementDefinition; nullable); TimeRequirementLimit.GroupLogic (LimitDefinition; nullable); MaintenanceEventDueLimit.GroupLogic (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    6TimeNextDueCalculationStrategy
    Reviewed
    TimeNextDueCalculationStrategy? { FromLastAccomplishment, FromPreviousDue, FromActualCounter, FromFixedBaseline, FromParentEvent, Manual }Nullable
    Required for: Optional

    In plain language Says where the next repeat interval starts after the work is completed.

    Real-world situation

    The inspection was due at 1,500 hours but was done early at 1,480. The repeat interval is 500 hours.

    What this means in practice Counting from completion gives 1,980. Counting from the previous due value gives 2,000. The selected approved strategy decides which applies.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Determines the reference used to calculate the next occurrence after accomplishment. AMOS documents several strategies; Coflyr’s enum is not a one-to-one copy and only implemented choices may run automatically.

    Shared next-due strategy on requirement, limit-definition and applied-limit rows, merging NextDueCalculationStrategy. Preserve parent defaults, child overrides and the resolved strategy captured for each snapshot. Existing automatic report-back supports only the implemented strategies; storing another enum value does not add calculation support.
    Used by: RequirementDefinition, LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirements.TimeNextDueCalculationStrategy (RequirementDefinition; nullable); TimeRequirementLimit.NextDueCalculationStrategy (LimitDefinition; nullable); MaintenanceEventDueLimit.NextDueCalculationStrategy (DueLimitSnapshot; nullable). HTML consolidation; backend/database adoption pending.
    7TimeOffsetHours
    Reviewed
    decimal?Nullable
    Required for: RequirementDefinition

    In plain language A waiting period measured in ordinary clock hours from a selected event.

    Real-world situation

    Task A finishes at 09:00. A linked rule requires task B two hours later.

    What this means in practice Task B is due at 11:00 even if the aircraft never flies. These are elapsed hours, not flying hours.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Elapsed-time offset from an agreed baseline, including a matched EventRequirements trigger. Elapsed clock hours must remain distinct from flight-hour consumption.

    Required decimal offset retained from the source definition. When a linked EventRequirements rule supplies the baseline, apply the agreed elapsed-hour offset from its matched occurrence timestamp. Example: a value of 2 gives two elapsed hours after valid task completion. Aircraft flight hours and cycles use structured TimeRequirementLimit dimensions. The exact baseline and unit interpretation must be confirmed during adoption.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.TimeOffsetHours (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    8DueAt
    Reviewed
    DateTime?Nullable
    Required for: Optional

    In plain language An exact calendar deadline including the time, for one occurrence.

    Real-world situation

    An approved rule requires action 30 elapsed days after 1 May at 08:00 UTC.

    What this means in practice The deadline is 31 May at 08:00 UTC. Unlike DueDate, this field retains the time of day.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Occurrence-specific calendar due timestamp. It records the calculated calendar deadline, while ExpectedAt can be a projection from usage.

    Calculated UTC calendar due timestamp on DueLimitSnapshot. Preserve the occurrence-specific value and source baseline. Existing requirement-level DueDate is DateOnly and remains separately documented; converting between a date and timestamp requires an explicit rule.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.DueAt (DueLimitSnapshot; nullable). HTML consolidation; backend/database adoption pending.
    9DueValue
    Reviewed
    decimal?Nullable
    Required for: Optional

    In plain language The total meter/counter value at which work becomes due.

    Real-world situation

    The inspection was last done at 1,000 flying hours and repeats after 500 more.

    What this means in practice DueValue is 1,500 hours. It is not 500; 500 is the interval amount.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Absolute counter reading at which an occurrence is due. It differs from Amount, which is the increment, and RemainingValue, which is the distance from the observation.

    Records the due value for this maintenance event due limit.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.DueValue (DueLimitSnapshot; nullable). HTML consolidation; backend/database adoption pending.
    10ValidityDate
    Reviewed
    DateOnly?Nullable
    Required for: Optional

    In plain language A date through which something is valid in the relevant business context.

    Real-world situation

    A qualification-related timing record says the qualification is valid through 31 December.

    What this means in practice This can support validity checking under defined rules. It is not automatically an aircraft inspection deadline; the intended role needs review.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Current decision: Restored and Reviewed in TimeRequirements, superseding the previous dropped decision. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Date-only validity endpoint for the requirement’s applicable business context. Its distinction from the maintenance due date must be defined for each use.

    Records the validity date for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ValidityDate (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.

    Amounts and measurements

    1 fields
    #FieldProposed typeNullability / required row typePlain explanation, practical example and source
    1Amount
    Merged · Reviewed
    decimal?Nullable
    Required for: LimitDefinition, DueLimitSnapshot

    Consolidated limit design: Use Amount (numeric value) + Dimension for each limit. LimitType = Threshold identifies first-due timing; LimitType = Interval identifies recurrence. HoursLimit, CyclesLimit, DaysLimit and TimeThresholdValue are dropped as separate fields and represented by structured limit rows.

    In plain language The numeric value of a threshold or repeat interval, interpreted together with Dimension, LimitType and the approved baseline.

    Real-world situation

    For the hours limit Maya enters 500 and selects flight hours. For the other limit she enters 6 and selects calendar months.

    What this means in practice 500 means 500 additional flying hours; 6 means six months. The unit and starting point are necessary to calculate the deadline.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Merged · Reviewed: Consolidates the legacy HoursLimit, CyclesLimit, DaysLimit and TimeThresholdValue representations into structured limits. One parent may have multiple limit rows, each retaining its own amount, dimension, limit type, baseline and combination scope. For example, first due at 5,000 flight cycles since new is Amount = 5000, Dimension = FC, LimitType = Threshold with a since-new baseline; repeat every 500 flight cycles is a separate Interval row with Amount = 500 and the approved next-due strategy. Resolve legacy meaning before mapping and preserve conflicts for explicit reconciliation. Do not add the legacy fields as parallel calculations. The existing Value field remains the separate historical CounterReading value. HTML review only; backend/database unchanged.

    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Magnitude of the threshold or interval in the selected Dimension. It is captured on an applied snapshot so later definition changes cannot rewrite that occurrence’s inputs.

    Positive threshold/interval amount on LimitDefinition; captured approved amount on DueLimitSnapshot. The two roles have separate rows so changes to a definition do not mutate an existing occurrence. Retain source precision of at least decimal(18,4).
    Used by: LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirementLimit.Amount (LimitDefinition; required); MaintenanceEventDueLimit.Amount (DueLimitSnapshot; required). Legacy header representations mapped into structured LimitDefinition rows: TimeRequirements.HoursLimit, TimeRequirements.CyclesLimit, TimeRequirements.DaysLimit, TimeRequirements.TimeThresholdValue (RequirementDefinition; nullable; consolidated). HTML consolidation; backend/database adoption pending.

    Descriptions and details

    1 fields
    #FieldProposed typeNullability / required row typePlain explanation, practical example and source
    1RequirementText
    Reviewed
    string?Nullable
    Required for: Optional

    In plain language A plain description of what must be done or complied with.

    Real-world situation

    Maya writes “Inspect the hydraulic filter for the condition specified in the approved procedure”.

    What this means in practice People understand the obligation. The timing and the detailed work instructions still come from their controlled records.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Narrative description of the obligation and its context. Calculations still require explicit dimensions, amounts and baselines.

    Records requirement text for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RequirementText (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.

    Audit and revision

    2 fields
    #FieldProposed typeNullability / required row typePlain explanation, practical example and source
    1SystemAuditId
    Reviewed
    Guid?Nullable
    Required for: Optional

    In plain language A computer link to the change history for this record.

    Real-world situation

    Maya changes the approved interval after review; the record links to its audit history.

    What this means in practice A reviewer can find who changed it and when. This ID does not represent an interval, aircraft or meter reading.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Links this row to Coflyr audit history. It supports traceability of changes and is not a maintenance rule or counter value.

    Links to system audit history when this model stores the reference.
    Used by: All, LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirements.SystemAuditId (All; nullable); TimeRequirementLimit.SystemAuditId (LimitDefinition; nullable); MaintenanceEventDueLimit.SystemAuditId (DueLimitSnapshot; nullable); CounterRecord.SystemAuditId (All; nullable). HTML consolidation; backend/database adoption pending.
    2UpdateId
    Reviewed
    Guid?Nullable
    Required for: Optional

    In plain language A legacy computer link to an earlier version/update record.

    Real-world situation

    The new requirement version links to the version it replaces.

    What this means in practice The history can be followed. This is different from selecting the parent inspection that owns a limit; the exact version-link rules still need adoption review.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Legacy link to a preceding update/revision record. The adopted design must distinguish it from the owning parent and preserve stable historical references.

    Links to the preceding revision or update record.
    Used by: All, LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirements.UpdateId (All; nullable); TimeRequirementLimit.UpdateId (LimitDefinition; nullable); MaintenanceEventDueLimit.UpdateId (DueLimitSnapshot; nullable); CounterRecord.UpdateId (All; nullable). HTML consolidation; backend/database adoption pending.

    Other fields

    29 fields
    #FieldProposed typeNullability / required row typePlain explanation, practical example and source
    1CalculationInfo
    Reviewed
    string?Nullable
    Required for: Optional

    In plain language A readable explanation of how the saved deadline was calculated, or why calculation failed.

    Real-world situation

    The saved note says “1,000 + 500 = due at 1,500 hours; current 1,200; remaining 300”.

    What this means in practice A planner can check the arithmetic. If a required reading is missing, this field can explain that instead of showing a misleading deadline.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Human-readable explanation of an applied calculation, including missing inputs or restrictions. It helps a planner understand the result without replacing the structured values.

    Records calculation info for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.CalculationInfo (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    2GracePeriodDays
    Reviewed
    int?Nullable
    Required for: Optional

    In plain language An old field for a possible days allowance after a nominal endpoint.

    Real-world situation

    A legacy record contains 5 days of grace.

    What this means in practice The team must check the approved source before using those five days. The field alone does not authorize completing a mandatory inspection late.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Legacy grace-period quantity. Any use must be explicitly authorized and reconciled with structured tolerances; it must not automatically extend a mandatory limit.

    Records grace period days for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.GracePeriodDays (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    3RegulatoryFrameworkBusinessPartnerId
    Merged · BusinessPartner lookup · Reviewed
    Guid?
    BusinessPartner lookup
    Nullable
    Required for: RequirementDefinition

    Merge decision: JurisdictionBusinessPartnerId is merged into RegulatoryFrameworkBusinessPartnerId, the single BusinessPartner lookup for the regulatory or jurisdiction authority associated with the obligation. The separate jurisdiction lookup is dropped.

    In plain language Selects the BusinessPartner representing the regulatory or jurisdiction authority associated with the obligation, consolidating the former JurisdictionBusinessPartnerId lookup.

    Real-world situation

    Maya selects the BusinessPartner record for the regulatory or jurisdiction authority identified by the controlled compliance document.

    What this means in practice A reviewer sees the selected regulatory authority’s name, while the field stores its BusinessPartner identifier. The source publication, version and clause still identify the applicable rules; selecting an authority alone does not prove approval or applicability.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Merged · Reviewed: JurisdictionBusinessPartnerId → RegulatoryFrameworkBusinessPartnerId. Keep one nullable Guid lookup to BusinessPartner.Id, required for RequirementDefinition rows as before. During later adoption, retain the valid regulatory-authority lookup; use the jurisdiction partner when the target is missing and it represents the relevant authority. Resolve legacy jurisdiction text and regulatory-framework enum values explicitly to saved BusinessPartner records. If the two source partners differ, preserve both and reconcile them explicitly before migration; do not silently overwrite or discard either. Preserve the source publication, version and clause. Original jurisdiction definition remains in dropped history. HTML review only; backend/database unchanged.

    Reviewed HTML rename and type change: RegulatoryFramework → RegulatoryFrameworkBusinessPartnerId. Nullable Guid lookup to BusinessPartner.Id, replacing the former enum. Original type: RegulatoryFramework? { None, Easa, Faa, CaaUk, CaaCanada, GcaaUae, DgcaIndia, CasaAustralia, CaasSingapore, Other }. Map legacy authority values explicitly to saved BusinessPartner records; None does not become a partner record, and Other needs explicit resolution. Preserve the source publication, revision and clause that define the framework. Earlier source descriptions retained below for history. Backend/database unchanged.

    Detailed design note: Text identifying the framework from which a requirement originates. It supports source classification but does not prove approval or applicability.

    Records regulatory framework for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RegulatoryFramework (RequirementDefinition; required; renamed to BusinessPartner lookup); TimeRequirements.Jurisdiction (RequirementDefinition; required; renamed JurisdictionBusinessPartnerId, merged). HTML consolidation; backend/database adoption pending.
    4RenewalWindowDays
    Reviewed
    int?Nullable
    Required for: Optional

    In plain language How early renewal planning may start before something expires.

    Real-world situation

    A qualification expires on 31 December, and its renewal window is 30 days.

    What this means in practice The intended workflow can begin renewal planning 30 days before expiry. It does not allow 30 extra days after expiry.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Legacy lead time for opening a renewal workflow before expiry. It is distinct from a tolerance permitting late accomplishment.

    Records renewal window days for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RenewalWindowDays (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    5RequirementCode
    Merged · Reviewed
    string?Nullable
    Required for: RequirementDefinition

    Resolution: RequirementCode is the single editable identifier for search and reference. ShortcutCode is merged and dropped as a separate field.

    In plain language The single business code people use to identify and quickly find the requirement, consolidating the former ShortcutCode field.

    Real-world situation

    Maya enters HYD-FILTER-INSPECTION-01.

    What this means in practice People can search or quote the code. The computer still keeps a separate permanent ID, and the code is not an hours/cycles counter code.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Merged · Reviewed: ShortcutCode → RequirementCode. Keep the existing required requirement code; use a valid shortcut only where the requirement code is missing, subject to the adopted code uniqueness and scope rules. If both source codes differ, preserve the legacy shortcut for reconciliation and historical reference rather than overwriting the requirement code or concatenating the two. Any continuing legacy-alias lookup needs an explicit adoption mapping; this HTML change does not implement one. The separate shortcut field and its independent editing path are removed from the proposal. Backend/database unchanged.

    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Business code identifying the requirement for users and references. It is separate from the stable UUID and from the code of a counter definition.

    Records requirement code for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RequirementCode (RequirementDefinition; required); TimeRequirements.ShortcutCode (RequirementDefinition; nullable; merged). HTML consolidation; backend/database adoption pending.
    6RequirementType
    Renamed · Reviewed
    RequirementType? { Threshold, Interval }Nullable
    Required for: Optional

    In plain language Says whether this timing requirement concerns the first inspection (Threshold) or repeat inspections (Interval).

    Real-world situation

    The first inspection at 5,000 cycles has RequirementType = Threshold. Repeat inspections every 500 cycles have RequirementType = Interval.

    What this means in practice A threshold means “first due”; an interval means “repeat after this much more”. Keep RequirementType consistent with the LimitType of its individual limits.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Renamed · Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.
    Reviewed HTML rename: RequirementGroupType → RequirementType. Proposed nullable enum: RequirementType { Threshold, Interval }. Original source enum is RequirementGroupType. The former competency-based RequirementType is retained separately in dropped history; backend/database unchanged.

    Detailed design note: Renamed from RequirementGroupType; classifies the timing requirement using the RequirementType enum with Threshold and Interval values. This reflects first-accomplishment versus repeat timing; per-limit LimitType must remain consistent.

    Records requirement group type for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RequirementGroupType (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    7RequirementTitle
    Merged · Reviewed
    string?Nullable
    Required for: Optional

    Merge decision: RecordName is merged into RequirementTitle, the single readable name for the requirement. The separate RecordName field is dropped.

    In plain language The single readable name or title describing the requirement, consolidating the former RecordName and RequirementTitle fields.

    Real-world situation

    Maya enters “Hydraulic filter inspection”.

    What this means in practice People recognize the requirement without decoding its business code. The title itself does not configure the 500-hour interval.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Merged · Reviewed: RecordName → RequirementTitle. Keep one nullable string for the RequirementDefinition label. During later adoption, retain an existing nonblank RequirementTitle; use RecordName when the title is blank. Where both contain different nonblank values, preserve both source values for explicit reconciliation before migration and do not silently discard either. Original RecordName definition remains in dropped history. HTML review only; backend/database unchanged.

    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Human-readable title describing the timing requirement. AMOS time-requirement headers have an optional title and description.

    Records requirement title for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RequirementTitle (RequirementDefinition; nullable); TimeRequirements.RecordName (RequirementDefinition; nullable; merged). HTML consolidation; backend/database adoption pending.
    8SourceType
    Reviewed · Merged
    RequirementSourceType? { Unclassified, IcaoStandard, IcaoRecommendedPractice, Regulation, Guidance, InternalPolicy, Regulatory, Publication, OperatorPolicy, Reliability, Contractual, InternalEngineering, TrainingProvider, InternalCompliance, Other }Nullable
    Required for: RequirementDefinition

    In plain language Says where the requirement came from: a publication, operator policy, regulation or another source category.

    Real-world situation

    The inspection instruction comes from a manufacturer publication, so Maya chooses Publication.

    What this means in practice The origin is clear. It is different from how a meter reading was entered; legacy SourceKind values must be reconciled here.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Shared classification of the requirement’s originating source, merging the former SourceKind and SourceType vocabularies. It differs from a counter reading’s entry source.

    Single required source classification replacing SourceType and SourceKind in TimeRequirements. Retains the legacy enum choices in one proposed RequirementSourceType enum. Regulatory is a general regulatory-source category; Regulation identifies an explicit regulation. Map legacy labels by name, rather than reusing numeric enum values. Where the old fields contain different classifications, review the source publication and select one explicit value; do not silently discard either original value or concatenate conflicting classifications. Reviewed HTML proposal; backend/database adoption pending.
    Sources: Requirements.SourceType, Requirements.SourceKind. TimeRequirements merge only.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.SourceType (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    9SourceUrl
    Reviewed
    string?Nullable
    Required for: Optional

    In plain language An optional web/document link that helps someone open the source.

    Real-world situation

    Maya adds the manufacturer portal link for the inspection instruction.

    What this means in practice A reviewer can reach the source more quickly. The selected publication and version are still necessary because content at a link can change.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Optional link to supporting source material. Keep the controlled publication identity/revision as well because the linked content can change.

    Records source url for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.SourceUrl (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    10ToGoDays
    Reviewed
    int?Nullable
    Required for: Optional

    In plain language A summary estimate of how many days remain before the limit is reached.

    Real-world situation

    The aircraft has 300 flying hours left and is expected to fly five hours per day.

    What this means in practice The estimate is 60 days. This is a forecast, not permission to fly for 60 days regardless of the actual hours accumulated.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Header summary of estimated calendar days remaining. For usage limits it depends on utilization and must not replace the actual counter margin.

    Records to go days for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ToGoDays (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    11ValidityPeriodUnit
    Reviewed
    TrainingRecurrenceUnit? { Days, Weeks, Months, Years }Nullable
    Required for: Optional

    In plain language The unit paired with a validity duration, such as months or years.

    Real-world situation

    A qualification’s validity duration is 12, with Months selected.

    What this means in practice The duration means twelve months. The agreed starting event is still needed to calculate the exact expiry date.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Calendar unit for the inherited validity-period quantity. It describes the duration of validity, which can differ from a renewal-planning window.

    Records validity period unit for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ValidityPeriodUnit (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    12ValidityPeriodValue
    Reviewed
    int?Nullable
    Required for: Optional

    In plain language The number in a validity duration.

    Real-world situation

    Maya enters 12 and selects Months in ValidityPeriodUnit.

    What this means in practice The record describes a one-year validity period, if that is the approved rule. It does not describe a 12-day renewal window.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Number of units for the inherited validity duration. Its baseline and relationship to ValidityDate must be defined for the record’s business role.

    Records validity period value for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ValidityPeriodValue (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    13Dimension
    Merged · Reviewed
    CounterDimension? { FH, FC, DY, MO, YR, AH, OD, Custom }Nullable
    Required for: LimitDefinition, DueLimitSnapshot

    In plain language The unit/category of this deadline: flying hours, cycles, days, months or another supported counter.

    Real-world situation

    For “500 flying hours” select FH. For “six calendar months” select MO.

    What this means in practice Coflyr can interpret the amount. AMOS uses AH for APU hours and OD for operational days; current Coflyr OD handling differs and needs review.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: What a limit measures: FH, FC, calendar days/months/years, AH or a custom counter. AMOS uses AH for APU hours and OD for operational days. Coflyr currently treats OD as on-demand and cannot forecast it; that mapping needs review.

    Source limit dimension used by LimitDefinition and DueLimitSnapshot. The source wording classified AH as aircraft hours and OD as on-demand; AMOS documents APU hours and operational days respectively. Reconcile these mappings explicitly; enum values and backend behavior remain unchanged by this HTML review. Required for both roles. This is distinct from CounterValueDimension on a counter definition; explicitly validate that a selected counter supports the required dimension.
    Used by: LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirementLimit.Dimension (LimitDefinition; required); MaintenanceEventDueLimit.Dimension (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    14LimitType
    Merged · Reviewed
    TimeRequirementLimitType? { Threshold, Interval }Nullable
    Required for: LimitDefinition, DueLimitSnapshot

    Recurrence decision: Structured Interval limits are the authoritative recurrence configuration, using Amount, Dimension, the approved baseline and next-due strategy. RecurrentFrequencyValue and RecurrentFrequencyUnit are dropped; their original definitions are retained in history.

    In plain language Says whether the limit is for the first occurrence or a repeat occurrence.

    Real-world situation

    A source says first inspect at 5,000 cycles, then every 500 cycles.

    What this means in practice Create a Threshold of 5,000 and an Interval of 500. The first number is not automatically reused as the repeat interval.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Distinguishes a first-accomplishment Threshold from a repeating Interval. A threshold is not automatically an interval after the first performance.

    Threshold or recurring Interval on a LimitDefinition, captured unchanged on its DueLimitSnapshot. Required for both roles; do not infer it from the parent row or the existence of prior occurrences.
    Used by: LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirementLimit.LimitType (LimitDefinition; required); MaintenanceEventDueLimit.LimitType (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    15LowerRangeValue
    Merged · Reviewed
    decimal?Nullable
    Required for: Optional

    In plain language The lower boundary of a usage range used to decide which rule applies.

    Real-world situation

    An approved rule applies to components from 5,000 to below 10,000 cycles. Enter 5,000 as the lower boundary.

    What this means in practice The range selects the applicable rule. It is not the amount of extra cycles allowed before the inspection; boundary treatment must be explicitly defined.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Coflyr field for the lower boundary of a conditional limit-applicability range. AMOS supports rules based on actual/historical counter values; boundary inclusivity and the referenced counter must be defined explicitly.

    Records lower range value for this time requirement limit.
    Used by: LimitDefinition.
    Sources: TimeRequirementLimit.LowerRangeValue (LimitDefinition; nullable). HTML consolidation; backend/database adoption pending.
    16ToleranceNegative
    Merged · Reviewed
    decimal?Nullable
    Required for: Optional

    In plain language An approved allowance for doing work earlier than its nominal due point.

    Real-world situation

    An AMOS example is due at 6,000 cycles, with an early window beginning at 4,000 cycles; the negative allowance is 2,000 cycles.

    What this means in practice This describes the early window. It does not mean subtract 2,000 from all future deadlines; next-due treatment depends on the approved strategy.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Approved early-accomplishment tolerance associated with a limit. AMOS describes negative tolerance as the early window; its effect on the next due value depends on strategy.

    Records tolerance negative for this time requirement limit.
    Used by: LimitDefinition.
    Sources: TimeRequirementLimit.ToleranceNegative (LimitDefinition; nullable). HTML consolidation; backend/database adoption pending.
    17TolerancePositive
    Merged · Reviewed
    decimal?Nullable
    Required for: Optional

    In plain language An approved allowance after the nominal due point, subject to the source’s conditions.

    Real-world situation

    A source gives a nominal 12-month interval with a specified one-month positive allowance.

    What this means in practice The allowance can be considered only under its approved rules. It must not automatically shift every later interval or act as a blanket extension.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Approved late-accomplishment tolerance associated with a limit. It does not automatically reset the next baseline or authorize use beyond approved conditions.

    Records tolerance positive for this time requirement limit.
    Used by: LimitDefinition.
    Sources: TimeRequirementLimit.TolerancePositive (LimitDefinition; nullable). HTML consolidation; backend/database adoption pending.
    18UpperRangeValue
    Merged · Reviewed
    decimal?Nullable
    Required for: Optional

    In plain language The upper boundary of the usage range used to choose an applicable rule.

    Real-world situation

    One approved interval applies below 10,000 cycles; another applies from 10,000 cycles.

    What this means in practice The boundary decides which interval is relevant. Define inclusivity so an asset at exactly 10,000 does not fall into both rules or neither.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Coflyr field for the upper boundary of a conditional applicability range. Its counter, unit and inclusive/exclusive treatment need an explicit rule.

    Records upper range value for this time requirement limit.
    Used by: LimitDefinition.
    Sources: TimeRequirementLimit.UpperRangeValue (LimitDefinition; nullable). HTML consolidation; backend/database adoption pending.
    19BaselineAt
    Merged · Reviewed
    DateTime?Nullable
    Required for: DueLimitSnapshot

    In plain language The actual starting date/time used in a saved calculation.

    Real-world situation

    The previous inspection was completed on 1 January 2026 at 08:00 UTC.

    What this means in practice That timestamp is saved as the starting point before adding six calendar months. TimeBaselineType explains why that starting point was chosen.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Resolved starting timestamp captured for a calendar or event-based due calculation. It is the actual input, while TimeBaselineType describes how it was chosen.

    Records the baseline at for this maintenance event due limit.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.BaselineAt (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    20BaselineValue
    Merged · Reviewed
    decimal?Nullable
    Required for: DueLimitSnapshot

    In plain language The actual starting usage value used in a saved calculation.

    Real-world situation

    The previous inspection was completed when the aircraft had 1,000 flying hours.

    What this means in practice Save 1,000 here. Adding the 500-hour interval produces a deadline of 1,500 aircraft hours.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Resolved starting counter value captured for a usage-based calculation.

    Records baseline value for this maintenance event due limit.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.BaselineValue (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    21CurrentValue
    Merged · Reviewed
    decimal?
    NotMapped · no database column
    Nullable
    Required for: DueLimitSnapshot, AssetCounter

    Mapping decision: NotMapped. No database column required in TimeRequirements. Provide the current or calculation-time usage value at runtime from the relevant counter evidence. Historical calculations must still use their original observation rather than a later live reading.

    In plain language The aircraft/component’s latest usage total, or the usage total captured for one saved calculation, depending on the record type.

    Real-world situation

    VT-ABC currently has 1,200 flying hours, and a due calculation is saved using 1,200.

    What this means in practice When a new flight raises the live total to 1,205, the old saved calculation must still show the 1,200 it originally used.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed as NotMapped in the TimeRequirements HTML proposal. No TimeRequirements database column required. Backend/database unchanged.
    HTML mapping decision: CurrentValue is NotMapped and does not require a TimeRequirements database column. This supersedes the earlier mapped-column proposal retained below for history. Backend/database unchanged.

    Detailed design note: On AssetCounter, the latest live counter total; on DueLimitSnapshot, the counter value captured for that calculation. These are separate rows and a historical snapshot must not change with the live counter.

    Shared decimal column used independently by two roles: AssetCounter holds the live current value; DueLimitSnapshot holds the counter value captured for that particular calculation. Updating the live row must not overwrite the captured row. Preserve at least decimal(20,6), which accommodates the source decimal(18,4) snapshots and decimal(20,6) counters.
    Used by: DueLimitSnapshot, AssetCounter.
    Sources: MaintenanceEventDueLimit.CurrentValue (DueLimitSnapshot; required); AssetCounter.CurrentValue (AssetCounter; required). Original source mapping retained for history. Current HTML decision: NotMapped; no TimeRequirements database column required. Backend/database unchanged.
    22ExpectedAt
    Merged · Reviewed
    DateTime?
    NotMapped · no database column
    Nullable
    Required for: Optional

    Mapping decision: NotMapped. No database column required in TimeRequirements. Calculate the forecast timestamp from the applicable deadline, remaining usage and utilization assumptions.

    In plain language The estimated date and time at which a usage limit will be reached.

    Real-world situation

    On 1 May the aircraft has 300 flying hours remaining. At five hours per day, this is about 60 days.

    What this means in practice The forecast is around 30 June. If utilization changes, the forecast date changes; the fixed 1,500-hour limit remains the same.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed as NotMapped in the TimeRequirements HTML proposal. No TimeRequirements database column required. Backend/database unchanged.
    HTML mapping decision: ExpectedAt is NotMapped and does not require a TimeRequirements database column. This supersedes the earlier mapped-column proposal retained below for history. Backend/database unchanged.

    Detailed design note: Projected timestamp at which a usage-driven deadline will be reached. It depends on daily utilization, while DueValue is the fixed counter threshold.

    Projected UTC due timestamp for this DueLimitSnapshot. For counter limits it is a utilization estimate; preserve the observation and calculation version. Requirement-level ExpectedDate is DateOnly and is not silently substituted for this timestamp.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.ExpectedAt (DueLimitSnapshot; nullable). Original source mapping retained for history. Current HTML decision: NotMapped; no TimeRequirements database column required. Backend/database unchanged.
    23UtilizationPerDay
    Merged · Reviewed
    decimal?
    NotMapped · no database column
    Nullable
    Required for: Optional

    Mapping decision: NotMapped. No database column required in TimeRequirements. Provide the daily usage assumption as a runtime planning input for the particular forecast; it does not alter the approved counter deadline.

    In plain language How much daily use the planner/software assumes for this particular forecast.

    Real-world situation

    Maya uses five flying hours per day for VT-ABC’s forecast.

    What this means in practice 300 hours remaining divided by five hours/day gives about 60 days. This assumption forecasts a date; it does not alter the approved hours deadline.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed as NotMapped in the TimeRequirements HTML proposal. No TimeRequirements database column required. Backend/database unchanged.
    HTML mapping decision: UtilizationPerDay is NotMapped and does not require a TimeRequirements database column. This supersedes the earlier mapped-column proposal retained below for history. Backend/database unchanged.

    Detailed design note: Daily usage assumption captured for this applied calculation. It converts a usage margin into an estimated calendar date; it does not change the approved usage limit.

    Records utilization per day for this maintenance event due limit.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.UtilizationPerDay (DueLimitSnapshot; nullable). Original source mapping retained for history. Current HTML decision: NotMapped; no TimeRequirements database column required. Backend/database unchanged.
    24DailyAverage
    Merged · Reviewed
    decimal?
    NotMapped · no database column
    Nullable
    Required for: Optional

    Mapping decision: NotMapped. No database column required; provide the default average daily usage as a planning input or derived value.

    In plain language A default average daily usage used as a planning assumption.

    Real-world situation

    The counter definition has a default of five flying hours per day.

    What this means in practice This may provide an initial forecast assumption. A saved aircraft-specific forecast records the actual assumption used in UtilizationPerDay, which may be different.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed as NotMapped in the TimeRequirements HTML proposal. No TimeRequirements database column required; provide default daily usage as a planning input or derived value. Backend/database unchanged.
    HTML mapping decision: DailyAverage is NotMapped and does not require a database column. Original source definition retained below for history. Backend/database unchanged.

    Detailed design note: Default average usage associated with a counter definition in the source model. A snapshot’s UtilizationPerDay records the specific assumption actually used for that forecast.

    Records daily average for this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.DailyAverage (CounterDefinition; nullable). Original source mapping retained for history. Current HTML decision: NotMapped; no database column required. Backend/database unchanged.
    25CounterValueDimension
    Merged · Reviewed
    CounterValueDimension? { Hours, Cycles, Landings, CalendarDays, Events, Quantity }Nullable
    Required for: CounterDefinition

    Resolved unit/category design: CounterValueDimension remains the explicit controlled category. MeasurementUnitId selects the concrete unit. Do not derive or overwrite the category from the current free-text MeasureUnit.UnitCategory.

    In plain language The broad kind of quantity a counter measures, such as hours or cycles.

    Real-world situation

    A flying-hours counter is classified Hours; a flight-cycles counter is classified Cycles.

    What this means in practice The system can check unit compatibility. An APU-hours counter also measures hours, so the broader category alone is not enough to select the correct counter.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Reviewed compatibility rule: CounterDefinition requires a saved unit and an explicit counter category with different responsibilities. During adoption, validate the pair using an approved mapping from saved unit identities to allowed CounterValueDimension values; reject incompatible pairs and require explicit mapping for unclassified units. Hours units may serve aircraft or APU counters; their specific identity/purpose must still agree with the selected limit. Do not cast enum values or guess categories from names, symbols, UnitCategory or UnitGroup text. Retain CounterValueDimension as mapped until a controlled, complete unit-category mapping exists. This is the HTML design requirement; backend/database enforcement is unchanged.

    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Broad measurement category of a counter, such as Hours, Cycles or CalendarDays. It differs from a limit Dimension, which also represents specific calendar units.

    Dimension of a CounterDefinition value: Hours, Cycles, Landings, CalendarDays, Events or Quantity. Renamed from CounterDefinition.Dimension to preserve its different enum and meaning. Do not cast its numeric enum to the maintenance-limit Dimension enum.
    Used by: CounterDefinition.
    Sources: CounterDefinition.Dimension (CounterDefinition; required). HTML consolidation; backend/database adoption pending.
    26AppliesToType
    Merged · Reviewed
    string?Nullable
    Required for: Optional

    In plain language Legacy text describing the broad intended use of a counter bundle.

    Real-world situation

    Maya writes “Airframe counters”.

    What this means in practice The description is helpful, but an actual aircraft-type or part assignment must still identify who receives the bundle.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Legacy text describing the intended applicability of a counter-template group. Structured assignments should identify actual aircraft types or parts.

    Records applies to type for this counter template group.
    Used by: CounterTemplateGroup.
    Sources: CounterTemplateGroup.AppliesToType (CounterTemplateGroup; nullable). HTML consolidation; backend/database adoption pending.
    27LastReadoutAt
    Merged · Reviewed
    DateTime?
    NotMapped · no database column
    Nullable
    Required for: Optional

    Mapping decision: NotMapped. No database column required in TimeRequirements. Provide the latest reading observation time from the applicable counter evidence at runtime; refreshing a forecast does not change that observation time.

    In plain language When the most recent reading represented by this asset counter was taken.

    Real-world situation

    The latest aircraft hours reading is from yesterday at 18:00.

    What this means in practice A planner can judge whether the live total is current. Recalculating a forecast today does not make that old reading a new observation.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed as NotMapped in the TimeRequirements HTML proposal. No TimeRequirements database column required. Backend/database unchanged.
    HTML mapping decision: LastReadoutAt is NotMapped and does not require a TimeRequirements database column. This supersedes the earlier mapped-column proposal retained below for history. Backend/database unchanged.

    Detailed design note: Timestamp of the latest readout represented by an asset counter. It helps judge currency and is separate from a snapshot’s refresh timestamp.

    Records the last readout at for this asset counter.
    Used by: AssetCounter.
    Sources: AssetCounter.LastReadoutAt (AssetCounter; nullable). Original source mapping retained for history. Current HTML decision: NotMapped; no TimeRequirements database column required. Backend/database unchanged.
    28SinceNewValue
    Merged · Reviewed
    decimal?
    NotMapped · no database column
    Nullable
    Required for: Optional

    Mapping decision: NotMapped. No database column required in TimeRequirements. Provide documented total usage since new from the component usage history at runtime; a replaced or reset meter must not erase earlier usage.

    In plain language All known usage accumulated by the component since it was new.

    Real-world situation

    A pump’s meter has been replaced and shows 50 hours, but its documented total since new is 2,350 hours.

    What this means in practice Its component history must preserve 2,350, not pretend it is a new 50-hour pump. Meter display and total life usage can differ.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed as NotMapped in the TimeRequirements HTML proposal. No TimeRequirements database column required. Backend/database unchanged.
    HTML mapping decision: SinceNewValue is NotMapped and does not require a TimeRequirements database column. This supersedes the earlier mapped-column proposal retained below for history. Backend/database unchanged.

    Detailed design note: Total accumulated usage since manufacture/new, where known. This differs from a physical meter’s display and from usage since the latest installation.

    Records since new value for this asset counter.
    Used by: AssetCounter.
    Sources: AssetCounter.SinceNewValue (AssetCounter; nullable). Original source mapping retained for history. Current HTML decision: NotMapped; no TimeRequirements database column required. Backend/database unchanged.
    29Value
    Merged · Reviewed
    decimal?Nullable
    Required for: CounterReading

    In plain language The actual number stored on one historical reading.

    Real-world situation

    Ravi saves a reading of 1,200 flying hours for VT-ABC.

    What this means in practice That reading remains 1,200 even after later readings reach 1,205. The latest live total and the history are separate records.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Historical value captured by a CounterReading row. It is not the live asset total by identity, even when the latest reading currently equals that total.

    Actual value captured on a CounterReading row. Preserve decimal(20,6), recorded time, source and administrative-correction evidence. A historical reading is separate from the AssetCounter live CurrentValue and a DueLimitSnapshot captured CurrentValue.
    Used by: CounterReading.
    Sources: CounterReading.Value (CounterReading; required). HTML consolidation; backend/database adoption pending.

    Row identity and hierarchy

    1 fields
    #FieldProposed typeNullability / required row typePlain explanation, practical example and source
    1RecordKind
    Unified row type · Reviewed
    TimeRequirementRecordKind { RequirementDefinition, LimitDefinition, DueLimitSnapshot, CounterDefinition, CounterTemplateGroup, CounterTemplateGroupAssignment, CounterTemplate, AssetCounter, CounterReading }Required
    Required for: All row types

    In plain language Says what job this saved row performs in the proposed shared table.

    Real-world situation

    “Filter inspection” is a RequirementDefinition; “500 hours” is a LimitDefinition; “VT-ABC read 1,200 hours today” is a CounterReading.

    What this means in practice Although they share one table, they are different kinds of records and need different fields. This type is explicit; it is not guessed from whether a record has children.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Required Coflyr discriminator identifying one of the nine row roles in the unified table. It determines applicable fields and valid lookup targets; the presence of children does not determine the role.

    Required explicit row role in the single TimeRequirements table. Maps the legacy counter RecordKind values to their corresponding roles and adds RequirementDefinition, LimitDefinition and DueLimitSnapshot. A row has one role; do not infer it from whether children exist. Parent/lookup targets and required fields must be validated by role.
    Used by: All.
    Sources: CounterRecord.RecordKind (All; required). HTML consolidation; backend/database adoption pending.

    Dropped fields · retained for review

    #Former fieldSource typeNullabilityPlain explanation, practical example and source
    1AmendmentReference
    Dropped
    string?Nullable

    Historical example · this field remains dropped

    In plain language The old typed reference to a document amendment. It has been replaced in this proposal by selecting PublicationMasterId.

    Real-world situation

    An old record contains “Maintenance Programme Revision 12, Amendment 3”.

    What this means in practice During adoption, match that text to the correct saved publication/version. This old field stays dropped; unmatched text needs review rather than being discarded.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former free-text amendment reference, replaced in this proposal by PublicationMasterId. Retained as dropped history so existing text can be reconciled with controlled publications.

    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 TimeRequirements.
    2ApplicabilityReviewedByStaffMemberId
    Dropped
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language The former selection of the staff member who checked whether the requirement applied.

    Real-world situation

    An old record selects engineer Maya as the person who checked VT-ABC’s connector configuration.

    What this means in practice It explains the old reviewer link. The field remains dropped here; this example does not introduce a new active reviewer field.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former staff lookup identifying who reviewed applicability. It remains dropped here; the example explains its historical purpose without restoring it.

    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 TimeRequirements.
    3ComponentMaintenanceTaskId
    Dropped · Merged
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language The old component-task link that was renamed/combined with MaintenanceTaskId.

    Real-world situation

    An old inspection record points to a component task card for pump P100.

    What this means in practice Map it to the intended maintenance task explicitly. The owning-task link now belongs to EventRequirements; this old spelling stays dropped.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former component-task lookup renamed/merged into MaintenanceTaskId, which has moved to EventRequirements. Legacy TaskCard references require explicit mapping.

    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 TimeRequirements.
    4CompetencyTemplateId
    Dropped · Moved to ResourceRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects the qualification/training definition describing what competence is required. It has moved to ResourceRequirements.

    Real-world situation

    The work needs an A320 B1 qualification, so the resource rule selects that qualification template.

    What this means in practice This answers “what qualification is needed?” A separate timing rule answers “when does it expire or need renewing?” Future competency implementation remains pending.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Qualification/training-template lookup moved to ResourceRequirements and retained there for future development. It describes what competency is required, rather than when work is due.

    Moved to ResourceRequirements only, where this nullable competency training/qualification lookup remains Reviewed · Future development. It describes the resource qualification required, rather than when work is due. Retained here as dropped history; HTML review only, backend/database adoption pending.
    Source: Requirements.CompetencyTemplateId.
    5ConditionStatus
    Dropped · Moved to EventRequirements
    DeferralConditionStatus { Open, Satisfied, Waived, NotApplicable }
    EF: DeferralConditionStatus
    Required

    Historical example · this field remains dropped

    In plain language Says whether a required condition is still open or has been met. It has moved to EventRequirements.

    Real-world situation

    A required pre-dispatch action is Open until valid evidence shows that it was completed.

    What this means in practice The condition can then be recorded as Satisfied under its rules. This is different from reaching a calendar deadline and does not itself authorize release.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Status of a deferral/event condition, moved to EventRequirements. It concerns fulfillment of the condition, not the numerical timing calculation.

    Moved to EventRequirements. ConditionStatus is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.ConditionStatus. Assigned to TimeRequirements.
    6ConditionType
    Dropped · Moved to EventRequirements
    DeferralConditionType { DispatchPrerequisite, DispatchProhibition, OperationalRestriction, MaintenanceAction, Monitoring }
    EF: DeferralConditionType
    Required

    Historical example · this field remains dropped

    In plain language Says what kind of condition or restriction is involved. It has moved to EventRequirements.

    Real-world situation

    An approved deferred-item instruction requires a MaintenanceAction.

    What this means in practice The event/condition record identifies that action type. The linked timing rule separately tells the team when it must be done.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Classification of a deferral/event condition, moved to EventRequirements. The approved source determines the actual obligation and restrictions.

    Moved to EventRequirements. ConditionType is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.ConditionType. Assigned to TimeRequirements.
    7DependencyEnforcement
    Dropped · Moved to EventRequirements
    TimeRequirementEnforcement? { MakeDue, BlockStart, BlockCompletion, BlockRelease }Nullable

    Historical example · this field remains dropped

    In plain language Says what should be made due or blocked when a prerequisite applies. It has moved to EventRequirements.

    Real-world situation

    The approved workflow requires a check before task B can be completed, so the proposed rule uses BlockCompletion.

    What this means in practice Implementation must enforce that particular gate using evidence. Storing the choice alone does not create a working block.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Proposed event-dependency control moved to EventRequirements. It defines whether a matched dependency makes work due or blocks a workflow step; enforcement remains pending.

    Moved to EventRequirements. DependencyEnforcement is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    8LimitationText
    Dropped · Moved to EventRequirements
    string?Nullable

    Historical example · this field remains dropped

    In plain language The words describing an approved operating restriction. It has moved to EventRequirements.

    Real-world situation

    An approved deferred-item instruction contains a particular operating restriction, which is recorded with its source.

    What this means in practice People can read the actual restriction. Its exact wording comes from the approved instruction, not from a generic deadline field.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Narrative operational/deferral restriction moved to EventRequirements. It must reflect the approved source, not an automatically inferred restriction.

    Moved to EventRequirements. LimitationText is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.LimitationText. Assigned to TimeRequirements.
    9LimitationType
    Dropped · Moved to EventRequirements
    DeferralLimitationType { None, GroundHandling, Operations, Passengers }
    EF: DeferralLimitationType
    Required

    Historical example · this field remains dropped

    In plain language A category for an approved restriction. It has moved to EventRequirements.

    Real-world situation

    The restriction concerns ground handling, so the category is GroundHandling.

    What this means in practice The category organizes the restriction. The actual instruction and conditions must still be recorded separately.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Category of an operational restriction, moved to EventRequirements. It organizes the approved restriction but does not specify the restriction by itself.

    Moved to EventRequirements. LimitationType is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.LimitationType. Assigned to TimeRequirements.
    10MaintenanceProcedure
    Dropped · Moved to EventRequirements
    string?Nullable

    Historical example · this field remains dropped

    In plain language The maintenance action or controlled procedure reference associated with a condition. It has moved to EventRequirements.

    Real-world situation

    An approved deferred item requires a check described in a specified maintenance procedure.

    What this means in practice The team can identify what work is required. The time rule separately controls when it must be performed.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Maintenance action/procedure text moved to EventRequirements. It identifies required work or a controlled procedure reference; it is not a time interval.

    Moved to EventRequirements. MaintenanceProcedure is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.MaintenanceProcedure. Assigned to TimeRequirements.
    11NoGo
    Dropped · Moved to EventRequirements
    boolRequired

    Historical example · this field remains dropped

    In plain language A condition indicating that dispatch is prohibited under the applicable approved item. It has moved to EventRequirements.

    Real-world situation

    A defect’s approved MEL item is marked NoGo.

    What this means in practice Rectification and the authorized release process are required as applicable. A future due date does not cancel the prohibition.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Dispatch-prohibition indicator moved to EventRequirements. AMOS supports NoGo markings in MEL-related workflows; the flag must be interpreted through the approved item and conditions.

    Moved to EventRequirements. NoGo is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.NoGo. Assigned to TimeRequirements.
    12OperationsProcedure
    Dropped · Moved to EventRequirements
    string?Nullable

    Historical example · this field remains dropped

    In plain language The approved operating action needed while a condition exists. It has moved to EventRequirements.

    Real-world situation

    An approved deferred-item instruction requires a specified operating procedure until rectification.

    What this means in practice The instruction is visible to the relevant users. It does not define the maintenance interval by itself.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Operational procedure text moved to EventRequirements. It supplies approved operating actions separately from maintenance timing.

    Moved to EventRequirements. OperationsProcedure is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.OperationsProcedure. Assigned to TimeRequirements.
    13PlacardText
    Dropped · Moved to EventRequirements
    string?Nullable

    Historical example · this field remains dropped

    In plain language The text the approved instruction requires on a notice/placard. It has moved to EventRequirements.

    Real-world situation

    The instruction specifies an “INOPERATIVE” placard at a stated location.

    What this means in practice The team knows the required wording. Separate evidence must show that the required placard was actually installed.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Text of an approved placard moved to EventRequirements. It describes the notice, not the due interval or proof that a placard was installed.

    Moved to EventRequirements. PlacardText is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.PlacardText. Assigned to TimeRequirements.
    14PlacardingRequired
    Dropped · Moved to EventRequirements
    boolRequired

    Historical example · this field remains dropped

    In plain language Says a placard must be provided. It has moved to EventRequirements.

    Real-world situation

    The approved deferred item requires a placard, so its event condition records Yes.

    What this means in practice Yes means an obligation exists, not that someone has already fitted the placard. Completion evidence is still needed.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Requirement to provide a placard, moved to EventRequirements. It is distinct from confirmation that the placard has actually been installed.

    Moved to EventRequirements. PlacardingRequired is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.PlacardingRequired. Assigned to TimeRequirements.
    15RequiredBeforeAssignment
    Dropped · Moved to EventRequirements
    boolRequired

    Historical example · this field remains dropped

    In plain language A proposed prerequisite that must be satisfied before work is assigned. It has moved to EventRequirements.

    Real-world situation

    A qualification check is required before assigning the technician to the task.

    What this means in practice The future workflow must check the qualification before assignment. This is not a time interval and is not enforced merely by saving the flag.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Proposed prerequisite gate moved to EventRequirements. Its exact subject and enforcement must be defined before adoption.

    Moved to EventRequirements. RequiredBeforeAssignment is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.RequiredBeforeAssignment. Assigned to TimeRequirements.
    16RequiredBeforeCertifyingPrivilege
    Dropped · Moved to EventRequirements
    boolRequired

    Historical example · this field remains dropped

    In plain language A proposed prerequisite before a person exercises a relevant certifying privilege. It has moved to EventRequirements.

    Real-world situation

    An organization-defined check must be satisfied before that person certifies the relevant work.

    What this means in practice The authorization and condition need to be validated together. This flag does not grant the person a privilege.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Proposed prerequisite for exercising a certifying privilege, moved to EventRequirements. It does not grant the privilege or validate the person’s authorization.

    Moved to EventRequirements. RequiredBeforeCertifyingPrivilege is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.RequiredBeforeCertifyingPrivilege. Assigned to TimeRequirements.
    17RequiredBeforeRelease
    Dropped · Moved to EventRequirements
    boolRequired

    Historical example · this field remains dropped

    In plain language A proposed prerequisite that must be met before release. It has moved to EventRequirements.

    Real-world situation

    An independent check must be evidenced before the applicable release process.

    What this means in practice The release workflow must verify that evidence. Completing the timing calculation or marking a task complete is insufficient.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Proposed release prerequisite moved to EventRequirements. Completion of the condition is separate from the authorized release record.

    Moved to EventRequirements. RequiredBeforeRelease is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    Source: Requirements.RequiredBeforeRelease. Assigned to TimeRequirements.
    18TriggerEventDefinitionId
    Dropped · Moved to EventRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects the kind of event that starts a linked rule. It has moved to EventRequirements.

    Real-world situation

    The rule starts when a component-installation event occurs for the relevant asset.

    What this means in practice The actual installation event supplies the starting time. Selecting an event definition does not mean an installation has already occurred.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Reusable event definition selected as the trigger, moved to EventRequirements. It identifies what occurrence to match, rather than a particular occurrence timestamp.

    Moved to EventRequirements. TriggerEventDefinitionId is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    19TriggerMaintenanceTaskId
    Dropped · Moved to EventRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects task A whose occurrence starts or conditions task B. It has moved to EventRequirements.

    Real-world situation

    Task A is “Install the component”; task B is “Perform the follow-up leak check”.

    What this means in practice When valid completion of task A is matched, the timing rule for B can start. B is selected through its own owning-task link.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Task A selected as the prerequisite/trigger for task B, moved to EventRequirements. It differs from MaintenanceTaskId, which identifies the owning task B.

    Moved to EventRequirements. TriggerMaintenanceTaskId is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    20TriggerType
    Dropped · Moved to EventRequirements
    TimeRequirementTriggerType { CalendarOrCounter, AfterTaskCompletion, AfterTaskStart, BeforeTaskStart, WithTask, EventOccurred }Required

    Historical example · this field remains dropped

    In plain language Says what kind of occurrence starts a dependent rule. It has moved to EventRequirements.

    Real-world situation

    The follow-up check begins counting after the installation task is completed, so choose AfterTaskCompletion.

    What this means in practice A start event would not be enough. The event rule must match valid completion evidence and supply the correct timing baseline.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Proposed classification of how a timing rule is triggered, moved to EventRequirements. Event processing and timing calculation remain separate responsibilities.

    Moved to EventRequirements. TriggerType is no longer active on TimeRequirements. Original field and source type remain visible for review history. HTML proposal only; backend/database adoption pending complete review.
    21DeferredDefectMasterId
    Dropped · Moved to EventRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects the particular deferred defect that owns the condition. It has moved to EventRequirements.

    Real-world situation

    The event requirement selects defect DD-104.

    What this means in practice Its conditions and linked rectification timing belong to DD-104. Another deferred defect must have its own context even if the same kind of rule applies.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Selects the deferred defect owning an event/condition requirement, moved to EventRequirements. It does not identify a generic counter definition.

    Moved to EventRequirements only. Selects the deferred defect associated with the event/condition requirement. Retained here for review history; backend/database adoption pending.
    Source: Requirements.DeferredDefectMasterId.
    22EventDefinitionId
    Dropped · Moved to EventRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects the reusable event description that owns an event-scope requirement. It has moved to EventRequirements.

    Real-world situation

    A reusable “Component installation” event definition owns a related requirement.

    What this means in practice That is the description of the event kind. An actual installation on VT-ABC is a separate occurrence with its own time and evidence.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Selects the reusable shared event definition owning an Event-scope requirement, moved to EventRequirements. It is distinct from a trigger event and an actual occurrence.

    Moved to EventRequirements; no longer an active TimeRequirements field. Retained here for review history. HTML decision only; backend/database adoption pending.
    Source: Requirements.EventDefinitionId.
    23MaintenanceProgramMasterId
    Dropped · Moved to EventRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects the maintenance programme to which the obligation belongs. It has moved to EventRequirements.

    Real-world situation

    The filter-inspection task belongs to the operator’s approved maintenance programme.

    What this means in practice The source programme and approved version remain traceable. The detailed hours/months limits are managed through linked timing records.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Selects the maintenance programme context, moved to EventRequirements. The programme’s approved version and applicability must remain traceable.

    Moved to EventRequirements; no longer an active TimeRequirements field. Retained here for review history. HTML decision only; backend/database adoption pending.
    Source: Requirements.MaintenanceProgramMasterId.
    24MaintenanceTaskId
    Dropped · Moved to EventRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects the task that must be performed. It has moved to EventRequirements.

    Real-world situation

    For the follow-up rule, select task B, “Perform leak check”.

    What this means in practice This identifies the work being made due. TriggerMaintenanceTaskId can separately select task A, whose completion starts the rule.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Single owning-task lookup after consolidating the former component-task field, moved to EventRequirements. It identifies task B, not a prerequisite task A.

    Moved to EventRequirements; no longer an active TimeRequirements field. Retained here for review history. Preserve the reviewed rename/merge from ComponentMaintenanceTaskId and explicitly reconcile the legacy TaskCard mapping. HTML decision only; backend/database adoption pending.
    Source: Requirements.MaintenanceTaskId.
    25ManualPageId
    Dropped
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language The former selection of a particular manual page, dropped from this timing proposal.

    Real-world situation

    An old record points to the page containing the inspection instruction.

    What this means in practice Preserve that old page reference during review. A page ID is not automatically the same as the full publication’s ID.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former manual-page lookup, dropped from TimeRequirements and retained for reconciliation history. It is more specific than selecting a publication master.

    Dropped from TimeRequirements. Former nullable manual-page lookup retained here for review history. HTML decision only; backend/database adoption pending.
    Source: Requirements.ManualPageId.
    26OperationSpecificationId
    Dropped · Moved to EventRequirements / ResourceRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects the relevant operation specification. It has moved to EventRequirements and is retained on ResourceRequirements.

    Real-world situation

    A resource or event obligation is associated with a particular operation-specification record.

    What this means in practice The business context is linked there. A separate time requirement can govern a relevant review/validity date; this old timing field stays dropped.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Operation-specification lookup moved to EventRequirements and retained on ResourceRequirements. It describes authorized operating context, not a clock/counter value.

    Moved to EventRequirements and retained on ResourceRequirements. No longer an active TimeRequirements field; original nullable operation-specification lookup remains visible here for review history. HTML decision only; backend/database adoption pending.
    Source: Requirements.OperationSpecificationId.
    27ParentAuthorizationId
    Dropped · Moved to ResourceRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects an authorization that owns a resource requirement. It has moved to ResourceRequirements.

    Real-world situation

    An organization’s certifying authorization requires a particular qualification.

    What this means in practice The qualification requirement belongs under that authorization. A linked time rule can separately govern renewal.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Parent authorization lookup moved to ResourceRequirements. It identifies the authorization context for a resource requirement.

    Moved to ResourceRequirements. No longer active on TimeRequirements; the original nullable lookup remains visible here for review history. HTML decision only; backend/database adoption pending.
    Source: Requirements.ParentAuthorizationId.
    28ParentCompetencyTemplateId
    Dropped · Moved to ResourceRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects the qualification/training template that owns a resource requirement. It has moved to ResourceRequirements.

    Real-world situation

    An A320 qualification template contains a practical-assessment requirement.

    What this means in practice The resource requirement is organized under that template. Its parent is not the date from which an inspection interval is counted.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Parent competency-template lookup moved to ResourceRequirements. It identifies a qualification hierarchy rather than a timing baseline.

    Moved to ResourceRequirements. No longer active on TimeRequirements; the original nullable lookup remains visible here for review history. HTML decision only; backend/database adoption pending.
    Source: Requirements.ParentCompetencyTemplateId.
    29ParentRequirementId
    Dropped · Renamed to ParentTimeRequirementId
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language The old name for the link to a parent timing requirement, now called ParentTimeRequirementId.

    Real-world situation

    An old child rule points to the main filter-inspection rule.

    What this means in practice Preserve that relationship under the new name. The old spelling stays dropped; it does not create a second parent link.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former hierarchy property renamed ParentTimeRequirementId. It remains dropped under this spelling; preserve and explicitly remap the legacy parent relationships.

    Renamed to ParentTimeRequirementId in TimeRequirements. Original field name retained for review history; preserve the nullable self-reference and remap legacy parent IDs explicitly. HTML decision only; backend/database adoption pending.
    Source: Requirements.ParentRequirementId.
    30PartId
    Dropped · Moved to ResourceRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects the part needed or concerned in the resource requirement. It has moved to ResourceRequirements.

    Real-world situation

    A resource requirement selects replacement filter part P100.

    What this means in practice This answers which part is required. PartMasterId retained in the timing proposal has a different role: assigning a counter setup to a part number.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Requirement-related part lookup moved to ResourceRequirements. It differs from PartMasterId, retained here specifically for counter-template group assignment.

    Moved to ResourceRequirements. No longer an active TimeRequirements field; the original nullable part lookup remains here for review history. HTML decision only; backend/database adoption pending.
    Source: Requirements.PartId.
    31ProcessOwnerStaffMemberId
    Dropped
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language The former selection of the person responsible for the process, dropped here.

    Real-world situation

    An old interval-review record identifies Maya as process owner.

    What this means in practice This described responsibility, not the timing calculation. Keep the legacy link available for reconciliation rather than assuming it is an inspection deadline input.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former staff lookup identifying the process owner, dropped from TimeRequirements. Ownership metadata does not calculate a maintenance deadline.

    Dropped from TimeRequirements. Former nullable process-owner staff lookup retained here for review history. HTML decision only; backend/database adoption pending.
    Source: Requirements.ProcessOwnerStaffMemberId.
    32RequirementGroupParentId
    Dropped
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language An old link used to place a requirement under a group, dropped here.

    Real-world situation

    Two inspection requirements were placed under the old “Hydraulic checks” group.

    What this means in practice The old grouping must be mapped explicitly. Do not assume it means one task must wait for the other, or that it defines earliest/latest timing logic.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former group-parent lookup, dropped here. Reconcile existing group relationships explicitly with the retained hierarchy and calculation-group design.

    Dropped from TimeRequirements. Former nullable requirement-group parent lookup retained here for review history. ParentTimeRequirementId remains the proposed TimeRequirements hierarchy lookup. Review legacy group mappings explicitly during adoption. HTML decision only; backend/database adoption pending.
    Source: Requirements.RequirementGroupParentId.
    33SafetyScopeId
    Dropped · Moved to EventRequirements
    Guid?Nullable

    Historical example · this field remains dropped

    In plain language Selects the safety context for an obligation. It has moved to EventRequirements.

    Real-world situation

    An event obligation is associated with a defined operational safety scope.

    What this means in practice The safety context is stored with the event requirement. Any related review deadline can be expressed by a separate linked time rule.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Safety-context lookup moved to EventRequirements. It associates an obligation with a safety scope rather than defining a time unit.

    Moved to EventRequirements. No longer an active TimeRequirements field; the original nullable safety-scope lookup remains here for review history. HTML decision only; backend/database adoption pending.
    Source: Requirements.SafetyScopeId.
    34SourceDocument
    Dropped
    stringRequired

    Historical example · this field remains dropped

    In plain language The old typed name/number of the source document, dropped in this proposal.

    Real-world situation

    An old record contains “Maintenance Programme MP-01”.

    What this means in practice Match it to the correct controlled publication record and preserve unmatched information for review. Do not simply erase the text.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Legacy source-document text, dropped and retained for reconciliation. It must not be discarded before matching controlled publication records and preserving unmatched references.

    Dropped from TimeRequirements. Original source document text remains visible here for review history. Preserve legacy values for reconciliation during later adoption. HTML decision only; backend/database adoption pending.
    Source: Requirements.SourceDocument.
    35SourceEdition
    Dropped
    stringRequired

    Historical example · this field remains dropped

    In plain language The old typed document edition/revision, dropped in this proposal.

    Real-world situation

    An old inspection requirement says “Revision 12”.

    What this means in practice Keep that edition associated with historical work when mapping to controlled publications. Do not silently replace it with today’s latest revision.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Legacy source-edition text, dropped and retained for reconciliation. Preserve the edition used historically when establishing the controlled publication mapping.

    Dropped from TimeRequirements. Original source edition text remains visible here for review history. Preserve legacy values for reconciliation during later adoption. HTML decision only; backend/database adoption pending.
    Source: Requirements.SourceEdition.
    36SourceKind
    Dropped · Merged into SourceType
    SafetyRequirementSourceKind { Unclassified, IcaoStandard, IcaoRecommendedPractice, Regulation, Guidance, InternalPolicy }
    EF: SafetyRequirementSourceKind
    Required

    Historical example · this field remains dropped

    In plain language The old source-category field, now merged into SourceType.

    Real-world situation

    One old field says Regulation and another says Regulatory.

    What this means in practice Review and map the combined source meaning explicitly. This old field stays dropped rather than remaining a second independently editable classification.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former source-classification enum merged into SourceType. Differing old classifications require explicit review rather than one silently overwriting the other.

    Merged into the reviewed SourceType field using the proposed RequirementSourceType enum. Retain this original field name and enum for review history; explicitly reconcile differing legacy SourceKind/SourceType values before adoption. HTML decision only; backend/database adoption pending.
    Source: Requirements.SourceKind.
    37RequirementId
    Dropped · Renamed / Merged
    Source definition retained in original catalogRole-specific

    Historical example · this field remains dropped

    In plain language The old link identifying which main requirement owns a limit or saved calculation, now merged into ParentTimeRequirementId.

    Real-world situation

    The 500-hour limit previously selected the main filter-inspection requirement through RequirementId.

    What this means in practice It still belongs to that requirement after the rename. The old spelling stays dropped; ownership is not removed.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former owner lookup on limits/snapshots, merged into ParentTimeRequirementId. Required role-specific ownership remains even though this spelling is dropped.

    Original field spelling merged or renamed to ParentTimeRequirementId in TimeRequirements. Sources: TimeRequirementLimit.RequirementId, MaintenanceEventDueLimit.RequirementId. Preserve source semantics, requiredness and explicit role-aware identity/enum mappings during adoption. Original source catalogs remain linked below. HTML proposal only; backend/database adoption pending.
    38NextDueCalculationStrategy
    Dropped · Renamed / Merged
    Source definition retained in original catalogRole-specific

    Historical example · this field remains dropped

    In plain language The old spelling for the choice of where the next interval begins, now TimeNextDueCalculationStrategy.

    Real-world situation

    An inspection done at 1,480 hours has a 500-hour repeat interval and uses completion as its starting point.

    What this means in practice The next due value remains 1,980 after the field mapping. Renaming must not change the approved strategy.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Former strategy spelling merged into TimeNextDueCalculationStrategy. Preserve default/override and snapshot semantics when adopting the shared property.

    Original field spelling merged or renamed to TimeNextDueCalculationStrategy in TimeRequirements. Sources: TimeRequirementLimit.NextDueCalculationStrategy, MaintenanceEventDueLimit.NextDueCalculationStrategy. Preserve source semantics, requiredness and explicit role-aware identity/enum mappings during adoption. Original source catalogs remain linked below. HTML proposal only; backend/database adoption pending.
    39BaselineType
    Dropped · Renamed / Merged
    Source definition retained in original catalogRole-specific

    Historical example · this field remains dropped

    In plain language The old spelling for the kind of starting point, now TimeBaselineType.

    Real-world situation

    An old calendar rule starts from the component’s installation date.

    What this means in practice After the rename it still starts from installation, not manufacture or today. The actual installation date must remain available.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Former baseline spelling merged into TimeBaselineType. Keep the approved baseline and captured values; renaming must not change the calculation origin.

    Original field spelling merged or renamed to TimeBaselineType in TimeRequirements. Sources: TimeRequirementLimit.BaselineType, MaintenanceEventDueLimit.BaselineType. Preserve source semantics, requiredness and explicit role-aware identity/enum mappings during adoption. Original source catalogs remain linked below. HTML proposal only; backend/database adoption pending.
    40GroupLogic
    Dropped · Renamed / Merged
    Source definition retained in original catalogRole-specific

    Historical example · this field remains dropped

    In plain language The old within-group earliest/latest choice, now TimeLogic.

    Real-world situation

    The hours and months limits in a group use whichever comes first.

    What this means in practice That choice survives the mapping. TimeGroupLogic remains the separate choice between different groups.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Former within-group logic merged into TimeLogic. It does not replace TimeGroupLogic, which combines different groups.

    Original field spelling merged or renamed to TimeLogic in TimeRequirements. Sources: TimeRequirementLimit.GroupLogic, MaintenanceEventDueLimit.GroupLogic. Preserve source semantics, requiredness and explicit role-aware identity/enum mappings during adoption. Original source catalogs remain linked below. HTML proposal only; backend/database adoption pending.
    41Sequence
    Dropped · Renamed / Merged
    Source definition retained in original catalogRole-specific

    Historical example · this field remains dropped

    In plain language The old ordering number, now SequenceNo.

    Real-world situation

    A limit was shown second using Sequence = 2.

    What this means in practice It stays second under SequenceNo = 2. The number does not become an interval amount or a group identity.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former ordering field merged into SequenceNo. Preserve source ordering and role-specific uniqueness rather than using it as a quantity.

    Original field spelling merged or renamed to SequenceNo in TimeRequirements. Sources: TimeRequirementLimit.Sequence, CounterTemplate.Sequence. Preserve source semantics, requiredness and explicit role-aware identity/enum mappings during adoption. Original source catalogs remain linked below. HTML proposal only; backend/database adoption pending.
    42CounterDefinition.Dimension
    Dropped · Renamed / Merged
    Source definition retained in original catalogRole-specific

    Historical example · this field remains dropped

    In plain language The old name for what kind of quantity a counter measures, now CounterValueDimension.

    Real-world situation

    The flying-hours definition used Dimension = Hours.

    What this means in practice Map it to CounterValueDimension = Hours. A maintenance deadline can still separately use Dimension = FH; these fields describe different levels of meaning.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Former counter-category property renamed CounterValueDimension to avoid colliding with the limit Dimension field.

    Original field spelling merged or renamed to CounterValueDimension in TimeRequirements. Sources: CounterDefinition.Dimension. Preserve source semantics, requiredness and explicit role-aware identity/enum mappings during adoption. Original source catalogs remain linked below. HTML proposal only; backend/database adoption pending.
    43Source
    Dropped · Renamed / Merged
    Source definition retained in original catalogRole-specific

    Historical example · this field remains dropped

    In plain language The old name for how a reading entered the system, now CounterReadingSource.

    Real-world situation

    A historical reading was imported, so its old Source is DataImport.

    What this means in practice It remains an imported reading after mapping. The source of the inspection rule, such as a publication, is recorded separately in SourceType.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Detailed design note: Former CounterReading.Source spelling renamed CounterReadingSource. Its entry-origin values remain separate from requirement-source classification.

    Original field spelling merged or renamed to CounterReadingSource in TimeRequirements. Sources: CounterReading.Source. Preserve source semantics, requiredness and explicit role-aware identity/enum mappings during adoption. Original source catalogs remain linked below. HTML proposal only; backend/database adoption pending.
    44GroupNumber
    Dropped
    int?Nullable
    Formerly required for: LimitDefinition, DueLimitSnapshot

    Historical example · this field remains dropped

    In plain language An old number identifying a group of timing limits. It remains dropped, and the replacement grouping method still needs review.

    Real-world situation

    Group 1 contains one set of hours/months limits; group 2 contains a different approved set.

    What this means in practice They must not be accidentally combined when adopting the shared table. AMOS uses group numbers to match its editor and diagrams, so the lost grouping identity needs an explicit solution.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Legacy number identifying a dimension group. AMOS displays group numbers to match editor groups with visualized thresholds/intervals. It remains dropped per review; the replacement group mapping is still unresolved.

    Dropped from the TimeRequirements proposal. Original type, row-role applicability and source definitions remain below for review history. Backend/database adoption pending. Legacy limit-group mappings must be explicitly reconciled during later adoption.
    Records group number for this time requirement limit.
    Used by: LimitDefinition, DueLimitSnapshot.
    Sources: TimeRequirementLimit.GroupNumber (LimitDefinition; required); MaintenanceEventDueLimit.GroupNumber (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    45CounterName
    Dropped
    string?Nullable
    Formerly required for: CounterDefinition

    Historical example · this field remains dropped

    In plain language The former readable name of a counter. It remains dropped per the review decision.

    Real-world situation

    Code H had the name “Flight hours”.

    What this means in practice The name helped people understand the code. AMOS requires a counter name; dropping this field in Coflyr still leaves a naming/display decision to resolve later.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Legacy readable name of a counter definition. AMOS explicitly requires a counter name alongside code and display format. This field remains dropped per your decision; an equivalent naming/display policy needs later review.

    Dropped from the TimeRequirements proposal. Original type, row-role applicability and source definitions remain below for review history. Backend/database adoption pending.
    Records counter name for this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.CounterName (CounterDefinition; required). HTML consolidation; backend/database adoption pending.
    46GroupName
    Dropped
    string?Nullable
    Formerly required for: CounterTemplateGroup

    Historical example · this field remains dropped

    In plain language The former readable name of a counter-template bundle. It remains dropped.

    Real-world situation

    The old bundle “Standard A320 counters” contained flying-hours and cycles setups.

    What this means in practice The bundle’s member counters and assignments must survive even if this name field is dropped. Review how the bundle will be identified for users.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Legacy name of a counter-template group. AMOS groups collect counter templates assigned to aircraft types or parts. This field stays dropped; preserve legacy labels for later naming review.

    Dropped from the TimeRequirements proposal. Original type, row-role applicability and source definitions remain below for review history. Backend/database adoption pending.
    Records group name for this counter template group.
    Used by: CounterTemplateGroup.
    Sources: CounterTemplateGroup.GroupName (CounterTemplateGroup; required). HTML consolidation; backend/database adoption pending.
    47CounterDefinitionId
    Dropped
    Guid?Nullable
    Formerly required for: CounterTemplate, AssetCounter

    Historical example · this field remains dropped

    In plain language Selects what kind of usage is being counted, such as flying hours or landings.

    Real-world situation

    For a 500-flying-hour inspection, Maya selects the “Flight hours” counter definition.

    What this means in practice Coflyr knows the rule uses flying hours. It still needs the particular aircraft’s counter to know how many hours that aircraft has flown.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Selects a CounterDefinition-role row describing what is counted. An asset counter supplies the actual value for a particular aircraft or component.

    Dropped from the TimeRequirements proposal. Original type, row-role applicability and source definitions remain below for review history. Backend/database adoption pending.
    Self-reference to a CounterDefinition-role TimeRequirements row. Required on AssetCounter and CounterTemplate; optional on limit rows except where a custom counter dimension requires it. Preserve Restrict deletion and validate the selected dimension/unit and role.
    Used by: LimitDefinition, DueLimitSnapshot, CounterTemplate, AssetCounter.
    Sources: TimeRequirementLimit.CounterDefinitionId (LimitDefinition; nullable); MaintenanceEventDueLimit.CounterDefinitionId (DueLimitSnapshot; nullable); CounterTemplate.CounterDefinitionId (CounterTemplate; required); AssetCounter.CounterDefinitionId (AssetCounter; required). HTML consolidation; backend/database adoption pending.
    48RangeMeasureUnitId
    Dropped
    Guid?Nullable
    Former applicability: Optional

    Historical example · this field remains dropped

    In plain language Selects the unit used to decide which usage range an asset falls into.

    Real-world situation

    A source rule uses one interval below 10,000 cycles and another above it. Maya selects “cycles” as the range unit.

    What this means in practice The range is checked in cycles, not hours. The exact treatment of the 10,000 boundary must be defined before implementation.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Selects the unit associated with a limit’s applicability range. It clarifies the numbers in LowerRangeValue and UpperRangeValue; the exact range-selection rule still needs adoption review.

    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.
    Selects the related range measure unit record.
    Used by: LimitDefinition.
    Sources: TimeRequirementLimit.RangeMeasureUnitId (LimitDefinition; nullable). HTML consolidation; backend/database adoption pending.
    49AssetCounterId
    Dropped
    Guid?Nullable
    Formerly required for: CounterReading

    Historical example · this field remains dropped

    In plain language Selects the usage record for one particular aircraft or component.

    Real-world situation

    Maya selects “VT-ABC — Flight hours”, currently showing 1,200 hours.

    What this means in practice The inspection uses VT-ABC’s hours. It must not use VT-DEF’s hours even though both counters measure the same thing.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Selects the AssetCounter-role row for a specific aircraft or component. Readings belong to that counter; applied limits can record which counter supplied their observation.

    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.
    Self-reference to an AssetCounter-role TimeRequirements row. Required on CounterReading and optional on applied limit snapshots except where custom-counter rules require it. Preserve the target asset and capture the reading used by the maintenance calculation.
    Used by: DueLimitSnapshot, CounterReading.
    Sources: MaintenanceEventDueLimit.AssetCounterId (DueLimitSnapshot; nullable); CounterReading.AssetCounterId (CounterReading; required). HTML consolidation; backend/database adoption pending.
    50MaintenanceEventMasterId
    Dropped · Moved to EventRequirements
    Guid?Nullable
    Formerly required for: DueLimitSnapshot

    Historical example · this field remains dropped

    In plain language Selects the particular occurrence of work being planned, rather than the repeating rule.

    Real-world situation

    Maya selects “VT-ABC filter inspection — June 2026 occurrence”.

    What this means in practice The calculated deadline is saved against this occurrence. The next inspection will be a different occurrence with its own saved calculation.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Links a due-limit snapshot to the particular maintenance occurrence being forecast or accomplished. MaintenanceEventMaster stays outside this proposed table merge.

    Dropped from TimeRequirements and moved to EventRequirements. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.
    Required external lookup from DueLimitSnapshot to the existing MaintenanceEventMaster occurrence. That table is not part of this merge. Preserve the applied calculation’s asset and occurrence ownership.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.MaintenanceEventMasterId (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    51AircraftTypeId
    Dropped
    Guid?Nullable
    Former applicability: Optional

    Historical example · this field remains dropped

    In plain language Selects the aircraft type that should receive a particular set of usage counters.

    Real-world situation

    Maya assigns the standard flying-hours and cycles counters to the A320 aircraft type.

    What this means in practice This describes the counter setup for the type. VT-ABC and VT-DEF still keep separate actual readings.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Selects the aircraft type receiving a counter-template group assignment. This assigns the counting setup to a type, while AircraftTailId identifies an individual aircraft.

    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.
    Selects the related aircraft type record.
    Used by: CounterTemplateGroupAssignment.
    Sources: CounterTemplateGroupAssignment.AircraftTypeId (CounterTemplateGroupAssignment; nullable). HTML consolidation; backend/database adoption pending.
    52CounterTemplateGroupId
    Dropped
    Guid?Nullable
    Formerly required for: CounterTemplateGroupAssignment, CounterTemplate

    Historical example · this field remains dropped

    In plain language Selects a reusable bundle of counter setups.

    Real-world situation

    Maya selects “Standard aircraft counters”, containing flying hours, cycles and calendar age.

    What this means in practice The bundle can be assigned together instead of choosing the same counter setups repeatedly. It is different from a group of inspection deadlines.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Detailed design note: Selects the CounterTemplateGroup-role row containing a set of counter templates. Group assignments and individual templates refer to this same group.

    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.
    Required self-reference on CounterTemplate and CounterTemplateGroupAssignment rows to a CounterTemplateGroup-role TimeRequirements row. Preserve legacy group/template/assignment behavior and scoped uniqueness.
    Used by: CounterTemplateGroupAssignment, CounterTemplate.
    Sources: CounterTemplateGroupAssignment.CounterTemplateGroupId (CounterTemplateGroupAssignment; required); CounterTemplate.CounterTemplateGroupId (CounterTemplate; required). HTML consolidation; backend/database adoption pending.
    53PartMasterId
    Dropped · Moved to EventRequirements
    Guid?Nullable
    Former applicability: Optional

    In plain language Selects a part number that should receive a particular counter setup.

    Real-world situation

    Pump part P100 needs flying-hours and cycles counters. Maya selects P100 for the counter-group assignment.

    What this means in practice All applicable serialized P100 pumps can receive that setup. Each individual pump still has its own usage history.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements and moved to EventRequirements. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    Detailed design note: Selects a part number to which a counter-template group is assigned. This is a part-definition assignment, distinct from a serialised component’s RotableMasterId.

    Selects the related part master record.
    Used by: CounterTemplateGroupAssignment.
    Sources: CounterTemplateGroupAssignment.PartMasterId (CounterTemplateGroupAssignment; nullable). HTML consolidation; backend/database adoption pending.
    54ReferenceType
    Dropped
    CounterReferenceType? { AircraftType, Part }Nullable
    Formerly required for: CounterTemplateGroupAssignment

    In plain language Dropped from the TimeRequirements proposal; retained for review history. Original meaning: Says whether a counter-group assignment is for an aircraft type or for a part number.

    Real-world situation

    Maya chooses Part, then selects pump part P100.

    What this means in practice The assignment is treated as a part assignment. Choosing AircraftType instead would require selecting an aircraft type.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    Detailed design note: States whether a counter-template group assignment targets an aircraft type or a part. Validate the corresponding lookup and do not silently use both.

    Records reference type for this counter template group assignment.
    Used by: CounterTemplateGroupAssignment.
    Sources: CounterTemplateGroupAssignment.ReferenceType (CounterTemplateGroupAssignment; required). HTML consolidation; backend/database adoption pending.
    55AircraftTailId
    Dropped
    Guid?Nullable
    Former applicability: Optional

    In plain language Dropped from the TimeRequirements proposal; retained for review history. Original meaning: Selects the individual aircraft that owns this usage counter.

    Real-world situation

    Maya selects aircraft VT-ABC.

    What this means in practice The 1,200-hour total belongs to VT-ABC. It is not a fleet-wide total or the total for every aircraft of the same type.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    Detailed design note: Identifies the individual aircraft whose AssetCounter is maintained. It is not the aircraft type or the counter definition.

    Selects the related aircraft tail record.
    Used by: AssetCounter.
    Sources: AssetCounter.AircraftTailId (AssetCounter; nullable). HTML consolidation; backend/database adoption pending.
    56CounterTemplateId
    Dropped
    Guid?Nullable
    Former applicability: Optional

    In plain language Dropped from the TimeRequirements proposal; retained for review history. Original meaning: Selects the reusable setup used to create this aircraft’s or component’s counter.

    Real-world situation

    VT-ABC’s flying-hours counter selects the standard “Aircraft flight hours” setup.

    What this means in practice The setup explains how the counter is intended to work. The aircraft’s actual 1,200 hours are stored on its own counter, not in the reusable setup.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    Detailed design note: Selects the reusable CounterTemplate-role setup from which an asset counter was created. It carries counting behaviour and configuration rather than the latest reading.

    Optional self-reference from AssetCounter to a CounterTemplate-role TimeRequirements row. Preserve the template relationship and validate its counter definition and group.
    Used by: AssetCounter.
    Sources: AssetCounter.CounterTemplateId (AssetCounter; nullable). HTML consolidation; backend/database adoption pending.
    57MasterAssetCounterId
    Dropped
    Guid?Nullable
    Former applicability: Optional

    In plain language Dropped from the TimeRequirements proposal; retained for review history. Original meaning: Selects the aircraft counter that an installed component follows while it is fitted.

    Real-world situation

    A pump is fitted when VT-ABC has 10,000 flying hours. The pump’s counter selects VT-ABC’s hours counter as its master.

    What this means in practice If the aircraft flies another 300 hours before removal, those 300 hours can be attributed to the pump’s installation period under the adopted counting rules.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    Detailed design note: Selects the master asset counter whose usage an installed child counter follows. Installation/removal readings establish the usage attributable to that installation; prevent self-links and cycles.

    Optional self-reference from an AssetCounter to another AssetCounter row used as its master counter. Preserve installation/removal master readings and prevent self-links and master-counter cycles.
    Used by: AssetCounter.
    Sources: AssetCounter.MasterAssetCounterId (AssetCounter; nullable). HTML consolidation; backend/database adoption pending.
    58RotableMasterId
    Dropped · Moved to ResourceRequirements
    Guid?Nullable
    Former applicability: Optional

    In plain language Moved to ResourceRequirements and dropped from the TimeRequirements proposal. Retained for review history. Original meaning: 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

    Technical details and original review decision
    Dropped from TimeRequirements and moved to ResourceRequirements. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    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.
    59FlightLogId
    Dropped
    Guid?Nullable
    Former applicability: Optional

    In plain language Dropped from the TimeRequirements proposal; retained for review history. Original meaning: Selects the flight record supporting a usage reading.

    Real-world situation

    Flight log FL-204 records a 2.5-hour flight. The new hours reading links to FL-204.

    What this means in practice A reviewer can trace the increase from 1,197.5 to 1,200 hours back to the flight that produced it.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    Detailed design note: Selects the flight-log record supporting a counter reading. It provides traceability to the flight data that produced the usage update.

    Selects the related flight log record.
    Used by: CounterReading.
    Sources: CounterReading.FlightLogId (CounterReading; nullable). HTML consolidation; backend/database adoption pending.
    60LifecycleStatus
    Dropped
    PartRequirementLifecycleStatus? { New, Active, Inactive, Superseded }Nullable
    Formerly required for: RequirementDefinition

    In plain language Dropped from the TimeRequirements proposal; retained for review history. Original meaning: Says whether the rule itself is being drafted, is in use or has been replaced.

    Real-world situation

    Maya prepares a revised interval as New, then it is activated through the approved process.

    What this means in practice The active rule can be used for new work. Earlier work keeps its original rule version; completing an inspection is a different action.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    Detailed design note: State of the requirement definition, such as New, Active, Inactive or Superseded. AMOS has controlled activation of new time requirements and archives previous revisions; exact enum mapping remains Coflyr-specific.

    Tracks the lifecycle status of this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.LifecycleStatus (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    61PlanningStatus
    Dropped
    PlanningStatusType? { None, Planned, Completed, Required, Expired, Waived, Other }Nullable
    Former applicability: Optional

    In plain language Dropped from the TimeRequirements proposal; retained for review history. Original meaning: Says where work stands in planning, rather than whether its underlying rule is active.

    Real-world situation

    The rule is Active, and the inspection is Planned for a June maintenance visit.

    What this means in practice Planners can see progress. The method for deriving this summary from individual work occurrences still needs definition.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    Detailed design note: Planning/compliance summary on a requirement row. It is distinct from definition lifecycle and needs an explicit derivation rule for individual occurrences.

    Tracks the planning status of this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.PlanningStatus (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    62Active
    Dropped
    bool?Nullable
    Formerly required for: CounterDefinition, CounterTemplateGroup, CounterTemplateGroupAssignment, AssetCounter

    In plain language Dropped from the TimeRequirements proposal; retained for review history. Original meaning: Says a counter or counter setup is enabled for its role.

    Real-world situation

    An aircraft leaves the fleet, so its usage counter is deactivated.

    What this means in practice Its historical readings remain. AMOS deactivation stops new automatic readings; this is different from closing a maintenance task.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    Detailed design note: Enables a counter definition, template-group setup, assignment or asset counter according to its row role. AMOS deactivation stops future automatic readouts without erasing history.

    Indicates whether active applies to this counter definition.
    Used by: CounterDefinition, CounterTemplateGroup, CounterTemplateGroupAssignment, AssetCounter.
    Sources: CounterDefinition.Active (CounterDefinition; required); CounterTemplateGroup.Active (CounterTemplateGroup; required); CounterTemplateGroupAssignment.Active (CounterTemplateGroupAssignment; required); AssetCounter.Active (AssetCounter; required). HTML consolidation; backend/database adoption pending.
    63IsIndividualized
    Dropped
    bool?Nullable
    Formerly required for: CounterDefinition, CounterTemplate

    In plain language Dropped from the TimeRequirements proposal; retained for review history. Original meaning: Says the standard counter setup has a special configuration for an individual case.

    Real-world situation

    One aircraft needs an approved different APU-hours formula.

    What this means in practice That aircraft can keep its special rule while the other aircraft retain the standard setup. The exact per-row implementation still needs review.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements proposal. Original type, applicability, example and source definitions remain for review history. HTML review decision only; backend/database unchanged.

    Detailed design note: Records that standard counting configuration has been individually adapted. AMOS supports individualized counter formulas; the exact scope of this Coflyr flag varies by row role.

    Indicates whether individualized applies to this counter definition.
    Used by: CounterDefinition, CounterTemplate.
    Sources: CounterDefinition.IsIndividualized (CounterDefinition; required); CounterTemplate.IsIndividualized (CounterTemplate; required). HTML consolidation; backend/database adoption pending.
    64IsReadable
    Dropped
    bool?Nullable
    Formerly required for: CounterTemplate

    Drop remark: Create a separate table for maintenance performance. HTML review only; backend/database unchanged.

    In plain language Dropped from TimeRequirements; original explanation retained for review history: Says a technician can read the value from a physical meter.

    Real-world situation

    Ravi looks at a component’s meter and sees 8,420.5 hours.

    What this means in practice He can record that physical reading. AMOS readable counters do not calculate readings from formulas; Coflyr’s input-mode rules must be reconciled with that.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Current review decision: Dropped from TimeRequirements. Create a separate table for maintenance performance. Original type, applicability, examples and sources retained below. Backend/database unchanged.
    Previous review decision (superseded): Reviewed; future review required to reconcile physical readouts, formula calculation and Coflyr InputMode.

    Detailed design note: Identifies a counter that can be physically read. AMOS readable counters use actual readings rather than formula calculation; reconcile this rule with Coflyr InputMode during adoption.

    Indicates whether readable applies to this counter template.
    Used by: CounterTemplate.
    Sources: CounterTemplate.IsReadable (CounterTemplate; required). HTML consolidation; backend/database adoption pending.
    65ValueKnown
    Dropped
    bool?Nullable
    Formerly required for: AssetCounter

    Drop remark: Create a separate table for maintenance performance. HTML review only; backend/database unchanged.

    In plain language Dropped from TimeRequirements; original explanation retained for review history: Says whether the component’s usage total is actually known.

    Real-world situation

    A received pump has no reliable since-new hours record.

    What this means in practice Mark the total unknown instead of pretending it is zero. In AMOS this marker does not stop every future reading or calculation.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Current review decision: Dropped from TimeRequirements. Create a separate table for maintenance performance. Original type, applicability, examples and sources retained below. Backend/database unchanged.

    Detailed design note: Records confidence that the counter value is known. AMOS permits an unknown marker without stopping all calculations or readings; it is not equivalent to zero usage.

    Indicates whether value known applies to this asset counter.
    Used by: AssetCounter.
    Sources: AssetCounter.ValueKnown (AssetCounter; required). HTML consolidation; backend/database adoption pending.
    66TimeGroupLogic
    Dropped · Merged into TimeLogic
    CalculationLogic? { WhicheverComesFirst, WhicheverComesLater, AllLimitsMustBeMet, AnyLimitCanTrigger, PrimaryCounterOnly, CalendarOnly, ManualPlanning }Nullable
    Former applicability: Optional

    Review decision: Merged into TimeLogic and dropped as a separate field. Original explanation, examples and sources retained below as history.

    In plain language Says how to choose between separate groups of timing rules.

    Real-world situation

    Group A produces a June deadline and group B produces a September deadline. The source says use the earlier group.

    What this means in practice June is selected. This differs from choosing between hours and months inside a single group; the group links must remain clear after GroupNumber is dropped.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Current decision: Dropped · Merged into TimeLogic. The separate-field design below is superseded; preserve calculation scope, grouping and legacy values during later adoption. HTML review only; backend/database unchanged.

    Detailed design note: Combines the results of separate limit groups. This differs from TimeLogic, which combines dimensions within one group. Group identities must survive adoption even though GroupNumber is dropped.

    Combines calendar/counter limits belonging to this TimeRequirements rule. Preserve the source calculation choices. Event trigger/enforcement logic belongs to EventRequirements; parent/group hierarchy does not itself define a dependency.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.TimeGroupLogic (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    67AircraftLocationCode
    Dropped · Moved to EventRequirements and ResourceRequirements
    string?Nullable
    Former applicability: Optional

    Review decision: Moved to EventRequirements and ResourceRequirements; dropped from TimeRequirements. Original explanation retained for review history.

    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
    Dropped from TimeRequirements and retained independently in EventRequirements and ResourceRequirements. Original type, example and source definition preserved below. 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: TimeRequirements.AircraftLocationCode (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    68AircraftModelCode
    Dropped
    string?Nullable
    Formerly required for: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Text narrowing the requirement to an aircraft model.

    Real-world situation

    The source says the requirement applies to model A320-214.

    What this means in practice The intended applicability is narrower than the whole aircraft family. Adoption must reconcile this text with the actual aircraft/model records.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Legacy model code used as applicability context. Reconcile text with the structured effectivity model instead of assuming that similar model labels are equivalent.

    Records aircraft model code for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.AircraftModelCode (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    69AircraftSubTypeCode
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language A more specific aircraft subgroup code used in old applicability data.

    Real-world situation

    A fleet uses subtype code SUB-A for aircraft with a particular approved configuration.

    What this means in practice The code helps describe which subgroup is intended. Its exact meaning must come from the fleet’s defined codes, not from guessing the abbreviation.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Legacy subtype classification refining the aircraft applicability context. The accepted code vocabulary and mapping require review.

    Records aircraft sub type code for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.AircraftSubTypeCode (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    70AircraftTypeCode
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Text identifying the aircraft type relevant to the requirement.

    Real-world situation

    Maya enters the source’s aircraft-type code, A320.

    What this means in practice This describes the requirement’s applicability. It is different from AircraftTypeId on a counter-group assignment, which selects an actual saved aircraft-type record.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Legacy aircraft-type text used in requirement applicability. This is distinct from AircraftTypeId, which is a structured counter-group assignment lookup.

    Records aircraft type code for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.AircraftTypeCode (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    71Applicability
    Dropped
    SafetyApplicability? { Undetermined, Applicable, NotApplicable }Nullable
    Formerly required for: RequirementDefinition

    Drop remark: Applicability will be managed through Effectivity (EffectivityId). The separate Applicability field is dropped from TimeRequirements. Original explanation, example and source retained for history.

    In plain language Says whether this requirement applies to the aircraft/component being considered, does not apply, or has not yet been decided.

    Real-world situation

    The instruction affects old connectors. VT-ABC has the new connector, so a reviewer records NotApplicable with evidence.

    What this means in practice The applicability decision is visible. It must be established before treating an aircraft as exempt; a due calculation does not decide it.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Applicability will be managed through Effectivity via EffectivityId. Preserve original applicability decisions and evidence for reconciliation during later adoption. Backend/database unchanged.

    Detailed design note: Records whether the requirement has been assessed as applicable, not applicable or still undetermined for its context. A due calculation does not itself settle applicability.

    Records applicability for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.Applicability (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    72ApplicabilityDecision
    Dropped
    string?Nullable
    Formerly required for: RequirementDefinition

    Drop remark: Managed through Effectivity via EffectivityId. The separate ApplicabilityDecision field is dropped from TimeRequirements. Original explanation, example and sources retained for review history.

    In plain language Explains the reason behind the applies/does-not-apply decision.

    Real-world situation

    The reviewer writes “Not applicable: delivery configuration confirms the new connector is already installed”.

    What this means in practice Another reviewer can understand and check the decision instead of seeing only a Yes/No status.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Applicability decisions will be managed through Effectivity via EffectivityId. Preserve existing decision explanations and supporting evidence for reconciliation during later adoption. Backend/database unchanged.

    Detailed design note: Narrative explanation supporting the applicability assessment. It should identify the evidence rather than merely repeat the status.

    Records applicability decision for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ApplicabilityDecision (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    73ApplicabilityReviewedAt
    Dropped
    DateTimeOffset?Nullable
    Former applicability: Optional

    Drop remark: Managed through Effectivity via EffectivityId. The separate ApplicabilityReviewedAt field is dropped from TimeRequirements. Original explanation, example and sources retained for review history.

    In plain language When someone checked whether the requirement applies.

    Real-world situation

    The engineer checks the configuration on 15 April at 10:00.

    What this means in practice The review timestamp is recorded. It does not mean the inspection is due on 15 April or that the rule starts that day.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Applicability review timestamps will be managed through Effectivity via EffectivityId. Preserve existing review timestamps and associated audit evidence for reconciliation during later adoption. Backend/database unchanged.

    Detailed design note: Timestamp of the applicability review, distinct from the date on which the requirement becomes applicable.

    Records the applicability reviewed at for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ApplicabilityReviewedAt (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    74ApplicableFrom
    Dropped
    DateTimeOffset?Nullable
    Former applicability: Optional

    Drop remark: Managed through Effectivity via EffectivityId. The separate ApplicableFrom field is dropped from TimeRequirements. Original explanation, example and sources retained for review history.

    In plain language When this rule starts applying in its intended context.

    Real-world situation

    An approved seasonal inspection rule applies from 1 November.

    What this means in practice The rule is relevant from that date. Its interval and starting point still determine the actual inspection deadlines.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. The applicability window will be managed through Effectivity via EffectivityId. Preserve existing dates and associated context for reconciliation during later adoption. Backend/database unchanged.

    Detailed design note: Start of the requirement’s applicability window. It determines when a rule is relevant, not necessarily when an occurrence must be completed.

    Records applicable from for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ApplicableFrom (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    75ApplicableUntil
    Dropped
    DateTimeOffset?Nullable
    Former applicability: Optional

    Drop remark: Managed through Effectivity via EffectivityId. The separate ApplicableUntil field is dropped from TimeRequirements. Original explanation, example and sources retained for review history.

    In plain language When the rule stops applying in its intended context.

    Real-world situation

    The seasonal rule applies until 31 March.

    What this means in practice The applicable period ends then, but past inspection records must remain. Outstanding obligations need explicit treatment rather than being silently erased.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. The applicability window will be managed through Effectivity via EffectivityId. Preserve existing dates and associated context for reconciliation during later adoption. Backend/database unchanged.

    Detailed design note: End of the requirement’s applicability window. Expiry of applicability must not silently erase outstanding historical obligations.

    Records applicable until for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ApplicableUntil (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    76SourceLimitId
    Dropped
    Guid?Nullable
    Formerly required for: DueLimitSnapshot

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Selects the original limit from which this saved calculation was made.

    Real-world situation

    The June inspection’s calculation selects the approved “500 flight hours” limit.

    What this means in practice Later, if the programme changes to 450 hours, reviewers can still see that the June calculation was made using the earlier 500-hour rule.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Selects the LimitDefinition-role row from which an occurrence snapshot was calculated. Keep the approved revision and captured inputs stable after later definition changes.

    Required self-reference on DueLimitSnapshot to its source LimitDefinition row in TimeRequirements. Preserve the approved source identity/revision and captured limit inputs. Changes to the live definition must not rewrite historical snapshots.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.SourceLimitId (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    77ReadoutReference
    Dropped
    Review later
    string?Nullable
    Former applicability: Optional

    Drop remark: Review later. Dropped from TimeRequirements; original explanation, example and sources retained for future review.

    In plain language A reference number explaining the occasion on which a reading was taken.

    Real-world situation

    Ravi reads a pump meter during workorder WO-1042 and enters WO-1042 as the reference.

    What this means in practice Someone can find the supporting workorder later. Typing the workorder number does not itself add hours to the counter.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal; review later. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Human-readable reference associated with a reading. AMOS describes readout references as contextual information, not an input that changes the counter calculation.

    Records readout reference for this counter reading.
    Used by: CounterReading.
    Sources: CounterReading.ReadoutReference (CounterReading; nullable). HTML consolidation; backend/database adoption pending.
    78ReadoutReferenceType
    Dropped
    Review later
    string?Nullable
    Former applicability: Optional

    Drop remark: Review later. Dropped from TimeRequirements; original explanation, example and sources retained for future review.

    In plain language Says what kind of record the reading’s reference points to.

    Real-world situation

    Ravi chooses Workorder and enters reference WO-1042.

    What this means in practice Coflyr knows WO-1042 is a workorder reference. This differs from saying the reading was entered manually.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal; review later. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Classifies the reading’s reference, such as a flight log or workorder. This differs from CounterReadingSource, which says how the reading entered the system.

    Records readout reference type for this counter reading.
    Used by: CounterReading.
    Sources: CounterReading.ReadoutReferenceType (CounterReading; nullable). HTML consolidation; backend/database adoption pending.
    79IsRequirementGroupHeader
    Dropped
    bool?Nullable
    Formerly required for: RequirementDefinition

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Says this row is a heading used to organize requirements.

    Real-world situation

    Maya creates a heading called “Landing gear checks”.

    What this means in practice Individual checks appear beneath it. The heading itself should not accidentally become a maintenance task with a deadline.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Marks a requirement row used to organize related requirements. A heading is separate from a due-limit grouping rule and must not accidentally create executable work.

    Indicates whether requirement group header applies to this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.IsRequirementGroupHeader (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    80IsCounterGroup
    Dropped
    bool?Nullable
    Formerly required for: CounterDefinition

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language A legacy counter flag whose exact intended effect is still unclear.

    Real-world situation

    A source counter record has IsCounterGroup = Yes.

    What this means in practice This is not enough to know which counters it groups. Keep it under review; the explicit counter-template group records identify actual bundle membership.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Legacy counter-definition flag whose exact business effect is not established by the reviewed AMOS passages. Keep its meaning under review; do not confuse it with an explicit CounterTemplateGroup row.

    Indicates whether counter group applies to this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.IsCounterGroup (CounterDefinition; required). HTML consolidation; backend/database adoption pending.
    81Mandatory
    Dropped · Merged into IsMandatory
    bool?Nullable
    Formerly required for: CounterDefinition, CounterTemplate

    Current review decision: Merged into IsMandatory and dropped as a separate field. The merged field retains counter and maintenance-requirement meanings according to row role. Original explanation and sources retained for history. Backend/database unchanged.

    In plain language Says this counter is required, rather than saying an inspection is mandatory.

    Real-world situation

    The aircraft setup requires flying-hours and cycles counters.

    What this means in practice Those counters must be maintained under the adopted rules. An optional inspection can still use them; counter obligation and inspection obligation are different.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Current decision: Dropped · Merged into IsMandatory by user review. The previous separate-field design below is superseded. Retain source row roles during adoption. Backend/database unchanged.

    Original design note (superseded): Counter-definition/template requirement flag. It concerns whether a counter must exist/be maintained, while IsMandatory concerns a maintenance requirement; their meanings should not be merged merely because both are Booleans.

    Indicates whether mandatory applies to this counter definition.
    Used by: CounterDefinition, CounterTemplate.
    Sources: CounterDefinition.Mandatory (CounterDefinition; required); CounterTemplate.Mandatory (CounterTemplate; required). HTML consolidation; backend/database adoption pending.
    82IsAdministrativeCorrection
    Dropped
    bool?Nullable
    Formerly required for: CounterReading

    Drop comment: Will be handled with execution. Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Says the reading corrects a data-entry/history error rather than recording new use.

    Real-world situation

    An earlier entry says 1,020 hours, but the signed record shows 1,200 hours.

    What this means in practice The correction needs supporting evidence. The 180-hour difference must not be mistaken for a newly flown 180-hour flight.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Will be handled with execution. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Marks a reading entered as a correction to recorded data rather than newly accrued operating usage. Preserve its reason and history; correction sequencing needs explicit implementation rules.

    Indicates whether administrative correction applies to this counter reading.
    Used by: CounterReading.
    Sources: CounterReading.IsAdministrativeCorrection (CounterReading; required). HTML consolidation; backend/database adoption pending.
    83ManufactureDate
    Dropped
    DateTime?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language When the aircraft or component was made, where relevant to age counting.

    Real-world situation

    A component was manufactured on 1 January 2025 and has an approved two-year age limit.

    What this means in practice Its age-based deadline can be calculated from manufacture. Installing it later does not silently change that starting date.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Manufacturing timestamp relevant to an asset counter or age-based calculation. AMOS uses manufacture dates for calendar-age counters and appropriate baselines.

    Records the manufacture date for this asset counter.
    Used by: AssetCounter.
    Sources: AssetCounter.ManufactureDate (AssetCounter; nullable). HTML consolidation; backend/database adoption pending.
    84RequirementGroupRemarks
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Notes explaining a group of requirements or limits.

    Real-world situation

    Maya writes “Use the earlier of the hours and calendar deadlines”.

    What this means in practice A reviewer understands the intention. The structured calculation setting must agree with the note; prose alone does not configure the calculator.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Notes explaining a requirement group. They can clarify interpretation but should not secretly override the structured limit or calculation logic.

    Records requirement group remarks for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RequirementGroupRemarks (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    85DefinitionDescription
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Explains what a counter measures.

    Real-world situation

    Maya writes “Total APU running hours recorded for this aircraft”.

    What this means in practice Someone selecting a counter can distinguish APU hours from aircraft flying hours even though both are measured in hours.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Explanation of what a counter counts and how its values should be understood. It is distinct from the counting expression.

    Records definition description for this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.DefinitionDescription (CounterDefinition; nullable). HTML consolidation; backend/database adoption pending.
    86GroupDescription
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Explains why a bundle of counter setups exists.

    Real-world situation

    Maya writes “Counters used for our standard aircraft setup: flight hours and flight cycles”.

    What this means in practice A user understands what the bundle is for before assigning it to an aircraft type.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Description of a counter-template group and its intended assignments.

    Records group description for this counter template group.
    Used by: CounterTemplateGroup.
    Sources: CounterTemplateGroup.GroupDescription (CounterTemplateGroup; nullable). HTML consolidation; backend/database adoption pending.
    87TemplateDescription
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Explains how a reusable counter setup is intended to work.

    Real-world situation

    Maya writes “Component counter follows aircraft flying hours while the component is installed”.

    What this means in practice A user understands the setup before creating an individual component counter. The description itself is not a calculation formula.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Description of the counting setup for a reusable counter template. AMOS permits template description edits even where existing counter readings restrict other changes.

    Records template description for this counter template.
    Used by: CounterTemplate.
    Sources: CounterTemplate.TemplateDescription (CounterTemplate; nullable). HTML consolidation; backend/database adoption pending.
    88AdministrativeCorrectionReason
    Dropped
    string?Nullable
    Former applicability: Optional

    Drop comment: Will be handled in execution. Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Explains why recorded usage was corrected.

    Real-world situation

    Ravi writes “Corrected 1,020 to 1,200 hours after checking the signed receiving record”.

    What this means in practice A reviewer sees the reason for the change instead of suspecting unexplained additional operation. Keep the supporting evidence.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Will be handled in execution. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Reason for an administrative counter adjustment. Keep it with correction evidence and do not infer a new operating event from the numerical change.

    Records administrative correction reason for this asset counter.
    Used by: AssetCounter.
    Sources: AssetCounter.AdministrativeCorrectionReason (AssetCounter; nullable). HTML consolidation; backend/database adoption pending.
    89ReadingComment
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Extra context about one meter/counter reading.

    Real-world situation

    Ravi writes “Physical meter checked during receiving inspection; photograph attached”.

    What this means in practice A later reviewer understands how this reading was obtained. The actual numerical value is stored separately.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Optional context recorded with a particular reading; not a formula or replacement for the reading value.

    Records reading comment for this counter reading.
    Used by: CounterReading.
    Sources: CounterReading.ReadingComment (CounterReading; nullable). HTML consolidation; backend/database adoption pending.
    90SourceRevision
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language The version of the source rule used for this saved due calculation.

    Real-world situation

    The June inspection was calculated using Maintenance Programme Revision 12.

    What this means in practice Even after Revision 13 is issued, the saved calculation can still explain which approved source was used.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Identifies the source definition revision used when calculating an applied due limit. It is provenance, not a counter reading or calculation-engine version.

    Records source revision for this maintenance event due limit.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.SourceRevision (DueLimitSnapshot; nullable). HTML consolidation; backend/database adoption pending.
    91CompetencyScope
    Dropped · Moved to ResourceRequirements
    CompetencyRequirementScope? { Template, Module, Examination, Qualification, Global, Organization, BusinessUnit, Department, Designation, StaffMember, Location, Facility, AircraftFamily, AircraftType, AircraftModel, Part, AtaChapter, MaintenanceTask, LearningActivity, Authorization, ExternalProvider }Nullable
    Formerly required for: RequirementDefinition

    Review decision: Moved to ResourceRequirements and dropped from TimeRequirements. Original explanation, example and sources retained for history.

    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. The actual qualification template belongs to ResourceRequirements; whether this field belongs on every maintenance timing row still needs review.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Current decision: Dropped from TimeRequirements and moved to ResourceRequirements. The earlier timing-scope discussion below is retained as history. Backend/database unchanged.

    Detailed design note: Inherited Coflyr classification of the training/qualification scope to which a requirement relates. Competency resource selection has moved to ResourceRequirements; this retained field’s timing applicability still needs review.

    Records competency scope for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.CompetencyScope (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    92ComplianceLevel
    Dropped · Moved to ResourceRequirements
    PartRequirementComplianceLevel? { Mandatory, Recommended, Optional, InformationOnly }Nullable
    Formerly required for: RequirementDefinition

    Review decision: Moved to ResourceRequirements and dropped from TimeRequirements. Original explanation, example and sources retained for history.

    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

    Technical details and original review decision
    Current decision: Dropped from TimeRequirements and moved to ResourceRequirements. Original type, example and source definition retained below. 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: TimeRequirements.ComplianceLevel (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    93CoverageDefinition
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language Text explaining the set of aircraft or components covered.

    Real-world situation

    Maya writes “Pumps from the affected production batch listed in the source instruction”.

    What this means in practice A reviewer understands the intended coverage. A structured applicability record is still needed to identify the exact assets reliably.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Free-text description of what the requirement covers. It supplements structured effectivity rather than automatically filtering assets.

    Records coverage definition for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.CoverageDefinition (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    94EffectiveFrom
    Dropped
    DateTimeOffset?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language When the approved requirement definition starts being effective.

    Real-world situation

    A revision is approved in April but becomes effective on 1 May.

    What this means in practice New work uses it according to the controlled adoption rule. The approval/review date and the work’s due date are separate dates.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Timestamp at which the requirement definition becomes effective. This is separate from review time, publication issue date and a particular occurrence’s due date.

    Records effective from for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.EffectiveFrom (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    95ValidFrom
    Dropped
    DateTime?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language When a reusable counter setup is intended to become valid.

    Real-world situation

    A new approved counter setup is valid from 1 January.

    What this means in practice The setup’s applicability period starts then. This is not automatically the date an individual component was installed or its meter was read.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Start of a counter template’s validity window. It is not the date of an actual reading or installation.

    Records valid from for this counter template.
    Used by: CounterTemplate.
    Sources: CounterTemplate.ValidFrom (CounterTemplate; nullable). HTML consolidation; backend/database adoption pending.
    96ValidTo
    Dropped
    DateTime?Nullable
    Former applicability: Optional

    Review decision: Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language When a reusable counter setup’s validity period ends.

    Real-world situation

    The setup is replaced at the end of December.

    What this means in practice Its old readings and history must remain. Ending a setup’s validity is not the same as deleting all counters created from it.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: End of a counter template’s validity window. Ending template validity must not erase the counters/readings already created from it.

    Records valid to for this counter template.
    Used by: CounterTemplate.
    Sources: CounterTemplate.ValidTo (CounterTemplate; nullable). HTML consolidation; backend/database adoption pending.
    97MasterValueAtInstallation
    Dropped
    decimal?Nullable
    Former applicability: Optional

    Drop remark: Will be added to the actual maintenance. Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language The aircraft/master counter value when a component was fitted.

    Real-world situation

    Pump S123 is installed when the aircraft has 10,000 flying hours.

    What this means in practice This starts measuring the aircraft usage attributable to that installation period. It is not necessarily the pump’s total since-new usage.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Will be added to the actual maintenance. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Master counter total captured when a child component is installed. Later master usage is measured from this point.

    Records the master value at installation for this asset counter.
    Used by: AssetCounter.
    Sources: AssetCounter.MasterValueAtInstallation (AssetCounter; nullable). HTML consolidation; backend/database adoption pending.
    98MasterValueAtRemoval
    Dropped
    decimal?Nullable
    Former applicability: Optional

    Drop remark: Will be added to the actual maintenance. Dropped from TimeRequirements; original explanation, example and sources retained for review history.

    In plain language The aircraft/master counter value when the component was removed.

    Real-world situation

    The pump is removed when the aircraft has 10,300 flying hours.

    What this means in practice 10,300 minus the installation value 10,000 gives 300 hours during that installation, under the approved counting rules.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Will be added to the actual maintenance. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Master counter total captured when a child component is removed. Together with the installation value, it closes the usage accumulated during that installation.

    Records the master value at removal for this asset counter.
    Used by: AssetCounter.
    Sources: AssetCounter.MasterValueAtRemoval (AssetCounter; nullable). HTML consolidation; backend/database adoption pending.
    99ResetValue
    Dropped
    decimal?Nullable
    Formerly required for: AssetCounter

    Drop remark: Will be reviewed with the actual performance. Dropped from TimeRequirements; original explanation, example and sources retained for future review.

    In plain language The number used by Coflyr’s permitted reset operation.

    Real-world situation

    An approved reset for a shop process counter uses value 0.

    What this means in practice The reset is kept as an evidenced event. AMOS fixed-value resets and current Coflyr resets handle history/differences differently, so do not assume matching behavior.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. Will be reviewed with the actual performance. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Coflyr stores the value used by its reset operation. AMOS fixed-value reset readouts have special semantics with no delta; Coflyr currently records a value difference as Delta, so these behaviours must be reconciled.

    Records reset value for this asset counter.
    Used by: AssetCounter.
    Sources: AssetCounter.ResetValue (AssetCounter; required). HTML consolidation; backend/database adoption pending.
    100CounterCode
    Dropped · Replaced by MeasurementUnitId
    string?Nullable
    Formerly required for: CounterDefinition

    Historical example · CounterCode remains dropped

    In plain language A short code saying what is counted.

    Real-world situation

    AMOS uses H for flying hours and C for cycles.

    What this means in practice Many aircraft can use the H definition, but each keeps its own hours. The code is not an individual aircraft’s registration or current value.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Dropped and replaced by MeasurementUnitId, a lookup to the existing MeasureUnit master. Retain original codes and references for explicit mapping during later adoption. HTML proposal only; backend/database unchanged.

    Detailed design note: Code identifying what is counted. AMOS includes default H, C, D and OD codes and reserves standard codes; Coflyr’s mapping must be explicit.

    Records counter code for this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.CounterCode (CounterDefinition; required). HTML consolidation; backend/database adoption pending.
    101MelCategory
    Dropped · Moved to EventRequirements
    MelCategory? { None, ClassA, ClassB, ClassC, ClassD }Nullable
    Former applicability: Optional

    Review decision: Moved to EventRequirements and dropped from TimeRequirements. Original explanation, example and sources retained for history.

    In plain language The MEL category label associated with the requirement. MEL means Minimum Equipment List.

    Real-world situation

    A deferred defect’s approved MEL item has category C.

    What this means in practice The label describes the item’s classification. The exact rectification deadline and conditions must come from the approved item, not from guessing based on the letter alone.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements and moved to EventRequirements. Original nullable enum, example and source definition retained below. HTML review only; backend/database unchanged.

    Detailed design note: Legacy MEL category label on a requirement. AMOS workorder transfer records categories A, B, C and D; the approved MEL item supplies the actual conditions and timing.

    Records mel category for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.MelCategory (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    102ReportingBackMessage
    Dropped
    string?Nullable
    Former applicability: Optional

    Drop comment: For actual implementation. Dropped from TimeRequirements; completion-recording guidance will be handled during actual maintenance implementation. Original explanation, example and sources retained for review history.

    In plain language A message shown to help someone record that the work was actually completed.

    Real-world situation

    Maya writes “Enter the performed date and the aircraft hours from the signed work record”.

    What this means in practice Ravi receives clear completion-recording guidance. The next inspection must use valid accomplishment evidence, not just a clicked Completed button.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from the TimeRequirements HTML proposal. For actual implementation. Preserve the completion-recording guidance for the actual maintenance workflow. Original type, applicability, example and source definitions retained below. Backend/database unchanged.

    Detailed design note: Message intended for the accomplishment/report-back workflow. AMOS report-back records performed events and can reschedule repetitive events; the exact Coflyr display/enforcement rules remain to be defined.

    Records reporting back message for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ReportingBackMessage (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    103RequirementGroup
    Dropped · Moved to EventRequirements
    RequirementGroupOption? { ETOPS, AD, ALI, CMR, Reliability, Operational, Engineering, Safety, Contractual, Other }Nullable
    Former applicability: Optional

    Review decision: Moved to EventRequirements and dropped from TimeRequirements. Original explanation, example and sources retained for history.

    In plain language A label organizing related requirements.

    Real-world situation

    Maya places several checks under “Hydraulic periodic inspections”.

    What this means in practice The requirements are easier to browse. The label alone does not say whether their deadlines use earliest, latest or another combination rule.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from TimeRequirements and moved to EventRequirements. HTML review only; backend/database unchanged.

    Detailed design note: Legacy requirement-group label. It organizes related requirements but must not be confused with a counter-template group or an arithmetic combination rule.

    Records requirement group for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RequirementGroup (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    104RequirementType
    Legacy competency classification
    Dropped · Replaced
    CompetencyRequirementType? { Other, TrainingRequirement, ExaminationRequirement, PracticalAssessmentRequirement, OjtRequirement, ExperienceRequirement, LicenseRequirement, AuthorizationRequirement, DocumentRequirement, RegulatoryRequirement, SkillRequirement, ToolRequirement, MedicalRequirement, ParentCompetency }Nullable
    Formerly required for: RequirementDefinition

    Review decision: This legacy competency classification is dropped from TimeRequirements. RequirementType now names the Threshold / Interval enum renamed from RequirementGroupType. These enum meanings are different; preserve legacy values and map them explicitly during adoption.

    In plain language An inherited category saying what kind of obligation this is.

    Real-world situation

    A qualification rule may be an ExaminationRequirement because it requires an examination.

    What this means in practice This helps classify that obligation. The retained list contains competency categories, so an appropriate treatment for maintenance-only timing rows still needs review.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped legacy competency-based RequirementType definition, retained for history. The active RequirementType is the renamed RequirementGroupType timing enum. Do not cast competency enum values to threshold/interval values. Backend/database unchanged.

    Detailed design note: Inherited Coflyr category for the nature of an obligation, such as training, examination or authorization. Its applicability to maintenance-only timing rows still needs review.

    Records requirement type for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RequirementType (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    105RetainUntil
    Dropped
    DateTimeOffset?Nullable
    Former applicability: Optional

    Drop remark: Add to actual implementation. Dropped from the TimeRequirements HTML proposal; original explanation, example and sources retained for review history.

    In plain language A date until which the record should be preserved under the adopted retention policy.

    Real-world situation

    An inspection is due this year, but its history must be preserved until a later policy-defined date.

    What this means in practice The preservation endpoint is separate from the maintenance deadline. A hold may require keeping the record longer under implemented records rules.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from TimeRequirements. Add to actual implementation. HTML review only; backend/database unchanged.

    Detailed design note: Record-retention endpoint. It determines record preservation under the adopted retention policy, not the maintenance completion deadline.

    Records retain until for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RetainUntil (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    106RetentionCategory
    Dropped
    string?Nullable
    Former applicability: Optional

    Drop remark: Add to actual implementation. Dropped from the TimeRequirements HTML proposal; original explanation, example and sources retained for review history.

    In plain language A category used to choose how a record is preserved.

    Real-world situation

    The organization classifies a record as inspection history rather than temporary planning information.

    What this means in practice Its retention policy can differ accordingly. Accepted categories and actual enforcement must be defined by the project.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from TimeRequirements. Add to actual implementation. HTML review only; backend/database unchanged.

    Detailed design note: Metadata classifying the retention treatment of the record. The organization must define its vocabulary and enforcement rules.

    Records retention category for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RetentionCategory (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    107RowVersion
    Dropped
    UInt32?Nullable
    Formerly required for: RequirementDefinition

    Review decision: Dropped from the TimeRequirements HTML proposal. Original explanation, example and sources retained for review history.

    In plain language A computer check that prevents one person accidentally overwriting another person’s newer changes.

    Real-world situation

    Maya and Ravi open the same rule. Maya saves a change first; Ravi then tries to save his older copy.

    What this means in practice The intended update check detects Ravi’s stale copy so he can refresh. This is not the manual’s revision number and users do not normally type it.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from TimeRequirements. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Concurrency token used to detect stale updates. It is technical metadata, not a publication revision or chronological sequence number.

    Records row version for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RowVersion (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    108SatisfiedAt
    Dropped
    DateTime?Nullable
    Former applicability: Optional

    Review decision: Dropped from the TimeRequirements HTML proposal. Original explanation, example and sources retained for review history.

    In plain language When the obligation was recorded as fulfilled in its relevant context.

    Real-world situation

    Ravi records the inspection as accomplished at 14:30 on 10 June.

    What this means in practice The system can preserve that accomplishment time. For a repeating rule, the next inspection is still needed; completion alone does not release the aircraft.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Timestamp at which the requirement was recorded as satisfied in its relevant context. It is not automatically aircraft release or the next occurrence’s baseline without a validated mapping.

    Timestamp of valid satisfaction evidence for the applicable requirement occurrence. Retained independently for timing and event requirements; fulfilling one does not automatically satisfy the other. Define occurrence-level evidence and preserve historical timestamps during adoption.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.SatisfiedAt (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    109Scope
    Dropped · Moved to ResourceRequirements
    ProgramRequirementScope? { Program, Task, Effectivity, Competency, Part, ComponentPart, ComponentResource, Deferred, Safety, Event }Nullable
    Formerly required for: RequirementDefinition

    Review decision: Moved to ResourceRequirements and dropped from TimeRequirements. Original explanation, example and sources retained for history.

    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

    Technical details and original review decision
    Dropped from TimeRequirements and moved to ResourceRequirements. 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: TimeRequirements.Scope (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    110ScopeCode
    Dropped · Moved to ResourceRequirements
    string?Nullable
    Former applicability: Optional

    Review decision: Moved to ResourceRequirements and dropped from TimeRequirements. Original explanation, example and sources retained for history.

    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
    Dropped from TimeRequirements and moved to ResourceRequirements. 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: TimeRequirements.ScopeCode (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    111LastRefreshedAt
    Dropped
    DateTime?Nullable
    Former applicability: Optional

    Drop remark: Required in forecast and post-performance. Dropped from the TimeRequirements HTML proposal; retain this requirement for forecast and post-performance implementation. Original explanation, example and sources retained for review history.

    In plain language When the software last recalculated this saved forecast.

    Real-world situation

    The forecast was refreshed yesterday, but a new flight was entered this morning.

    What this means in practice A planner can see that the forecast may be stale and needs recalculation. Refresh time is not the time the aircraft’s meter was read.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Required in forecast and post-performance. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Timestamp when the applied calculation was last refreshed. It helps identify stale forecasts when new readings or utilization assumptions arrive.

    Records the last refreshed at for this maintenance event due limit.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.LastRefreshedAt (DueLimitSnapshot; nullable). HTML consolidation; backend/database adoption pending.
    112ObservedAt
    Dropped
    DateTime?Nullable
    Formerly required for: DueLimitSnapshot

    Drop remark: Required in forecast and post-performance. Dropped from the TimeRequirements HTML proposal; retain this requirement for forecast and post-performance implementation. Original explanation, example and sources retained for review history.

    In plain language When the usage value used in the calculation was actually observed.

    Real-world situation

    The aircraft’s 1,200-hour total is associated with 18:00 yesterday; the forecast job runs at 19:00.

    What this means in practice The calculation keeps 18:00 as the observation time. Running the job later does not make the underlying reading newer.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Required in forecast and post-performance. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Timestamp associated with the counter observation used in the snapshot. It is different from the time the software later recalculates the forecast.

    Records the observed at for this maintenance event due limit.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.ObservedAt (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    113RemainingValue
    Dropped
    decimal?Nullable
    Former applicability: Optional

    Drop remark: Required in forecast and post-performance. Dropped from the TimeRequirements HTML proposal; retain this requirement for forecast and post-performance implementation. Original explanation, example and sources retained for review history.

    In plain language How much usage is left before the nominal counter deadline.

    Real-world situation

    The inspection is due at 1,500 flying hours and the aircraft currently has 1,200.

    What this means in practice There are 300 flying hours left. If the aircraft has 1,510, the value is −10, meaning it is beyond the nominal threshold, subject to the approved rule.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Required in forecast and post-performance. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Usage remaining to the due counter value at the captured observation. A negative result indicates the nominal counter threshold has been exceeded, subject to the approved rule.

    Records remaining value for this maintenance event due limit.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.RemainingValue (DueLimitSnapshot; nullable). HTML consolidation; backend/database adoption pending.
    114RecordedAt
    Dropped
    DateTime?Nullable
    Formerly required for: CounterReading

    Review decision: Dropped from the TimeRequirements HTML proposal. Original explanation, example and sources retained for review history.

    In plain language When the reading was entered into Coflyr.

    Real-world situation

    Ravi reads a meter at 09:00 and enters it at 10:00.

    What this means in practice Current Coflyr records 10:00 UTC as entry time. The actual 09:00 observation needs its own preserved context; the two times must not be confused.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from TimeRequirements. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Timestamp when Coflyr records the reading. The current service assigns UTC entry time; delayed entry must not be confused with the physical observation time used for historical calculations.

    Records the recorded at for this counter reading.
    Used by: CounterReading.
    Sources: CounterReading.RecordedAt (CounterReading; required). HTML consolidation; backend/database adoption pending.
    115Delta
    Dropped
    decimal?Nullable
    Formerly required for: CounterReading

    Drop remark: For actual implementation. Dropped from TimeRequirements; retain the reading-difference requirement for actual maintenance implementation. Original explanation, example and sources retained for review history.

    In plain language How much the value changed compared with the preceding applicable reading.

    Real-world situation

    The previous aircraft reading was 1,197.5 hours and the new reading is 1,200.

    What this means in practice The increase is 2.5 hours. A correction/reset difference needs special interpretation; not every numerical increase is actual flying.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. For actual implementation. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Change represented by a reading relative to the preceding applicable value. Corrections and resets need explicit treatment; the number alone does not prove physical operation.

    Records delta for this counter reading.
    Used by: CounterReading.
    Sources: CounterReading.Delta (CounterReading; required). HTML consolidation; backend/database adoption pending.
    116Behavior
    Dropped · Moved to EventRequirements
    CounterTemplateBehavior? { Master, Child, Standalone }Nullable
    Formerly required for: CounterTemplate

    Review decision: Moved to EventRequirements and dropped from TimeRequirements. Original explanation, example and sources retained for history.

    In plain language Says whether a counter leads other counters, follows one while installed, or operates independently.

    Real-world situation

    The aircraft hours counter is Master. An installed pump’s hours counter can be Child.

    What this means in practice The child follows usage attributable to its installation under the approved counting rules. Standalone means it is not a master/child counter.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements and moved to EventRequirements. HTML review only; backend/database unchanged.

    Detailed design note: Defines a counter template as Master, Child or Standalone. AMOS distinguishes these relationships; readable input is a separate property in this Coflyr proposal.

    Records behavior for this counter template.
    Used by: CounterTemplate.
    Sources: CounterTemplate.Behavior (CounterTemplate; required). HTML consolidation; backend/database adoption pending.
    117InstallationPosition
    Dropped · Moved to EventRequirements
    string?Nullable
    Former applicability: Optional

    Review decision: Moved to EventRequirements and dropped from TimeRequirements. Original explanation, example and sources retained for history.

    In plain language Where the component is installed, as recorded for its usage context.

    Real-world situation

    Pump serial S123 is installed in the left hydraulic-pump position.

    What this means in practice The counter history can be associated with that installation location. Structured configuration consistency still needs explicit validation.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements and moved to EventRequirements. HTML review only; backend/database unchanged.

    Detailed design note: Position associated with an installed component’s asset counter. It supplies installation context and must be reconciled with structured configuration where available.

    Records installation position for this asset counter.
    Used by: AssetCounter.
    Sources: AssetCounter.InstallationPosition (AssetCounter; nullable). HTML consolidation; backend/database adoption pending.
    118GroupCode
    Dropped
    string?Nullable
    Formerly required for: CounterTemplateGroup

    Review decision: Dropped from the TimeRequirements HTML proposal. Original explanation, example and sources retained for review history.

    In plain language A business code identifying a bundle of counter setups.

    Real-world situation

    Maya uses AIRFRAME-STD for a bundle containing hours and cycles.

    What this means in practice Users can find and assign that bundle. The code does not identify an inspection limit group or a particular aircraft’s counter.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Business code identifying a counter-template group. It does not identify a time-limit dimension group or a concrete aircraft counter.

    Records group code for this counter template group.
    Used by: CounterTemplateGroup.
    Sources: CounterTemplateGroup.GroupCode (CounterTemplateGroup; required). HTML consolidation; backend/database adoption pending.
    119RuleSetJson
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from the TimeRequirements HTML proposal. Original explanation, example and sources retained for review history.

    In plain language Computer-formatted conditions used by a counter calculation.

    Real-world situation

    An approved setup specifies what to do if required flight timestamps are missing.

    What this means in practice The software can apply a validated rule once implemented. Free text or arbitrary JSON must not be assumed to be a working calculation.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Coflyr structured configuration for counter-calculation conditions. AMOS has mathematical/logical formula rules; the exact JSON schema is a project implementation detail.

    Records rule set json for this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.RuleSetJson (CounterDefinition; nullable). HTML consolidation; backend/database adoption pending.
    120InputMode
    Dropped
    CounterInputMode? { Manual, Calculated, Hybrid }Nullable
    Formerly required for: CounterDefinition, CounterTemplate

    Review decision: Dropped from the TimeRequirements HTML proposal. Original explanation, example and sources retained for review history.

    In plain language Says whether values are entered manually, calculated by software or allowed through both paths.

    Real-world situation

    A physical meter is read manually; a flight-hours counter may be calculated from flight logs.

    What this means in practice The mode guides permitted entry. AMOS readable counters are not formula-calculated, so Coflyr’s Hybrid choice needs explicit validation rather than assuming it is equivalent.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Coflyr classification of Manual, Calculated or Hybrid entry. AMOS distinguishes physically readable counters from calculated counters; Hybrid is not established as equivalent AMOS behaviour.

    Records input mode for this counter definition.
    Used by: CounterDefinition, CounterTemplate.
    Sources: CounterDefinition.InputMode (CounterDefinition; required); CounterTemplate.InputMode (CounterTemplate; required). HTML consolidation; backend/database adoption pending.
    121IndividualCalculationRuleJson
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from the TimeRequirements HTML proposal. Original explanation, example and sources retained for review history.

    In plain language Computer-formatted settings for a specially adapted counter formula. Users should normally edit these through a suitable form, not type raw JSON.

    Real-world situation

    One aircraft has an approved special APU-hours counting rule.

    What this means in practice Its special settings can be saved without changing the standard fleet setup. The project still needs a validated format and implementation for these settings.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Coflyr serialized configuration for an individualized counter rule. AMOS supports individualizing formulas, but this JSON shape is a project representation requiring schema validation.

    Records individual calculation rule json for this counter definition.
    Used by: CounterDefinition, CounterTemplate.
    Sources: CounterDefinition.IndividualCalculationRuleJson (CounterDefinition; nullable); CounterTemplate.IndividualCalculationRuleJson (CounterTemplate; nullable). HTML consolidation; backend/database adoption pending.
    122DisplayOrder
    Dropped
    int?Nullable
    Formerly required for: CounterDefinition

    Review decision: Dropped from the TimeRequirements HTML proposal. Original explanation, example and sources retained for review history.

    In plain language Where the counter appears in a list.

    Real-world situation

    Maya gives flying hours display order 1 and cycles display order 2.

    What this means in practice Users see flying hours before cycles. This does not decide which counter is calculated first or which inspection deadline controls.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from TimeRequirements. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Order of counter definitions in displays. It is separate from calculation dependencies and from the ordering of limit rows.

    Records display order for this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.DisplayOrder (CounterDefinition; required). HTML consolidation; backend/database adoption pending.
    123DisplayUnit
    Dropped · Review later
    string?Nullable
    Formerly required for: CounterDefinition

    Drop remark: Review later. Dropped from the TimeRequirements HTML proposal; future review required. Original explanation, example and sources retained for review history.

    In plain language The unit label printed beside the value.

    Real-world situation

    The screen shows 1,200 FH for flight hours and 8,400 FC for flight cycles.

    What this means in practice People know what the number measures. Typing a different label does not convert hours into cycles.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Review later; future review required. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Unit label shown with counter values. A label does not convert values or prove compatibility with a selected maintenance limit.

    Records display unit for this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.DisplayUnit (CounterDefinition; required). HTML consolidation; backend/database adoption pending.
    124DisplayFormat
    Dropped · Review later
    CounterDisplayFormat? { WholeNumber, DecimalNumber, TimeAmount }Nullable
    Formerly required for: CounterDefinition

    Drop remark: Review later. Dropped from the TimeRequirements HTML proposal; future review required. Original explanation, example and sources retained for review history.

    In plain language How the number appears on screen.

    Real-world situation

    Cycles appear as 12,345; flying hours may appear as 1,200.5.

    What this means in practice The chosen appearance helps users read the value. Formatting must not silently change the stored quantity or confuse decimal hours with hours-and-minutes notation.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Review later; future review required. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Presentation format of a counter value, such as whole number, decimal number or time amount. It must not change the underlying stored quantity.

    Records display format for this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.DisplayFormat (CounterDefinition; required). HTML consolidation; backend/database adoption pending.
    125CalculationOrder
    Dropped · Future development
    int?Nullable
    Former applicability: Optional

    Drop remark: Future development. Dropped from the TimeRequirements HTML proposal; retain for future development and review. Original explanation, example and sources retained for history.

    In plain language An intended order for evaluating formulas that depend on other results.

    Real-world situation

    A custom counter needs the flight-duration result, so flight duration is calculated first.

    What this means in practice The required input is available before the dependent calculation runs. The design must also reject circular dependencies rather than relying only on an order number.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from TimeRequirements. Future development; future review required. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Order intended for evaluating calculated counters with dependencies. It must not replace dependency validation or allow circular formulas.

    Records calculation order for this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.CalculationOrder (CounterDefinition; nullable). HTML consolidation; backend/database adoption pending.
    126CalculationExpression
    Dropped · Future development
    string?Nullable
    Former applicability: Optional

    Drop remark: Future development. Dropped from the TimeRequirements HTML proposal; retain for future development and review. Original explanation, example and sources retained for history.

    In plain language The formula used to calculate how a usage counter grows.

    Real-world situation

    The approved flying-hours setup derives flight duration from the flight records.

    What this means in practice That formula can produce usage increments when implemented and validated. It is different from the inspection rule “repeat every 500 flying hours”.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Future development; future review required. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Formula describing how a calculated counter accrues value. AMOS supports counter formulas and dependencies; Coflyr’s expression syntax and execution support require explicit validation.

    Records calculation expression for this counter definition.
    Used by: CounterDefinition.
    Sources: CounterDefinition.CalculationExpression (CounterDefinition; nullable). HTML consolidation; backend/database adoption pending.
    127CalculationVersion
    Dropped · Future development
    string?Nullable
    Formerly required for: DueLimitSnapshot

    Drop remark: Future development. Dropped from the TimeRequirements HTML proposal; retain for future development and review. Original explanation, example and sources retained for history.

    In plain language Identifies the software calculation version that produced the saved result.

    Real-world situation

    A calculation uses software rule-engine version 2 and Maintenance Programme Revision 12.

    What this means in practice Investigators can distinguish a software-version change from a maintenance-document revision. This value is normally assigned by the software.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from TimeRequirements. Future development; future review required. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Technical identifier for the calculator/rule implementation that produced a snapshot. It differs from the publication’s SourceRevision.

    Records calculation version for this maintenance event due limit.
    Used by: DueLimitSnapshot.
    Sources: MaintenanceEventDueLimit.CalculationVersion (DueLimitSnapshot; required). HTML consolidation; backend/database adoption pending.
    128RecordRetentionRule
    Dropped · Future development
    string?Nullable
    Former applicability: Optional

    Drop remark: Future development. Dropped from the TimeRequirements HTML proposal; retain for future development and review. Original explanation, example and sources retained for history.

    In plain language Text describing how long or under what policy the record should be kept.

    Real-world situation

    The organization records “Keep with the aircraft’s controlled maintenance history”.

    What this means in practice Records-management rules can use this information once implemented. This does not change the inspection interval or automatically delete records.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from TimeRequirements. Future development; future review required. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Text describing a retention rule for requirement records. It does not calculate maintenance due dates or implement deletion by itself.

    Records record retention rule for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RecordRetentionRule (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    129RecordCode
    Dropped
    string?Nullable
    Former applicability: Optional

    Review decision: Dropped from the TimeRequirements HTML proposal. Original explanation, example and sources retained for review history.

    In plain language A general code inherited from the requirement record.

    Real-world situation

    Maya uses REQ-HYD-01 for a hydraulic inspection record.

    What this means in practice It helps identify the record in a list. Its distinction from RequirementCode and ShortcutCode still needs review; it does not specify a usage unit.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped from TimeRequirements. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: General code inherited from the requirement record. Its relation to RequirementCode and ShortcutCode remains to be defined; do not infer a counter dimension from it.

    Records record code for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RecordCode (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    130CounterReadingSource
    Dropped
    CounterReadingSource? { Manual, FlightLog, ComponentBooking, DataImport, Calculation, Reset }Nullable
    Formerly required for: CounterReading

    Review decision: Dropped from the TimeRequirements HTML proposal. Original explanation, example and sources retained for review history.

    In plain language Says how this particular reading entered the system.

    Real-world situation

    A reading comes from flight log FL-204, so its source is FlightLog. A technician’s entry is Manual.

    What this means in practice Reviewers understand the reading’s origin. This is separate from whether the inspection rule came from a manufacturer publication.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped from TimeRequirements. Original type, applicability and source definitions retained below. HTML review only; backend/database unchanged.

    Detailed design note: Origin of a reading: manual entry, flight log, component booking, import, calculation or reset. This is distinct from a requirement’s publication/regulatory SourceType.

    Origin of a CounterReading: Manual, FlightLog, ComponentBooking, DataImport, Calculation or Reset. Renamed from CounterReading.Source. It is separate from SourceType, which classifies a requirement’s regulatory/publication origin.
    Used by: CounterReading.
    Sources: CounterReading.Source (CounterReading; required). HTML consolidation; backend/database adoption pending.
    131RecordName
    Dropped · Merged into RequirementTitle
    string?Nullable
    Former applicability: Optional

    Merge decision: Merged into RequirementTitle and dropped as a separate field. Earlier overlap-review notes below are superseded. Original explanation, example and sources retained for history.

    In plain language A short name shown to people so they can recognize the record.

    Real-world situation

    Maya enters “Hydraulic filter inspection”.

    What this means in practice The list is easier to read. This name does not tell Coflyr how often to inspect; the interval must be entered separately. Its overlap with RequirementTitle still needs review.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped · Merged into RequirementTitle. The earlier separate-field proposal and pending-overlap notes are superseded. Preserve source values and reconcile differing names during later adoption. Backend/database unchanged.

    Detailed design note: Optional human-readable record label inherited from the shared requirement model. Its relationship to RequirementTitle needs review; this field does not define a timing calculation.

    Records record name for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RecordName (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    132SourceBusinessPartnerId
    Dropped · Merged into IssuingAuthorityBusinessPartnerId
    Guid?Nullable
    Former applicability: Optional

    Merge decision: Merged into IssuingAuthorityBusinessPartnerId and dropped as a separate field. Original explanation, example and sources retained for history.

    In plain language Selects the company or organization that supplied the requirement.

    Real-world situation

    The pump manufacturer issued the inspection instruction. Maya selects that manufacturer from Business Partners.

    What this means in practice A reviewer knows who supplied the instruction. The aircraft’s airline is selected only if that airline actually issued the rule.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped · Merged into IssuingAuthorityBusinessPartnerId. Preserve source values and reconcile differing partner identities during later adoption. The earlier separate-field proposal is superseded. Backend/database unchanged.

    Detailed design note: Selects the organization supplying or issuing the requirement. It identifies the source organization, not the aircraft operator unless that operator actually issued the rule.

    Selects the related source business partner record.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.SourceBusinessPartnerId (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    133JurisdictionBusinessPartnerId
    Dropped · Merged into RegulatoryFrameworkBusinessPartnerId
    Guid?
    BusinessPartner lookup
    Nullable
    Formerly required for: RequirementDefinition

    Merge decision: Merged into RegulatoryFrameworkBusinessPartnerId and dropped as a separate field. Original explanation, example and sources retained for history.

    In plain language Selects the BusinessPartner record representing the jurisdiction authority associated with the source obligation.

    Real-world situation

    Maya selects the BusinessPartner record for the jurisdiction authority identified in the controlled compliance record.

    What this means in practice Reviewers see the selected authority’s name, while the field stores its BusinessPartner identifier. Selecting it does not automatically determine applicability or verify regulatory compliance.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped · Merged into RegulatoryFrameworkBusinessPartnerId. The earlier separate-jurisdiction-field proposal is superseded. Preserve source values and reconcile differing authority identities during later adoption. Backend/database unchanged.

    Reviewed BusinessPartner lookup: JurisdictionBusinessPartnerId selects BusinessPartner.Id for the jurisdiction authority. Backend/database unchanged.

    HTML rename: Jurisdiction → JurisdictionBusinessPartnerId. Nullable Guid lookup to BusinessPartner.Id, replacing the former jurisdiction text. Select the BusinessPartner representing the jurisdiction authority; preserve the distinction from the issuing authority. Resolve legacy text explicitly to the appropriate saved record during adoption. Original string definition retained below for history. Backend/database unchanged; lookup reviewed.

    Detailed design note: Coflyr metadata identifying the jurisdiction associated with the source obligation. It does not automatically determine the applicable regulatory rules.

    Records jurisdiction for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.Jurisdiction (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    134RecurrentFrequencyValue
    Dropped · Replaced by structured interval limits
    int?Nullable
    Former applicability: Optional

    Drop decision: Recurrence is managed through structured interval limits using Amount, Dimension and LimitType = Interval, with the approved baseline and next-due strategy. The separate RecurrentFrequencyValue and RecurrentFrequencyUnit fields are dropped to avoid parallel recurrence calculations. Original definitions retained for history.

    In plain language The number paired with the old recurrence unit.

    Real-world situation

    Maya enters 24, with Months selected in RecurrentFrequencyUnit.

    What this means in practice Together they describe a two-year repeat period. The number alone does not say when counting starts.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Dropped: Replaced by structured interval limits. This supersedes the earlier reviewed decision to retain the separate recurrence pair. Map each legacy value and unit together to the applicable interval limit during later adoption, preserving its baseline, scope and next-due strategy. Days, Months and Years map to their corresponding calendar dimensions; Weeks requires an explicit seven-calendar-days mapping and agreed boundary semantics. Do not convert months or years to fixed day counts or silently overwrite a conflicting existing interval. ValidityPeriodValue and ValidityPeriodUnit retain their separate validity-duration meaning. Original source values and definitions preserved below. HTML review only; backend/database unchanged.

    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Number of calendar units between recurrences in the inherited field pair. It is not a flight-hour or cycle count.

    Records recurrent frequency value for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RecurrentFrequencyValue (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    135RecurrentFrequencyUnit
    Dropped · Replaced by structured interval limits
    TrainingRecurrenceUnit? { Days, Weeks, Months, Years }Nullable
    Former applicability: Optional

    Drop decision: Recurrence is managed through structured interval limits using Amount, Dimension and LimitType = Interval, with the approved baseline and next-due strategy. The separate RecurrentFrequencyValue and RecurrentFrequencyUnit fields are dropped to avoid parallel recurrence calculations. Original definitions retained for history.

    In plain language The calendar unit paired with the old recurrence number.

    Real-world situation

    A recurrent training rule has value 24 and unit Months.

    What this means in practice The pair means every 24 months, not every 24 flying hours. Reconcile it with the detailed timing-limit design before choosing one calculation path.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision

    Dropped: Replaced by structured interval limits. This supersedes the earlier reviewed decision to retain the separate recurrence pair. Map each legacy value and unit together to the applicable interval limit during later adoption, preserving its baseline, scope and next-due strategy. Days, Months and Years map to their corresponding calendar dimensions; Weeks requires an explicit seven-calendar-days mapping and agreed boundary semantics. Do not convert months or years to fixed day counts or silently overwrite a conflicting existing interval. ValidityPeriodValue and ValidityPeriodUnit retain their separate validity-duration meaning. Original source values and definitions preserved below. HTML review only; backend/database unchanged.

    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Calendar unit for an inherited recurrence value, such as Months or Years. Reconcile this pair with structured timing limits to avoid competing recurrence calculations.

    Records recurrent frequency unit for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.RecurrentFrequencyUnit (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    136HoursLimit
    Dropped · Consolidated into structured limits
    int?Nullable
    Former applicability: Optional

    Consolidation decision: Use Amount as the numeric value, Dimension as the unit/counter dimension, and LimitType to distinguish Threshold and Interval. The approved baseline supplies the starting point. HoursLimit is dropped as a separate field. Original definition retained for history.

    In plain language An old header field holding an hours amount; the correct hours counter must be identified.

    Real-world situation

    A legacy record says inspect every 500 flying hours.

    What this means in practice Use flying hours, not 500 clock hours or APU hours. Reconcile this field with the detailed hours-limit record.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Dropped · Consolidated: HoursLimit is represented by the corresponding structured LimitDefinition row. Identify FH versus AH or a custom hours counter from the approved source; hours must not be assumed to mean elapsed clock hours. Preserve legacy values and map each applicable limit separately during later adoption; reconcile conflicts with existing structured limits before migration. The earlier reviewed separate-field decision is superseded. HTML review only; backend/database unchanged.

    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Legacy header-level hours limit. The approved rule must identify the correct hours counter and baseline; reconcile it with structured limits.

    Records hours limit for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.HoursLimit (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    137CyclesLimit
    Dropped · Consolidated into structured limits
    int?Nullable
    Former applicability: Optional

    Consolidation decision: Use Amount as the numeric value, Dimension as the unit/counter dimension, and LimitType to distinguish Threshold and Interval. The approved baseline supplies the starting point. CyclesLimit is dropped as a separate field. Original definition retained for history.

    In plain language An old header field holding a cycle amount; its detailed meaning must be preserved when adopting structured limits.

    Real-world situation

    A legacy record says repeat the inspection every 500 flight cycles.

    What this means in practice Map it to the reviewed cycle-limit record. Do not evaluate the old field and the new limit as two unrelated obligations.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Dropped · Consolidated: CyclesLimit is represented by the corresponding structured LimitDefinition row. Use FC where the approved source specifies flight cycles; do not substitute landings or unrelated cycle counts. Preserve legacy values and map each applicable limit separately during later adoption; reconcile conflicts with existing structured limits before migration. The earlier reviewed separate-field decision is superseded. HTML review only; backend/database unchanged.

    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Legacy header-level cycle limit. Preserve its meaning and reconcile it with a structured FC LimitDefinition before adopting one authoritative calculation path.

    Records cycles limit for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.CyclesLimit (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    138DaysLimit
    Dropped · Consolidated into structured limits
    int?Nullable
    Former applicability: Optional

    Consolidation decision: Use Amount as the numeric value, Dimension as the unit/counter dimension, and LimitType to distinguish Threshold and Interval. The approved baseline supplies the starting point. DaysLimit is dropped as a separate field. Original definition retained for history.

    In plain language An old header field holding a number of days.

    Real-world situation

    A legacy inspection rule allows 30 days from installation.

    What this means in practice The start date and meaning of “day” are needed. Reconcile it with a detailed 30-day limit so the software does not run two conflicting rules.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Dropped · Consolidated: DaysLimit is represented by the corresponding structured LimitDefinition row. Use DY with an explicit calendar or elapsed-day interpretation and the approved starting point. Preserve legacy values and map each applicable limit separately during later adoption; reconcile conflicts with existing structured limits before migration. The earlier reviewed separate-field decision is superseded. HTML review only; backend/database unchanged.

    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Legacy header-level day limit. Reconcile it with a structured DY limit and its baseline, including calendar versus elapsed-day semantics.

    Records days limit for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.DaysLimit (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    139TimeThresholdValue
    Dropped · Consolidated into structured limits
    decimal?Nullable
    Former applicability: Optional

    Consolidation decision: Use Amount as the numeric value, Dimension as the unit/counter dimension, and LimitType to distinguish Threshold and Interval. The approved baseline supplies the starting point. TimeThresholdValue is dropped as a separate field. Original definition retained for history.

    In plain language A legacy number for the first time work becomes due. It needs a unit and starting point to make sense.

    Real-world situation

    The source says the first inspection is due at 5,000 cycles.

    What this means in practice The number 5,000 alone is insufficient. Reconcile this old field with the detailed cycle-limit record so two competing calculations are not created.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision

    Dropped · Consolidated: TimeThresholdValue is represented by the corresponding structured LimitDefinition row. Use LimitType = Threshold with the source-defined Dimension and baseline. An absolute since-new threshold must not be treated as an additional interval from a later reading. Preserve legacy values and map each applicable limit separately during later adoption; reconcile conflicts with existing structured limits before migration. The earlier reviewed separate-field decision is superseded. HTML review only; backend/database unchanged.

    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Legacy header-level threshold amount. A dimension and baseline are essential to interpret it; reconcile it with structured LimitDefinition.Amount instead of evaluating conflicting duplicate limits.

    Records the time threshold value for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.TimeThresholdValue (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    140IsOneTimeOnly
    Dropped · Merged into RecurrenceMode
    bool?Nullable
    Formerly required for: RequirementDefinition

    Merge decision: Merged into RecurrenceMode and dropped as a separate field. Original explanation, example and sources retained for history.

    In plain language Says this action is required once for the affected aircraft or component.

    Real-world situation

    An aircraft needs a one-time inspection after a modification.

    What this means in practice After valid accomplishment, the system should not keep creating another identical periodic inspection unless a separate rule requires one.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped · Merged into RecurrenceMode. The earlier reviewed separate-field proposal is superseded. Preserve and explicitly reconcile legacy values during later adoption. HTML review only; backend/database unchanged.
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Identifies a single required accomplishment for the applicable asset/context. A completed one-time action should not automatically create a repeating interval.

    Whether this requirement applies once for the relevant asset and approved applicability context. Retained independently on timing and event rules. An event processor must still handle retries idempotently; false does not prescribe a calendar recurrence.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.IsOneTimeOnly (RequirementDefinition; required). HTML consolidation; backend/database adoption pending.
    141TimeIsRepetitive
    Dropped · Merged into RecurrenceMode
    bool?Nullable
    Former applicability: Optional

    Merge decision: Merged into RecurrenceMode and dropped as a separate field. Original explanation, example and sources retained for history.

    In plain language Says the work repeats after it is done.

    Real-world situation

    The filter must be inspected every 500 flying hours.

    What this means in practice After valid completion, another inspection becomes due according to the repeat rule. It is different from a one-time modification check.

    AMOS concept · Coflyr field mapping

    Technical details and original review decision
    Dropped · Merged into RecurrenceMode. The earlier reviewed separate-field proposal is superseded. Preserve and explicitly reconcile legacy values during later adoption. HTML review only; backend/database unchanged.
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged; adoption pending complete review.

    Detailed design note: Marks a requirement that repeats after accomplishment under its approved interval and next-due strategy.

    Indicates whether time is repetitive applies to this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.TimeIsRepetitive (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.
    142ShortcutCode
    Dropped · Merged into RequirementCode
    string?Nullable
    Former applicability: Optional

    Merge decision: Merged into RequirementCode and dropped as a separate field. Original explanation, example and sources retained for history.

    In plain language A short nickname/code for quickly finding the requirement.

    Real-world situation

    Maya uses HYD-FLT as a shortcut for the hydraulic filter inspection.

    What this means in practice A planner can search the short code. It does not replace the full business code, source document or permanent record ID.

    Coflyr metadata / proposal · no direct AMOS field definition cited

    Technical details and original review decision
    Dropped · Merged into RequirementCode. The earlier reviewed separate-field proposal is superseded. Preserve and explicitly reconcile legacy values during later adoption. HTML review only; backend/database unchanged.
    Reviewed in the TimeRequirements HTML proposal. Backend/database unchanged.

    Detailed design note: Optional abbreviated code for convenient lookup/display. It is not a UUID or a counter formula variable unless the adopted design explicitly makes it one.

    Records shortcut code for this requirements.
    Used by: RequirementDefinition.
    Sources: TimeRequirements.ShortcutCode (RequirementDefinition; nullable). HTML consolidation; backend/database adoption pending.

    AMOS reference passages

    References link to the locally extracted AMOS manuals. Line numbers refer to those text files. These passages support the documented business concepts; Coflyr role names, UUID links, JSON formats and the single-table proposal remain project design choices.

    Dropped source tables · original fields retained