ModAstera

What is ModAstera?

ModAstera is an AI development platform provided by ModAstera Inc., designed for use in medical, manufacturing, and other regulated workflows. Its core product, MAEA, integrates data preparation, annotation, training, evaluation, governance, and deployment into a single, traceable process.

It is not a chat tool designed for ordinary users, nor is it a shortcut to obtaining approval for medical devices. The value of this platform lies in reducing the gaps between data collection, experimentation, validation of evidence, and the handover of products; however, the ultimate uses, clinical validation, and regulatory responsibilities remain with the organizations that use it.

Main functions

• Data preparation: Import medical imaging, industrial inspection images, sensor data streams, expert notes, and existing labels, and organize the metadata as well as the dataset hierarchy. Before training, it is still necessary to check for authorization, de-identification, completeness, and biases.
• AI-assisted annotation: Preliminary masks, detection boxes, classifications, or key points are generated based on a small number of examples, after which experts focus on correcting the boundaries and those difficult cases. This approach helps reduce the amount of repetitive annotation work, but it cannot replace professional review.
• Active learning: Prioritize the cases where the model is most uncertain for expert review, so that the limited time available for labeling is focused on samples with more valuable information. The rules used for selection can affect the distribution of samples, and it is necessary to record each strategy employed in each round.
• Review and versioning: Save information on the person who made the annotations, the date, the changes made, the reasons for those changes, the version of the dataset, as well as the history of reviews, in order to create a record that can be used for subsequent training and auditing.
• Natural language pipeline: Researchers can describe the prediction objectives and metrics, while MAEA assists with setting up experiments, processing data, and searching for models. The generated configurations must be reviewed by technical staff.
• Automatic model search: Train models among candidates such as CNN, Vision Transformer, or custom backbones, compare hyperparameters, and utilize GPUs for parallel experiments.
• Reproducible training: It allows for the saving of data snapshots, code or configuration settings, dependencies, parameters, metrics, and model outputs, which facilitates version comparison and rollback.
• Verification and subgroup inspection: Monitor overall metrics, subgroup performance, deviations, drift patterns, and known limitations, to avoid relying solely on accuracy.
• Model cards and evidence packages: These combine the data lineage, experiments, validations, deployment environment, audit logs, and model cards to form materials that can be transferred. Evidence packages assist in reviews, but they do not automatically prove compliance with regulations.
• One-click deployment: Publishes the validated model to a controlled endpoint, while preserving the API context, environment controls, and deployment records. For actual production use, security reviews, monitoring, rollback mechanisms, and designated responsible persons are still required.
• Edge, Cloud, and Federated Training: The page lists the options for edge or cloud deployment as well as federated training, which is suitable for projects where it is not appropriate to transfer data in a centralized manner. The specific architectures, supported environments, and packages need to be confirmed during a demonstration.
• Model monitoring: Tracks input quality, output distribution, latency, errors, workflow results, and human feedback, and connects drift signals to decisions regarding review and retraining.
• Manufacturing workflow: Utilize inspection images, process signals, and reliability data to establish processes for defect detection, quality control, and production deployment.
• Hebra’s professional products: built on MAEA, they provide branded patient entry points, structured data collection, and preparation for consultations for independent specialty clinics; it is not a general-purpose EHR, a telemedicine platform, or a doctor marketplace.

Support for data and tasks

The process from data to deployment

1. Define the intended use, users, operating environment, consequences of errors, success metrics, and matters that cannot be determined by the model.
2. Confirm data rights, privacy foundations, de-identification methods, inclusion/exclusion rules, and training or validation split strategies.
3. Upload the data and create a labeling task; the AI generates a draft, which is then revised by professionals who also establish rules for handling disputes.
4. Freeze tracked dataset versions to check for duplicate samples, label leakage, class imbalance, and device or regional biases.
5. Set up experiments to compare candidate architectures and parameters, while recording computing power, code, configuration, metrics, and failed runs.
6. Evaluations are conducted on an independent validation set and key subgroups, with performance thresholds, manual escalation mechanisms, and conditions for rejecting outputs established.
7. Model cards, validation evidence, and deployment packages are generated and approved jointly by the heads of clinical affairs, quality, safety, and regulatory affairs.
8. Publish to the testing endpoint to verify authentication, latency, capacity, logging, rollback, and integration with existing systems.
9. It is launched on a small scale, with continuous monitoring of inputs, outputs, drift, errors, and human decisions; it pauses or re-verifies when the predefined conditions are met.

Suitable for users and scenarios

• Hospitals and medical research teams: create imaging datasets and experimental models, while keeping records of the research process.
• Medical AI and SaMD teams: integrate labeling, experimentation, validation evidence, and deployment handover into a unified process.
• Pathology, radiology, ophthalmology, and specialized data teams: enhance data preparation capabilities through expert review combined with supplementary annotation.
• Manufacturing Quality Team: Develops models for visual defects, process anomalies, and reliability, as well as plans for production deployment.
• Small R&D teams: It reduces the engineering workload associated with developing custom annotation tools, training infrastructure, and MLOps pipelines.
• Regulation and Quality Personnel: View the connection records between data, models, evaluations, releases, and manual reviews.
• It should not be assumed that the claim on a page stating it is HIPAA-ready or that there is evidence of quality means the product has obtained approval for a specific medical device.

Prices and packages

The main product page and the application page offer different benefits for the free tier, as well as for the Starter and Team plans; this may be due to different entry points, account levels, or recent updates. The quotas indicated on any of these pages should not be considered the standard for all accounts – the package details after registration, the actual billing amount, or a written quote should be taken as the reference.

The public page does not list the costs associated with Team, Organization, and Enterprise plans, nor does it provide a complete explanation of the rules regarding excess usage of GPUs, inference capabilities, storage space, and refunds. The 14-day trial period is stated to be free of charge, but details such as downgrade after the trial ends, data retention, and whether automatic charging will apply need to be checked in the account settings.

Platforms, APIs, and deployment

API, SDK, and open-source status

• The platform can deploy models as API endpoints, but there is no information available regarding a complete set of developer APIs, SDKs, rate limits, or pricing for self-service interfaces intended for the general public.
• The product description mentions that the MCP layer is used for scheduling machine learning experiments, but the public pages do not provide sufficient documentation to prove that it is available as a standard feature for customers.
• Since there are no official open-source repositories or open-source licenses available for MAEA, Hebra, or the core training and governance platform, they should be considered proprietary software.
• Whether the model trained by the client can be downloaded, deployed externally, or used in papers or commercial products must be determined based on account privileges, data licensing agreements, and the relevant contracts.
• API access, federated training, edge deployment, and custom integration do not imply that the platform code can be replicated or used for unlimited commercial purposes.

Privacy, security, medical, and commercial considerations

• The platform handles medical images, industrial data, labels, review records, model outputs, and deployment logs; medical projects must have their identifying information removed and access permissions established before they are uploaded.
• The page mentions concepts such as HIPAA readiness, APPI readiness, encryption, audit logs, and role-based permissions, but no English privacy policy or list of security certifications that can be fully verified was provided in this case.
• The regulatory team shall provide written confirmation regarding the data areas, sub-processors, key management, backup procedures, deletion timelines, incident reporting, and cross-border data transfers.
• Federal training can reduce the need to gather raw data in a centralized manner, but gradient values, model updates, logs, and coordination services still require threat modeling and privacy assessment.
• The audit trail and the exportable SaMD documents represent capabilities in evidence management; they do not imply that regulatory authorities have reviewed and approved the model or its clinical use.
• Medical models must be validated in relation to changes in population, equipment, institutions, time, and workflows; the results shown on pages cannot serve as a substitute for external validation of this project.
• To create a model, it is necessary to define strategies for false positives, missed detections, line shutdowns, and fail-safe operations; production processes should not be triggered solely by automatic predictions.
• The ownership of the models, labels, and outputs, as well as the reuse of training data, rights for commercial deployment and publication, are not clearly specified; these aspects should be outlined in detail within the procurement contract.
• The existing Terms page is accessible, but its content is not yet available consistently; details regarding refunds, responsibilities, termination, and content licensing have not been finalized as of yet.

Advantages and limitations

• Advantages: It connects annotation, experimentation, evaluation, evidence, and deployment, making it suitable for reducing the fragmentation of tools in regulated AI projects.
• Advantages: Auxiliary annotation, active learning, and expert review allow professionals to focus their time on complex cases.
• Advantages: Subgroups, drift, model cards, audit logs, and rollback mechanisms are more in line with real-world production governance practices.
• Limitations: The free quotas and team quotas for different pages overlap with each other, and the actual costs as well as resource limitations are not clear.
• Limitations: The capabilities of the platform cannot eliminate data discrepancies, incorrect labels, nor the responsibilities related to clinical validation and manufacturing safety.
• Limitations: There is insufficient transparency regarding privacy, security certifications, API documentation, SDKs, refund policies, and model ownership terms.
• Limitations: The core product’s open-source status has not been confirmed; custom deployment, federated training, and enterprise integration may require sales and implementation services.

Summary

ModAstera is suitable for teams that wish to move from raw medical or manufacturing data to verifiable, deployable models while retaining evidence of the processes involved. During evaluation, an end-to-end test should be conducted using real data, and attention should be paid to the quality of the annotations, the performance of different subgroups, the deployment interfaces, monitoring mechanisms, compliance responsibilities, package limits, and data-related contracts.