A multi-platform integrated approach to tracing the source of language learning and practical achievements

Abstract

This application belongs to the field of data processing technology, specifically involving an integrated traceability method for language learning and practice results across multiple platforms. The method includes: acquiring learning behavior data from multiple platforms; standardizing and converting the multi-platform learning behavior data and writing a unified event serial number to generate a unified learning record; writing user identifiers, timestamps, record summary values, and previous record summary values ​​into the unified learning record to generate a chained record sequence; storing the chained record sequence in a storage network, and generating a restricted access copy and an integrity verification copy when the sharing request is verified; performing behavior fragment coverage checks and supplementary collection based on the integrity verification copy to generate a complete set of learning behaviors; and integrating the complete set of learning behaviors across platforms to generate a learning trajectory archive. This application can balance record reliability, sharing controllability, and trajectory integrity.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, specifically a method for tracing the integrated source of language learning and practice results across multiple platforms. Background Technology

[0002] With the continuous development of digital education, online training, and formative assessment, the methods for recognizing learning outcomes are shifting from single-result recognition to recognition based on the entire learning process. Learning records not only relate to the continuous presentation of an individual's growth trajectory but also to the data foundation for teaching evaluation, competency certification, resource allocation, and education governance.

[0003] In existing technologies, learners often complete exercises, submit, query, share, and showcase their results across multiple platforms. The data structures, time stamping methods, and recording granularities vary across these platforms, resulting in the fragmented storage of the same learning behavior and making it difficult to merging and correlate them. While some systems have introduced distributed storage to improve capacity and availability, this largely remains at the level of scattered data storage, lacking unified identification, contextual correlation, and integrity checks for the entire learning behavior chain. In practical applications, there is also a conflict between sharing control and data verification. Sharing requires cropping fields, but the cropped data may not be able to support the identification and supplementary collection of missing segments, leading to incomplete learning trajectories, difficulty in verifying sources, and challenges in cross-platform result interoperability, thus affecting the reliable use and continuous accumulation of educational data. Summary of the Invention

[0004] To address the above issues, this application provides an integrated traceability method for language learning and practice outcomes across multiple platforms, which aims to at least solve the problem of how to balance credible association of learning records, controlled sharing, and complete reconstruction of learning trajectories in a heterogeneous multi-platform environment.

[0005] To achieve the above objectives, the technical solution adopted in this application is as follows: This application provides a multi-platform integrated method for tracing the source of language learning and practice outcomes, the method comprising: Acquire learning behavior data from multiple platforms, standardize and transform the data, write it into a unified event serial number, and generate a unified learning record. Write the user identifier, timestamp, record summary value, and previous record summary value into the unified learning record to generate a chained record sequence. The record summary value and previous record summary value are used to indicate the chained relationship between adjacent unified learning records. The chained record sequence is stored in the storage network, the sharing request is verified, and if the sharing request is verified, a restricted access copy and an integrity verification copy that retains the learning behavior fragment index are generated. Based on the integrity verification copy, a behavior fragment coverage check is performed, and if there are missing fragments, a supplementary collection is initiated to the source platform. A complete set of learning behaviors is generated based on the coverage check results and the supplementary collection results. The complete set of learning behaviors is integrated across platforms to generate a learning trajectory profile.

[0006] In one possible implementation, the unified learning record includes a unified event serial number, a source platform identifier, the time of occurrence of the learning behavior, and an index of the learning behavior segment.

[0007] In one possible implementation, multi-platform learning behavior data is standardized and written with a unified event serial number to generate a unified learning record. This includes: converting multi-platform learning behavior data into a unified field structure according to the data format corresponding to the source platform identifier; writing the same unified event serial number to the collection record, query record, sharing record, and integration record corresponding to the same learning behavior; and generating a unified learning record based on the unified field structure and the unified event serial number.

[0008] In one possible implementation, a user identifier, timestamp, record summary value, and previous record summary value are written to a unified learning record to generate a chained record sequence. This includes: sorting the unified learning records according to their timestamps; calculating the corresponding record summary value based on the sorted unified learning records; setting the previous record summary value to a preset null value for the first unified learning record; and writing the record summary value of the previous unified learning record to the previous record summary value for non-first unified learning records for non-first unified learning records to generate a chained record sequence.

[0009] In one possible implementation, the storage network is a distributed storage network, and storing the chained record sequence into the storage network includes: data fragmentation of the chained record sequence; sending the data fragments to multiple storage nodes through an encrypted transmission channel; performing format compatibility verification and integrity verification on the data fragments, and performing persistent storage if the verification passes.

[0010] In one possible implementation, the sharing request is verified, and if the sharing request passes verification, a restricted access copy and an integrity verification copy retaining the learning behavior fragment index are generated. This includes: obtaining the sharing request, which includes a request subject identifier, a target platform identifier, and an authorization scope; verifying the request subject identifier, target platform identifier, and authorization scope; filtering data fields in the chained record sequence according to the verified authorization scope to generate a restricted access copy; extracting the unified event serial number, user identifier, and source platform identifier from the unified learning record, and retaining the unified event serial number, user identifier, source platform identifier, timestamp, learning behavior fragment index, and record summary value to generate an integrity verification copy.

[0011] In one possible implementation, the request subject identifier, target platform identifier, and authorization scope are verified, including: if the request subject identifier matches the user identifier, verifying whether the target platform identifier corresponds to the authorization scope, and determining that the sharing request passes verification if the verification passes; if the request subject identifier does not match the user identifier, obtaining an authorization token, and verifying the authorized object, authorization scope, and validity period corresponding to the authorization token; and determining that the sharing request passes verification if the authorization token verification passes.

[0012] In one possible implementation, a behavior segment coverage check is performed based on the integrity verification copy, and supplementary collection is initiated to the source platform if missing segments exist. This includes: grouping records according to the unified event serial number and user identifier in the integrity verification copy, and generating an actual segment set based on the learning behavior segment index in the grouping result; determining the expected segment set based on the source platform identifier and timestamp in the grouping result; comparing the expected segment set with the actual segment set to determine the missing segments; sending a supplementary collection request to the source platform corresponding to the missing segments, and updating the actual segment set based on the returned supplementary learning behavior data.

[0013] In one possible implementation, a complete set of learning behaviors is generated based on the coverage check results and the supplementary collection results, including: if the updated actual fragment set does not cover the expected fragment set, the currently missing fragment is re-determined, and supplementary collection is initiated again to the source platform corresponding to the currently missing fragment; if the updated actual fragment set covers the expected fragment set, the updated actual fragment set is determined as the complete set of learning behaviors.

[0014] In one possible implementation, the complete set of learning behaviors is integrated across platforms to generate a learning trajectory profile, including: writing the complete set of learning behaviors into the target platform database according to field mapping rules; determining the learning progress status based on the timestamps and learning behavior order in the complete set of learning behaviors; and generating a learning trajectory profile based on the learning progress status.

[0015] Compared with existing technologies, the advantages and beneficial effects of this application are as follows: By standardizing and converting learning behavior data from multiple platforms and writing it into a unified event serial number, a unified expression of heterogeneous records and stable merging of the same learning behavior are achieved, reducing the problem of broken links caused by field differences between platforms and record dispersion.

[0016] By writing user identifiers, timestamps, record summary values, and previous record summary values ​​into the unified learning record, a chain-like association between adjacent records is achieved, enhancing the continuity, verifiability, and traceability of records.

[0017] By storing the chained record sequence in the storage network and generating restricted access copies and integrity verification copies simultaneously during the sharing phase, the separation of data sharing control and integrity checking is achieved, ensuring that the sharing scope is controlled while retaining the key fields required for subsequent verification.

[0018] By performing behavior fragment coverage checks based on integrity verification copies and initiating supplementary collection to the source platform, targeted completion of missing fragments and complete recovery of the learning behavior set were achieved.

[0019] By integrating the complete set of learning behaviors across platforms, a unified learning trajectory profile is generated and continuously updated, facilitating subsequent evaluation, certification, display, and auditing. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the method described in this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solution, the present application will be described in detail below with reference to the embodiments. The description in this section is only exemplary and explanatory, and should not be used to limit the scope of protection of the present application in any way.

[0022] As language learning and practice outcome management becomes increasingly process-oriented, collaborative, and continuous, single-platform data processing methods are no longer sufficient to meet the organizational needs of cross-task, cross-stage, and cross-subject learning behaviors. The technological value of multi-platform collaboration lies not only in enabling data exchange between different learning systems but also in establishing a unified organizational mechanism for the same learning behavior, allowing dispersed practice records, process records, and outcome records to be continuously identified, associated, and retrieved within the same technological framework. Distributed storage provides the foundation for the distributed storage and continuous preservation of massive amounts of learning records, but relying solely on storage layer expansion is insufficient to solve the problems of correspondence, sharing, and verification between cross-platform records. Therefore, it is necessary to construct an integrated traceability method for language learning and practice outcomes across multiple platforms, enabling unified recording, chain-like association, controlled sharing, integrity verification, and cross-platform integration of multi-source learning behaviors to form a continuously updated learning trajectory archive.

[0023] like Figure 1 As shown, a multi-platform integrated method for tracing the source of language learning and practice outcomes includes: Acquire learning behavior data from multiple platforms, standardize and transform the data, write it into a unified event serial number, and generate a unified learning record. In this embodiment, the multi-platform learning behavior data can come from oral practice platforms, writing training platforms, collaborative learning platforms, or results display platforms. The data structures returned by different platforms are typically inconsistent; some platforms use structured fields, while others use semi-structured logs. To ensure a unified input basis for subsequent chained record sequence generation and cross-platform integration processing, the multi-platform learning behavior data is first standardized and transformed, and a unified event serial number is written into the transformed records to form a unified learning record. The unified event serial number is used to identify the relationship between the same learning behavior during the collection, query, sharing, and integration processes. After the unified learning record is generated, it continues to be passed on as the data basis for subsequent user identifier writing, timestamp association, summary calculation, and integrity verification.

[0024] The unified learning record includes a unified event serial number, source platform identifier, time of occurrence of learning behavior, and index of learning behavior segments.

[0025] In one embodiment, the unified learning record is further limited to a fixed field structure, including at least a unified event serial number, a source platform identifier, the time of occurrence of the learning behavior, and an index of the learning behavior segment. This limitation is introduced because, although the original learning behavior data in a multi-platform environment are all used to describe the learning process, different platforms record the behavior time, segment number, and source information differently. If the basic fields are not unified during the record generation stage, it will be difficult to determine whether different records belong to the same learning behavior, and it will also be difficult to provide stable input for subsequent segment coverage checks.

[0026] In practical implementation, a unified learning record template can be pre-established in the standardized conversion service. The template includes a unified event serial number to identify the record chain corresponding to the same learning behavior, a source platform identifier to identify which learning platform the current record comes from, a learning behavior occurrence time to characterize the actual time the learning behavior occurred, and a learning behavior segment index to characterize the segment position of the current record within the complete learning behavior. The source platform identifier can be the platform code assigned during platform registration or the platform name field agreed upon in the platform interface configuration, as long as it remains unique and unchanged throughout the entire processing cycle. The learning behavior occurrence time can be uniformly converted to a standard time format under the same time base, such as a second-level or millisecond-level timestamp. The selection of time precision can be determined based on the platform's original return capabilities. When a platform only returns date and time period information, the date and time period start time can be converted together into the learning behavior occurrence time, and a time precision mark can be added inside the record to distinguish between precise and approximate times during subsequent processing.

[0027] The learning behavior fragment index can be numbered sequentially using natural numbers, or it can use a mapping between platform fragment numbers and unified sequence numbers. When using sequential numbering, the fragment index increments from the beginning; when using a mapping method, the mapping from platform fragment numbers to unified sequence numbers needs to be completed during the standardization and conversion stage.

[0028] After this processing, data output from different platforms can all fall into the same record template, providing clear data boundaries for subsequent processing of record summary values, preceding record summary values, and fragment coverage relationships. For raw data that does not contain source platform identifiers or fragment location information, the platform source can be added to the metadata of the access interface, and the learning behavior fragment index can be added according to the submission order of the raw data, page pagination order, or media segmentation order; if it is not possible to add the index, the corresponding record can be marked as a record to be verified, and its entry into the unified learning record writing process can be temporarily suspended. Through the above methods, each field in the unified learning record has a clear source, clear meaning, and clear purpose, which can not only support the record generation at this stage but also provide direct input for subsequent integrity verification.

[0029] Standardize and convert learning behavior data from multiple platforms and write it into a unified event serial number to generate a unified learning record. This includes: converting learning behavior data from multiple platforms into a unified field structure according to the data format corresponding to the source platform identifier; writing the same unified event serial number to the collection record, query record, sharing record, and integration record corresponding to the same learning behavior; and generating a unified learning record based on the unified field structure and the unified event serial number.

[0030] In one embodiment, the standardization conversion of multi-platform learning behavior data and the writing of unified event serial numbers are further limited to performing field mapping, record merging, and event number inheritance according to the data format corresponding to the source platform identifier. The reason for introducing this limitation is that the collection records, query records, shared records, and integrated records of the same learning behavior on different platforms are often generated by different business interfaces, and there are differences in field names, field order, and return structure. If only simple field copying is performed, it is impossible to guarantee the consistency of the association relationship between subsequent unified learning records.

[0031] In practical implementation, a mapping table between source platform identifiers and data formats can be maintained at the platform access layer. This mapping table should include at least the source platform identifier, original field name, unified field name, field type, time conversion rules, and fragment index generation rules. Upon receiving multi-platform learning behavior data, the standardization conversion service first locates the corresponding mapping table based on the source platform identifier, and then converts each original field into a unified field structure. The unified field structure can include event fields, platform fields, time fields, and fragment fields.

[0032] The event field stores the unified event serial number, the platform field stores the source platform identifier, the time field stores the time of occurrence of the converted learning behavior, and the fragment field stores the learning behavior fragment index. For collection records, query records, sharing records, and integration records corresponding to the same learning behavior, the unified event serial number is not generated separately, but rather generated by the first collection record and inherited by subsequent records. That is, when the system first receives a collection record for a certain learning behavior, the event numbering service generates a unique unified event serial number for that collection record; when subsequent query records, sharing records, or integration records associated with that collection record appear, these records inherit the same unified event serial number from the association relationship. The association relationship can be determined based on the business association identifier returned by the platform, the request context in the processing chain, or the record index written previously. If the business interface can return an association identifier, it is directly used for association; if the business interface does not return an association identifier, a combination of the source platform identifier, the time of occurrence of the learning behavior, and the learning behavior fragment index can be used as the matching basis, and merging can be performed within the set time tolerance range.

[0033] The time tolerance range can be determined based on the platform's recording accuracy. For example, a tolerance range not exceeding one collection cycle can be used for second-level time, while a smaller tolerance range can be used for millisecond-level time. After the unified event serial number is written, the conversion service outputs unified learning records based on the unified field structure and unified event serial number, and writes the output results to the record cache or directly submits them to the subsequent chained record sequence generation service. For cases where fields are missing, field types do not match, or the unified event serial number cannot be inherited, the reason for the exception can be recorded and entered into the manual verification queue, or it can be rolled back to an independent record to be confirmed according to preset rules to avoid erroneous merging of different learning behaviors. Through the above implementation method, the generation process of unified learning records has a clear input source, a clear conversion basis, and clear association rules, which can ensure that records generated by the same learning behavior in different business links are stably merged into the same event chain, establishing a reliable foundation for subsequent summary writing and fragment completion.

[0034] Write the user identifier, timestamp, record summary value, and previous record summary value into the unified learning record to generate a chained record sequence. The record summary value and previous record summary value are used to indicate the chained relationship between adjacent unified learning records. In this embodiment, after a unified learning record is generated, user identifiers, timestamps, record summary values, and previous record summary values ​​are written to the unified learning record to form a chained record sequence. The user identifier identifies the learner corresponding to the current learning record, and the timestamp identifies the chained timestamp corresponding to the current learning record. The chained timestamp is generated based on the time the learning behavior occurred and is used for unified learning record sorting and subsequent segment coverage checks. The record summary value characterizes the content features of the current learning record, and the previous record summary value characterizes the link relationship between the current learning record and the previous learning record. When generating the chained record sequence, the unified learning record is used as the basic processing unit. The unified learning records corresponding to the same user are arranged in chronological order, and then summary association information is written one by one according to the arrangement result. After the chained record sequence is generated, it can serve as the basic sequence for subsequent storage in the storage network and for performing shared verification.

[0035] Write user identifier, timestamp, record summary value, and previous record summary value to a unified learning record to generate a chained record sequence. This includes: sorting the unified learning records according to their timestamps; calculating the corresponding record summary value based on the sorted unified learning records; setting the previous record summary value to a preset null value for the first unified learning record; and writing the record summary value of the previous unified learning record to the previous record summary value for non-first unified learning records to generate a chained record sequence.

[0036] In one embodiment, the generation of the chained record sequence is further limited to sorting by timestamp, calculating the record summary value for each record, and writing the summary values ​​of the preceding records of the first and non-first records respectively. The reason for introducing this limitation is that although the unified learning records already have a unified field structure and a unified event serial number, without a stable sequential order and rules for association, subsequent writing to the storage network will still only result in discrete records, and a verifiable record chain cannot be formed.

[0037] In practice, learning records can be first grouped by user identifier, ensuring that records for the same user enter the same processing queue. Then, within each processing queue, records are sorted in ascending order based on timestamps to obtain a record sequence table by user dimension. Timestamps can directly use the time the learning activity occurred, or a chained timestamp can be generated by overlaying processing batch information on the learning activity's occurrence time, as long as a consistent rule is maintained within the same processing queue. If two learning records have the same timestamp, a unified event serial number can be used as a secondary sorting criterion to ensure the sorting result is unique.

[0038] After sorting, a record summary value is calculated for each unified learning record in the record sequence table. The input for the record summary value can include the unified event serial number, source platform identifier, learning behavior occurrence time, learning behavior segment index, and user identifier. It can also further include core behavior content fields after standardization. During summary generation, common summarization algorithms can be called to obtain a fixed-length summary result. The summary result can be saved as a string or a byte sequence, as long as the subsequent chained verification stage uses the same encoding rules. For the first unified learning record in the record sequence table, if there is no preceding record, the preceding record summary value can be set to a preset null value. The preset null value can be an empty string, a fixed zero value, or a system-preset initial identifier. Using a fixed zero value or a system-preset initial identifier avoids inconsistencies in how different storage components handle null values. For non-first unified learning records in the record sequence table, the already generated record summary value is read from the previous unified learning record and written into the preceding record summary value field of the current unified learning record.

[0039] Once a unified learning record is written, it establishes a sequential connection with the previous unified learning record. Traversing the entire record sequence list in this manner generates a chained record sequence. After generation, a sequence check can be performed on the chained record sequence to check if the preceding record summary value of each non-first record matches the record summary value of the previous record. If an inconsistency exists, the sorting result can be reread and the preceding record summary value rewritten. If an inconsistency persists after two consecutive rereads, the corresponding record is marked as a chained record to be checked and temporarily not sent to the subsequent storage network. After this processing, each record in the chained record sequence has a clearly defined owner, a clearly defined write time, a clearly defined content summary, and a clearly defined preceding and following source, ensuring the chained connection between adjacent records and providing direct input for subsequent integrity checks and shared copy generation.

[0040] The chained record sequence is stored in the storage network, the sharing request is verified, and if the sharing request is verified, a restricted access copy and an integrity verification copy that retains the learning behavior fragment index are generated. In this embodiment, after the chained record sequence is generated, it enters the storage and sharing processing stage. This stage takes the chained record sequence as input, writing it into the storage network to form a persistently stored record set. Simultaneously, it receives sharing requests, verifies them, and generates a restricted access copy and an integrity verification copy upon successful verification. The restricted access copy provides data within the authorized scope to external requesters, while the integrity verification copy retains the basic fields required for subsequent behavior fragment coverage checks. After the integrity verification copy is generated, it continues to serve as input for subsequent missing fragment identification and supplementary data collection. With this processing, the chained record sequence can enter both the long-term storage path and the controlled sharing and integrity verification path, establishing a clear data connection between storage and sharing processes.

[0041] The storage network is a distributed storage network that stores a chained record sequence into the storage network. This includes: data fragmentation of the chained record sequence; sending the data fragments to multiple storage nodes through an encrypted transmission channel; performing format compatibility and integrity checks on the data fragments; and performing persistent storage if the checks pass.

[0042] In one embodiment, the storage network is further defined as a distributed storage network, and the writing process of the chained record sequence is defined as data sharding, node sending, format compatibility verification, integrity verification, and persistent storage. This limitation is introduced because chained record sequences often contain learning records from multiple platforms, various behaviors, and multiple time points. When faced with a continuously growing record scale, a single storage node is prone to storage capacity limitations, access congestion, or partial failures affecting overall availability.

[0043] By employing a distributed storage network, a chained record sequence can be split and written to multiple storage nodes, providing clearer division of labor and a more stable foundation for subsequent access during record saving. In practice, records can be segmented based on a unified event serial number, user identifier, or time interval within the chained record sequence, generating multiple data shards. Data sharding can use either a fixed number of records or a fixed data volume. Fixed number of records is suitable for scenarios with relatively stable record fields, while fixed data volume is suitable for scenarios with significant differences in record content size. Each data shard retains a complete record, without disassembling the fields within a single record, thus avoiding the need to reassemble individual records during subsequent readings.

[0044] After data shards are generated, the storage scheduling service selects a target storage node for each data shard based on node load, available node capacity, and node network connectivity. The data shards are then sent to the corresponding storage nodes via an encrypted transmission channel. This encrypted transmission channel can employ common secure transmission protocols in the field, as long as they ensure that the shards are not exposed in plaintext during transmission.

[0045] After receiving data fragments, the storage node does not write them directly to disk. Instead, it first performs a format compatibility check. This check verifies whether the field arrangement, field encoding, time format, and index format in the data fragments are consistent with the data formats supported by the current node. If inconsistencies are found, the access node can perform a local conversion to change the field encoding and index format to the storage format supported by the current node before proceeding to the subsequent verification process.

[0046] After format compatibility verification passes, integrity verification is performed. Integrity verification can check the order of records in the data shard by comparing the record digest values ​​with the previous record digest values, or it can check the number of records within the shard, field integrity, and index continuity. If there are missing digest values, missing fields, or broken chain sequences, persistent writing is not performed; instead, the data shard is returned to the retransmission queue or marked as a shard to be corrected. Data shards that pass verification are written to the corresponding storage nodes, and a shard storage index is generated.

[0047] The sharded storage index includes at least a unified event serial number range, a user identifier range, a time range, and a node location. This index is used both for subsequent shared request reading of the chained record sequence and for quickly locating existing records during subsequent supplementary collection phases. For the same chained record sequence, backup shards can also be generated on different storage nodes according to a preset number of replicas. The number of replicas can be determined based on availability requirements and storage resource conditions; a higher number of replicas can be used when data security is prioritized, and a lower number of replicas can be used when storage cost is prioritized. Through the above processing, the chained record sequence can be stably written in a distributed manner, providing a locationable, verifiable, and readable storage foundation for the generation of subsequent shared replicas.

[0048] The process involves verifying the sharing request and, if the sharing request passes verification, generating a restricted access copy and an integrity verification copy that retains the learning behavior fragment index. This includes: obtaining the sharing request, which includes the request subject identifier, target platform identifier, and authorization scope; verifying the request subject identifier, target platform identifier, and authorization scope; filtering the data fields in the chained record sequence based on the verified authorization scope to generate a restricted access copy; and extracting the unified event serial number, user identifier, and source platform identifier from the unified learning record, while retaining the unified event serial number, user identifier, source platform identifier, timestamp, learning behavior fragment index, and record summary value to generate an integrity verification copy.

[0049] In one embodiment, the sharing request verification and copy generation are further restricted to performing access verification based on the request subject identifier, target platform identifier, and authorized scope, and generating restricted access copies and integrity verification copies based on the verification results. This restriction is introduced because the chained record sequence contains not only learning outcome-related content but also chained association fields, platform source fields, and fragment index fields. Directly outputting the original chained record sequence during the sharing phase could easily exceed the sharing scope and expose verification fields that are not needed by all requesters.

[0050] By employing a dual-copy processing approach, data content intended for sharing can be separated from data content intended for verification. This ensures that both the sharing action and subsequent integrity checks obtain their respective data sets at the same stage. Specifically, the system first receives a sharing request and parses the requesting entity identifier, target platform identifier, and authorization scope from it. The requesting entity identifier identifies the entity initiating the sharing request, the target platform identifier identifies the platform to which the shared data will be sent, and the authorization scope limits the data fields that can be output and the range of records that can be read.

[0051] After parsing, the access control service performs verification on the three objects mentioned above. Before successful verification, shared content in the chained record sequence is not read. After successful verification, the system filters the data fields in the chained record sequence according to the authorized scope, generating a restricted access copy. The authorized scope can be limited to a field-level scope or a record-level scope. Field-level scopes are suitable for scenarios where sharing of some content fields is allowed but not all content fields is not permitted, while record-level scopes are suitable for scenarios where the sharing scope is controlled by time period, learning task, or platform source.

[0052] When filtering fields, you can retain fields such as the learning activity's occurrence time, platform source information, and necessary outcome content. Alternatively, you can delete extended fields outside the authorized scope, internal validation fields, or management fields used only by the system. The resulting restricted access copy is for external sharing and does not serve for integrity verification. Correspondingly, the system extracts the unified event serial number, user identifier, and source platform identifier from the unified learning record, and retains these elements, along with the timestamp, learning activity fragment index, and record summary value, to generate an integrity-verified copy.

[0053] The integrity verification copy does not aim for complete shared content, but rather for coverage checks and chained verification to proceed. The source platform identifier identifies the platform from which the fragment originates, the timestamp identifies the time position of the fragment, the learning behavior fragment index identifies the fragment's sequential position within the complete learning behavior, and the record summary value identifies the content features of the current record. This copy may not retain all result content fields, only the key fields needed for subsequent missing fragment identification, thus avoiding shared pruning affecting the continued execution of integrity verification.

[0054] After the restricted access copy and integrity verification copy are generated, they can be written to different copy buffers. The restricted access copy is sent to the target platform or shared interface, while the integrity verification copy is sent to the coverage check service. This process creates a clear dual-path output structure in the sharing phase, which satisfies data access control requirements and retains the necessary verification basis for the next phase of fragment coverage check.

[0055] The request subject identifier, target platform identifier, and authorization scope are verified, including: if the request subject identifier and user identifier are consistent, verifying whether the target platform identifier corresponds to the authorization scope, and determining that the sharing request passes verification if the verification passes; if the request subject identifier and user identifier are inconsistent, obtaining an authorization token, and verifying the authorized object, authorization scope, and validity period corresponding to the authorization token; if the authorization token verification passes, determining that the sharing request passes verification.

[0056] In one embodiment, the verification process for the requesting subject identifier, target platform identifier, and authorization scope is further limited to an identity consistency verification branch and an authorization token verification branch. This limitation is introduced because, in practical applications, sharing requests may be initiated by the learner themselves, or by a platform authorized by the learner, a teacher's management terminal, or an authentication platform. If these two scenarios are not distinguished and a single verification rule is used uniformly, it is easy to encounter problems such as overly complex access procedures for the learner or insufficient constraints on access procedures for third parties.

[0057] In practice, the access control service first compares the request subject identifier with the user identifier. The user identifier comes from the unified learning record corresponding to the chained record sequence and is used to identify the learner to whom the current record belongs. When the request subject identifier matches the user identifier, the system recognizes the current sharing request as a personal access request. For personal access requests, an authorization token is not required; instead, the system further verifies whether the target platform identifier corresponds to the authorization scope. This correspondence means that the scope of shareable data declared in the authorization scope must allow data output to the platform indicated by the current target platform identifier. For example, if the authorization scope is limited to sending only to personal achievement platforms, the target platform identifier must belong to the set of personal achievement platforms; if the authorization scope is limited to sending only to authentication platforms, the target platform identifier must belong to the set of authentication platforms.

[0058] The mapping relationship can be verified using a platform identifier-authorization scope mapping table. The mapping table must include at least the authorization scope category, the set of allowed platform identifiers, and the set of restricted data fields. Once the mapping table verification is successful, the sharing request is considered valid. When the request subject identifier does not match the user identifier, the system identifies the current sharing request as a third-party access request. For third-party access requests, the access control service obtains an authorization token and verifies it. The authorization token must include at least the authorization object, the authorization scope, and the validity period. The authorization object identifies the authorized request subject, the authorization scope limits the range of data the authorized subject can access, and the validity period limits the duration of the authorization.

[0059] During verification, the system checks whether the authorized object matches the request subject identifier, whether the authorized scope covers the access scope corresponding to the current target platform identifier, and whether the current request time falls within the validity period. If any condition is not met, the sharing request fails verification and a rejection result is returned. If all conditions are met, the sharing request is deemed to have passed verification. To ensure the traceability of the verification process, the verification result, failure reason, and access type corresponding to the target platform identifier can be recorded after verification. Verification failure records can be used for subsequent auditing, and verification success records can be used for subsequent sharing confirmation. Through the above dual-branch verification method, the sharing request can maintain a relatively direct processing path in the scenario of personal access, and can also establish a clear authorization constraint relationship in the scenario of third-party access, thus making the generation of shared copies based on a clear, stable, and verifiable verification foundation.

[0060] Based on the integrity verification copy, a behavior fragment coverage check is performed, and if there are missing fragments, a supplementary collection is initiated to the source platform. A complete set of learning behaviors is generated based on the coverage check results and the supplementary collection results. In this embodiment, after the integrity verification copy is generated, the process enters the behavior fragment coverage check and supplementary collection stage. This stage uses the integrity verification copy as input, parsing the source platform identifier, timestamp, learning behavior fragment index, and record summary value retained therein to determine if the current learning behavior has missing fragments, out-of-order fragments, or fragments that have not been fully merged. If missing fragments exist, supplementary collection is initiated from the corresponding source platform, and the returned supplementary learning behavior data is merged into the existing record set to obtain an updated fragment set. The coverage check result and the supplementary collection result are used together to determine the complete learning behavior set. After the complete learning behavior set is generated, the process continues into the cross-platform integration stage.

[0061] The system performs behavior segment coverage checks based on the integrity verification copy and initiates supplementary collection to the source platform if missing segments exist. This includes: grouping records according to the unified event serial number and user identifier in the integrity verification copy, and generating an actual segment set based on the learning behavior segment index in the grouping results; determining the expected segment set based on the source platform identifier and timestamp in the grouping results; comparing the expected segment set with the actual segment set to determine the missing segments; sending a supplementary collection request to the source platform corresponding to the missing segments, and updating the actual segment set based on the returned supplementary learning behavior data.

[0062] In one embodiment, the behavior fragment coverage check is further limited to constructing an actual fragment set based on the learned behavior fragment index, determining the expected fragment set based on the source platform identifier and timestamp, and then identifying missing fragments through set comparison. The reason for introducing this limitation is that although the integrity verification copy has already retained the key fields required for the behavior fragment coverage check, if the scattered fields are not first organized into a comparable fragment set, the system cannot determine whether the current learning behavior has been completely collected or only partially written.

[0063] In practice, the coverage inspection service first reads the unified event serial number, user identifier, and learning behavior fragment index from the integrity verification copy, and then groups the records according to the unified event serial number and user identifier. Each group of records represents a learning behavior to be inspected. After grouping, all learning behavior fragment indices within the group are written into the actual fragment set in index order. The actual fragment set represents the range of fragments currently mastered by the system. Each fragment entry in the set includes at least a fragment sequence number, a source platform identifier, a timestamp, and a record summary value. The fragment sequence number identifies the position of the current fragment within the complete learning behavior, the source platform identifier identifies the learning platform from which the current fragment originates, the timestamp identifies the corresponding time position of the current fragment, and the record summary value identifies the summary characteristics of the current fragment's record content.

[0064] After the actual segment set is generated, the coverage check service determines the expected segment set based on the source platform identifier and timestamp. The expected segment set represents the theoretically all segment range that should exist within the current learning cycle. The expected segment set can be determined in two ways. One way is based on the source platform's original segment planning rules. For example, a speaking practice platform might divide a learning task into a fixed number of audio segments, while a writing training platform might divide a writing process into draft segments, revision segments, and submission segments. The system can pre-save the platform's segment planning rules and directly obtain the number and order of segments that the current learning activity should include based on the source platform identifier. The other way is to infer the expected segment range based on the timestamp and the distribution of received segments. For example, if the same learning activity should generate several sequential segments within a consecutive time period, and the current segment time distribution shows a significant gap, then the positions corresponding to the gaps are included in the expected segment set. Both methods can be used individually or in combination.

[0065] Once the expected fragment set is determined, the coverage check service compares the expected fragment set with the actual fragment set item by item. The comparison includes at least the existence of fragment numbers, the continuity of fragment order, the consistency of source platforms, and the matchability of summary records. The comparison results may fall into several categories: one is that all fragments in the expected fragment set exist in the actual fragment set, indicating that the current learning behavior fragments are complete; another is that some fragment numbers are missing, indicating missing fragments; and a third is that fragment numbers exist but the source platforms are inconsistent or the summary records are abnormal, indicating a possible mismatch in fragment records. These types of fragments can be treated as missing fragments for later re-collection and coverage.

[0066] Once the missing segments are identified, the coverage check service generates a supplementary collection task for each missing segment. Each supplementary collection task includes at least a unified event serial number, user identifier, missing segment sequence number, corresponding source platform identifier, and current check time. After the supplementary collection task is sent to the corresponding source platform, the source platform returns supplementary learning behavior data. This returned supplementary learning behavior data is then checked for fields and corrected for indexes before being incorporated into the actual segment set, forming an updated actual segment set. This process further organizes the basic fields in the integrity verification copy into a set of segments with comparative capabilities, allowing the coverage check service to clearly distinguish between existing and missing segments and providing explicit input for subsequent supplementary collection. If the source platform does not return data, returns data in an incorrect format, or returns a segment index inconsistent with the current missing segment, the corresponding supplementary collection task can be marked as a failed task, and the reason for failure can be retained for use in the next round of collection.

[0067] Based on the coverage check results and supplementary collection results, a complete set of learning behaviors is generated, including: if the updated actual fragment set does not cover the expected fragment set, the currently missing fragment is re-identified, and supplementary collection is initiated again to the source platform corresponding to the currently missing fragment; if the updated actual fragment set covers the expected fragment set, the updated actual fragment set is identified as the complete set of learning behaviors.

[0068] In one embodiment, the generation of the complete learning behavior set is further limited by repeatedly performing coverage checks based on the updated actual fragment set. If the desired fragment set is not covered, the currently missing fragments are determined and supplementary collection is initiated again. When the desired fragment set is covered, the supplementary process for the current learning behavior ends. The reason for introducing this limitation is that the supplementary return from the source platform may not be able to fill in all missing fragments in a single collection. Some platforms may only return partial fragments, and some fragments may be temporarily unavailable due to network anomalies, interface rate limiting, or delayed writing of the original records. If only one supplementary collection is performed, the determination of the complete learning behavior set may remain in an incomplete state.

[0069] In practice, after obtaining the updated actual fragment set, the coverage check service does not directly output the complete set of learning behaviors. Instead, it performs a coverage check again between the updated actual fragment set and the expected fragment set. The core of the coverage check is to check whether the updated actual fragment set contains all fragment entries in the expected fragment set. During the check, it not only checks whether all fragment numbers appear, but also whether the source platform identifier of each fragment entry matches the expected source platform, and whether the fragment order meets the predetermined order. The expected fragment set is considered not covered if any of the following conditions exist: 1) fragment numbers are still missing; 2) although the number of fragment entries is sufficient, the source platform identifier corresponding to a certain fragment is incorrect; 3) a fragment entry exists, but its record summary value is empty or it is marked as an abnormal record. For cases of non-coverage, the system redetermines the currently missing fragments. The currently missing fragments are not limited to those obtained from the initial check, but also include newly identified mismatched fragments and invalid fragments after supplementation.

[0070] Once the missing segment is identified, the system initiates another round of supplementary data collection from the corresponding source platform. During this second round, the reason for the previous failure, the range of successfully completed segments, and the sequence number of the currently missing segment can be written into the collection task. This ensures the source platform only returns the remaining missing portion, reducing redundant transmissions. For the returned supplementary learning behavior data, the system repeatedly performs field checks, index corrections, segment merging, and coverage checks. To avoid infinite loops, upper limits can be set for the number of supplementary collection rounds and single-segment retry limits. The upper limit for the number of supplementary collection rounds restricts the overall number of times the same learning behavior can be supplemented, while the single-segment retry limit restricts the number of repeated requests for the same segment. These limits can be set based on the source platform's response capabilities, the importance of the learning behavior, and the system's processing time. If the expected segment set is not covered even after reaching the upper limit, the current learning behavior is marked as a learning behavior to be supplemented, and the current actual segment set and missing segment list are retained for subsequent scheduled supplementary data collection or manual processing.

[0071] When the updated actual fragment set covers the expected fragment set, the system determines the updated actual fragment set as the complete learning behavior set. The complete learning behavior set includes at least all fragment entries, the source platform identifier for each fragment, a timestamp, fragment sequence number, and the merged record content. After the complete learning behavior set is generated, it can be written to the integration buffer with an attached integrity status flag, indicating that the current learning behavior has completed fragment completion and coverage confirmation. This process ensures that the formation of the complete learning behavior set is not a one-time static judgment result, but a closed-loop process based on coverage checks, supplementary data collection, re-checks, and final confirmation. This approach adapts to the reality of inconsistent data returns from multiple platforms and ensures that the data entering the subsequent cross-platform integration stage has a clear integrity foundation.

[0072] The complete set of learning behaviors is integrated across platforms to generate a learning trajectory profile.

[0073] In this embodiment, after the complete set of learning behaviors is generated, the cross-platform integration process begins. This stage takes the complete set of learning behaviors as input, writes the learning behavior segments that have been covered and confirmed into the target platform database, reconstructs the learning process based on timestamps and the order of learning behaviors, and then determines the learning progress status based on the reconstruction results. The learning progress status indicates whether the current learning behavior is in the start, ongoing, or completed stage. The target platform database is used to centrally store the cross-platform integrated learning records. After the learning progress status is determined, a learning trajectory file is generated by combining the corresponding behavior time, segment order, and platform source information. The learning trajectory file serves as the unified output for subsequent display, sharing, and auditing.

[0074] The complete set of learning behaviors is integrated across platforms to generate a learning trajectory profile, including: writing the complete set of learning behaviors into the target platform database according to field mapping rules; determining the learning progress status based on the timestamps and learning behavior order in the complete set of learning behaviors; and generating a learning trajectory profile based on the learning progress status.

[0075] In one embodiment, the process of cross-platform integration of a complete set of learning behaviors is further defined as field mapping and writing, sequential merging, status determination, and file generation. This limitation is introduced because although the complete set of learning behaviors already possesses fragmentary integrity, each record still retains the field expression habits of different source platforms. Without unified mapping and sequential merging, the record structure in the target platform database will be inconsistent, and the learning progress status will be difficult to determine stably. Specifically, an integration processing service can be set up outside the target platform database. This service pre-maintains field mapping rules, which define the correspondence between source platform fields and target platform database fields. The field mapping rules include at least the source platform field name, target field name, field type, time format conversion rules, and fragment order inheritance rules.

[0076] Upon receiving the complete set of learning behaviors, the integration and processing service reads the corresponding field mapping rules based on the source platform identifier, converting each fragment record in the complete set of learning behaviors into a unified record structure acceptable to the target platform's database. The unified record structure may include a user identifier, a unified event serial number, a source platform identifier, the time the learning behavior occurred, the learning behavior fragment index, the record content, and a record summary value. When writing records to the target platform's database, they can be grouped by the unified event serial number, ensuring that all fragments corresponding to the same learning behavior enter the same file writing transaction.

[0077] After the data is written, the integration processing service determines the learning progress status based on the timestamps and the order of learning behaviors in the complete set of learning behaviors. The timestamps identify the order in which each segment enters the integration process, and the order of learning behaviors identifies the sequence of segments within the same learning behavior. The learning progress status can be determined based on the segment coverage and key behavior nodes. For example, if the complete set of learning behaviors only contains the starting segment and not the submitted segment, it can be determined as being in progress; if the complete set of learning behaviors already contains the last segment or a preset completion marker, it can be determined as being completed; if the complete set of learning behaviors has been written to the target platform's database but no valid behavior segments have yet appeared, it can be determined as being in the initialization state. The preset completion marker can be set according to the business rules of the source platform; for example, a spoken language practice platform returns a practice completion marker, and a writing training platform returns a submission success marker.

[0078] Once the learning progress status is determined, the integrated processing service generates a learning trajectory profile using a unified event serial number as an index. The learning trajectory profile can include user identifier, behavior start time, behavior end time, platform source distribution, segment order list, current learning progress status, and summary association information. The behavior start time can be the earliest occurrence time of the same learning behavior, the behavior end time can be the latest occurrence time, the platform source distribution can be obtained statistically based on the source platform identifier, and the segment order list can be generated in ascending order by the learning behavior segment index.

[0079] Once the learning trajectory file is generated, it can be written to the file table or sent to the file service interface. If there are issues such as field mapping failures, time sequence conflicts, or undetermined learning progress status, the corresponding learning behavior can be marked as a file awaiting correction, retaining the conflicting fields, conflict times, and reasons for the lack of determination for subsequent correction processing. This process transforms the complete set of learning behaviors into a structured, ordered, and clearly defined learning trajectory file, enabling the cross-platform learning process to form a readable, verifiable, and continuously updatable unified record in the target platform's database.

[0080] It should be noted that, in this document, the terms "comprising," "including," and any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Specific examples have been used in this document to illustrate the principles and implementation methods of the technical solutions of this application. The above examples are only for the purpose of helping to understand the methods and core ideas of this application. The above descriptions are merely preferred embodiments of this application. It should be pointed out that, due to the limitations of written expression and the objective existence of infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this application, and can also combine the above technical features in an appropriate manner; these improvements, modifications, changes, or combinations, or the direct application of the concept and technical solutions of this application to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A multi-platform integrated method for tracing the source of language learning and practice achievements, characterized in that, The method includes: Acquire learning behavior data from multiple platforms, standardize and convert the multi-platform learning behavior data, write a unified event serial number, and generate a unified learning record; Write a user identifier, timestamp, record summary value, and previous record summary value into the unified learning record to generate a chained record sequence, wherein the record summary value and the previous record summary value are used to indicate the chained association relationship between adjacent unified learning records; The chained record sequence is stored in the storage network, the sharing request is verified, and if the sharing request is verified, a restricted access copy and an integrity verification copy that retains the learning behavior fragment index are generated. Based on the integrity verification copy, a behavior fragment coverage check is performed, and if there are missing fragments, a supplementary collection is initiated to the source platform. A complete set of learning behaviors is generated based on the coverage check results and the supplementary collection results. The complete set of learning behaviors is integrated across platforms to generate a learning trajectory profile.

2. The method according to claim 1, characterized in that, The unified learning record includes the unified event serial number, the source platform identifier, the time of occurrence of the learning behavior, and the index of the learning behavior segment.

3. The method according to claim 2, characterized in that, The process of standardizing and converting the multi-platform learning behavior data and writing it into a unified event serial number to generate a unified learning record includes: The multi-platform learning behavior data is converted into a unified field structure according to the data format corresponding to the source platform identifier; The same unified event serial number is written to the collection record, query record, sharing record and integration record corresponding to the same learning behavior; The unified learning record is generated based on the unified field structure and the unified event serial number.

4. The method according to claim 1, characterized in that, The step of writing user identifier, timestamp, record summary value, and previous record summary value into the unified learning record to generate a chained record sequence includes: The unified learning records are sorted according to the timestamps. Calculate the corresponding record summary value based on the sorted unified learning records; For the first unified learning record, set the previous record summary value to a preset null value; For a non-first unified learning record, the record summary value of the previous unified learning record is written into the preceding record summary value of the non-first unified learning record to generate the chained record sequence.

5. The method according to claim 1, characterized in that, The storage network is a distributed storage network, and storing the chained record sequence into the storage network includes: The chained record sequence is fragmented into data segments; The data fragments are sent to multiple storage nodes via an encrypted transmission channel; The data fragments are subjected to format compatibility and integrity checks, and persistent storage is performed if the checks pass.

6. The method according to claim 1, characterized in that, The step of verifying the sharing request and generating a restricted access copy and an integrity verification copy that preserves the learning behavior fragment index, if the sharing request passes verification, includes: The sharing request is obtained, and the sharing request includes the requesting entity identifier, the target platform identifier, and the authorization scope; The requesting entity identifier, the target platform identifier, and the scope of authorization are verified. Based on the verified authorization scope, the data fields in the chained record sequence are filtered to generate the restricted access copy; Extract the unified event serial number, the user identifier, and the source platform identifier from the unified learning record, and retain the unified event serial number, the user identifier, the source platform identifier, the timestamp, the learning behavior fragment index, and the record summary value to generate the integrity verification copy.

7. The method according to claim 6, characterized in that, The verification of the requesting entity identifier, the target platform identifier, and the scope of authorization includes: If the request subject identifier matches the user identifier, verify whether the target platform identifier corresponds to the authorization scope, and if the verification passes, determine that the sharing request has passed the verification. If the request subject identifier does not match the user identifier, obtain an authorization token and verify the authorized object, the authorization scope, and the validity period corresponding to the authorization token; If the authorization token verification passes, the sharing request is determined to be verified.

8. The method according to claim 6, characterized in that, The step of performing behavior fragment coverage checks based on the integrity verification copy, and initiating supplementary collection to the source platform if missing fragments exist, includes: The records are grouped according to the unified event serial number and the user identifier in the integrity verification copy, and an actual fragment set is generated according to the learning behavior fragment index in the grouping result. The desired fragment set is determined based on the source platform identifier and the timestamp in the grouping results; The expected set of segments is compared with the actual set of segments to determine the missing segments; A supplementary collection request is sent to the source platform corresponding to the missing segment, and the actual segment set is updated based on the returned supplementary learning behavior data.

9. The method according to claim 8, characterized in that, The process of generating a complete set of learning behaviors based on the coverage check results and supplementary data collection results includes: If the updated set of actual fragments does not cover the set of expected fragments, the current missing fragment is re-determined, and supplementary collection is initiated again to the source platform corresponding to the current missing fragment; If the updated set of actual segments covers the set of expected segments, the updated set of actual segments is determined as the complete set of learning behaviors.

10. The method according to claim 1, characterized in that, The cross-platform integration of the complete set of learning behaviors to generate a learning trajectory profile includes: Write the complete set of learning behaviors into the target platform database according to the field mapping rules; The learning progress status is determined based on the timestamps and the order of learning behaviors in the complete set of learning behaviors. The learning trajectory file is generated based on the learning progress status.

Images