Fix BigQuery field description limits for input layer

models/input_layer/input_layer__eligibility.yml

@@ -73,7 +73,7 @@ models:
       materialized: view
     columns:
       - name: person_id
-        description: 'Unique identifier for each person in the dataset. person_id is a required (string) field that ideally contains a person-level UUID (Universally Unique Identifier), if available. This can be populated from the Tuva EMPI Engine or with your own Master Patient Index identifier. If you dont have a UUID, we recommend mapping the source patient identifier to this field (member_id for claims and patient_id for clinical). The primary key for the eligibility table is person_id, member_id, enrollment_start_date, enrollment_end_date, and data_source. There are two commonly used data formats for eligibility (also known as enrollment) data: the eligibility span format and the member month format. The eligibility span format has one record per member eligibility span. An eligibility span is a time period when a member was enrolled with and therefore had insurance coverage by a health plan. An eligibility span has a start date and an end date. A person can have multiple eligibility spans. The member month format has one record per member per month of enrollment. For example, a person with a single eligibility span from 1/1/2020 through 3/31/2020 would have a single eligibility span record, but 3 member month records, one for each month. The eligibility table follows the eligibility span format.'
+        description: 'Unique identifier for each person in the dataset. This required string should ideally be a person-level UUID, whether from the Tuva EMPI Engine or your own master patient index. If no UUID is available, map the source patient identifier to person_id, such as member_id in claims or patient_id in clinical data. The eligibility table follows the eligibility span format, so a person may appear on multiple rows because the table key also includes member_id, enrollment dates, and data_source, but person_id itself should remain stable across coverage periods, plans, payers, and source files for the same individual.'
         mapping_instructions: >-
           Map this field to a unique person-level identifier. The same person
           should not have multiple `person_id` values across payers, data