CORENET X isn't CORENET 2.0 with a new name. Mandatory IFC-SG, automated validation, and multi-agency submissions change everything. October 2026 is the cliff.
You're sitting in a project handover meeting when someone mentions it. The new submission goes through CORENET X, not CORENET 2.0. You nod, assuming it's the same process with a different name. Export your DWGs, compile your PDFs, upload through the portal. You've done this dozens of times.
Then you open the submission requirements.
IFC-SG format. Mandatory. SGPset property sets with specific values on specific elements. Automated validation that checks your model before any human reviews it. Your DWG workflow doesn't apply here. Neither do your PDF compilations. The entire submission process you've refined over years just became obsolete.
We've all been here. Or we're about to be. The transition from CORENET 2.0 to CORENET X isn't a platform update. It's a fundamental shift in how Singapore handles regulatory submissions. And the October 2026 deadline means every practice in Singapore needs to adapt.
This builds on our previous piece about why CORENET X validation fails after export. That article covered the export-validate-fix cycle. This one steps back further: what actually changed between the two systems, and what does that mean for your practice?
CORENET 2.0 was built around documents. You compiled drawings, exported files, uploaded packages. Human reviewers checked your submissions against regulatory requirements. The system accepted what you gave it; validation happened downstream.
CORENET X is built around data. Your model isn't just a file to upload. It's a structured dataset that machines parse, validate, and route to multiple agencies simultaneously. The system doesn't wait for human review to tell you something's wrong. It knows immediately.
Here's what that looks like in practice:
| Aspect | CORENET 2.0 | CORENET X |
|---|---|---|
| Submission Format | DWG, PDF, limited IFC | IFC-SG (mandatory) |
| Validation | Manual review | Automated IFC validation |
| Property Requirements | Optional metadata | SGPsets required on elements |
| Agency Integration | Separate portals per agency | Unified multi-agency submission |
| Feedback Timing | Days to weeks | Immediate on upload |
The implications cascade through your entire workflow.
CORENET 2.0 accepted IFC files, but they were optional. Most practices defaulted to DWG exports with PDF documentation packages. If you exported IFC at all, it was supplementary.
CORENET X makes IFC-SG the primary submission format. Not optional. Not supplementary. The only format that passes through the gate.
IFC-SG extends the standard IFC4 schema with Singapore-specific property sets (SGPsets) required by local regulatory agencies. Your model needs SGPset_Door properties on doors. SGPset_Wall properties on walls. SGPset_SpaceDimension on rooms. Hundreds of parameters organized by element type and regulatory requirement.
Week 1. You're starting a new project. Deadline is months away. You set up your Revit template the way you always have: categories, shared parameters, your standard family library. IFC export configuration can wait.
Month 3. Design development wraps. You start thinking about documentation. Someone mentions CORENET X. You check the SGPset requirements and realize half your shared parameters don't map to what the system needs.
Month 5. Submission deadline approaching. You're retrofitting SGPset properties onto elements that should have had them from the start. Every door, every wall, every room needs properties you didn't plan for. Four hours of IFC export. Upload. Immediate failure. Missing SGPset_FireRating on seventeen doors. Wrong IFC class mappings on your curtain wall panels.
Month 5, Week 2. You're debugging cryptic validation errors at 11 PM, wondering why you didn't set this up properly in Week 1.
The pattern repeats across the industry. Not because practitioners are careless, but because the CORENET 2.0 muscle memory doesn't transfer. The habits that worked before now create problems.
In the CORENET 2.0 world, you uploaded files and waited. Days passed. Sometimes weeks. Eventually, feedback arrived. Often vague, sometimes contradictory between agencies. You made corrections, resubmitted, waited again.
CORENET X validates instantly. Upload your IFC file, and the system parses it immediately. Schema compliance. Quality checks. Regulatory requirements. Results in minutes, not weeks.
This sounds like an improvement. Faster feedback should mean faster iteration. But there's a catch: the validation is precise in ways human review never was.
Missing a FireRating parameter on one door? CORENET 2.0's human reviewer might not catch it, or might accept a note in your documentation. CORENET X flags it immediately. Every door. Every instance. No exceptions, no discretion, no "we'll note that in the response."
The same precision applies everywhere. SVY21 coordinates configured incorrectly? Flagged. IFC class mappings that don't match expected patterns? Flagged. Property values that fall outside acceptable ranges? Flagged.
You're no longer working with reviewers who understand context and make judgment calls. You're working with validation rules that execute exactly as written.
CORENET 2.0 routed submissions to agencies separately. BCA had their portal. URA had theirs. SCDF, PUB, LTA: each maintained their own systems with their own requirements. Painful, yes, but the pain was distributed. You could satisfy one agency at a time.
CORENET X consolidates eight agencies (BCA, URA, LTA, PUB, NEA, SCDF, NParks, SLA) into unified submission gateways. One model serves multiple regulatory reviews simultaneously. One upload, multiple validations.
This means your model needs to satisfy everyone at once. The SGPset properties BCA requires. The spatial data URA needs. The fire safety parameters SCDF validates. The drainage information PUB checks. All present, all correct, all in the same IFC file.
The efficiency gains are real: no more managing eight separate submission workflows. But the model requirements compound. A property set you never needed for BCA approval might be mandatory for PUB compliance. An IFC class mapping that satisfies URA might not work for LTA.
Your single model now carries the burden of eight agencies' requirements. And automated validation checks all of them.
The transition isn't gradual. It's staged with hard deadlines:
| Phase | Date | Requirement |
|---|---|---|
| Active | Oct 2025 | IFC-SG BIM mandatory for new projects with GFA ≥30,000 sqm |
| Phase 2 | Oct 2026 | IFC-SG BIM mandatory for projects ≥5,000 sqm GFA |
| Phase 3 | Oct 2027 | Ongoing projects ≥5,000 sqm must migrate to IFC-SG |
We're now in the first phase. Large projects are already submitting through CORENET X. The October 2026 deadline expands the mandate to most commercial and institutional projects. By October 2027, even ongoing projects above the threshold must migrate.
For practices working primarily on projects ≥5,000 sqm, October 2026 is the cliff. Not "starting to learn." Actually capable of successful submission.
❓ Can I keep using my CORENET 2.0 workflow until October 2026?
✅ Technically yes, for projects under the size threshold. But you're compressing your learning curve into an increasingly narrow window. Practices that wait until 2026 to adapt will compete for the same consultants, training resources, and troubleshooting support as everyone else scrambling to meet the deadline.
❓ Do I need new software for CORENET X submissions?
✅ Not necessarily. Revit, ArchiCAD, and most BIM authoring tools can export IFC. The challenge isn't software. It's configuration. Your export settings, property mappings, and template setup need to align with IFC-SG requirements. The tools you have can work; the workflows you use need to change.
❓ What happens if my submission fails automated validation?
✅ You receive specific error codes indicating which elements failed and why. Unlike CORENET 2.0's narrative feedback, these are structured validation results. Useful for debugging, but only if you understand what the codes mean and can trace them back to your model.
❓ How do I know which SGPset properties my project needs?
✅ The Industry Mapping documentation defines all 700+ parameters organized by element type and regulatory requirement. The CORENET X Parameter Lookup Tool lets you search this database by agency, discipline, or element type.
The transition doesn't require panic, but it does require action. Here's what actually helps:
Audit your current IFC workflow. Export a typical project to IFC today. Open it in a viewer. Check what properties transferred, what class mappings applied, what got lost. Most practices using default export settings will find significant gaps.
Map SGPset requirements early. Use the CORENET X Parameter Lookup to understand what your project types need. Identify which parameters you already capture and which require new shared parameter definitions.
Test on a non-critical project. Run through the full CORENET X submission process before you have a real deadline. Discover the pain points when you have time to solve them.
Build validation into your workflow. The export-validate-fix cycle we covered previously costs hours per iteration. Tools like Senibina Gateway validate SGPset compliance inside Revit before export, catching issues at the source rather than after four hours of export time. We're currently partnering with 5 Founding Firms during our technology preview. Apply for Founding Access to shape what we build.
CORENET X isn't a software update. It's a workflow transformation that affects every practice in Singapore. The timeline is fixed, the requirements are clear, and the validation is unforgiving.
Practices that adapt early will spend their time on design and delivery. Those that wait will spend October 2026 debugging validation errors they could have prevented months earlier.
The submission platform changed. The question is when your workflow will.