Ten customer questions ·
What can Neon actually do?
Ten answers from a named Neon GUI run: requirements, alternatives, port-level connectivity, documents, delivery, security and risk. Each answer states what was observed and what remains unproved.
The evidence behind these answers
These answers are adapted from Traiano Welcome’s 4 September 2026 customer-publication document, ‘10 Things Neon Can Demonstrably Do’. Its test used Neon 0.2.0-internal.5+d2768dae2cbe on macOS arm64, in an isolated local_secure installation. The source reports GUI controls only, no workflow skips, no direct API advancement and no unexpected browser-console or HTTP failures.
The source scenario is redacted as ACMEX Asia. We reviewed the supplied screenshots and retained the original captures without editing them. Project AIF-PROJ-000001 reached revision REV-000003 and baseline BASELINE-000001. These are observations reported in that source run, not a fresh test of today’s product or a published customer endorsement. We preserve its qualifications, including the vendor-projection mismatch.
1. Can Neon take an AI factory from requirements to engineering handoff?
Yes. Neon carries requirements through design, assessment, alternatives, decisions and a governed handoff. The useful output is the recorded path: what was assumed, what changed, who decided and what remains open. That gives the next engineer a starting point they can inspect, instead of a design whose reasoning has disappeared.
Observed in the source run: The installed application completed all ten visible workflow stages. The run created a checkpoint, an alternative, a comparison, a review decision, a baseline and an evidence package.
Completing the workflow does not close every unresolved engineering item. Open issues still need an owner and a decision.
2. Does Neon bring the IT and software architecture into one view?
Yes. Neon joins compute, scale-up interconnect, east-west fabrics, storage, north-south services, management, security and platform software in one architecture. It also carries equipment, physical connectivity, facility-facing demands, risks and delivery work. The purpose is to expose dependencies between these parts before different teams turn them into separate documents.
Observed in the source run: The Architecture view and Workbench showed the bill of materials, physical fabrics, security, requirements, risk, vendor options and delivery planning for the same project.
Coverage depends on the compiler and knowledge available for each domain. Facility-facing quantities do not replace electrical, mechanical or civil engineering.
3. Can I explore alternatives without rebuilding the design?
Yes. Change a requirement or an architecture choice, then recompile the affected design. Keep checkpoints on both sides of the change so reviewers can compare what moved. This makes an alternative a recorded engineering branch with visible differences, rather than another slide deck someone must reconcile by hand.
Observed in the source run: A storage-capacity alternative changed the target to 4.5 PiB. The run recompiled it, saved a checkpoint and compared recorded semantic differences in the GUI.
A comparison records the consequences of a change. It does not automatically recommend which alternative to buy.
4. Can Neon compare competing vendor technologies?
Neon can classify the selected basis, compatible implementations, alternatives requiring a different architecture and candidates needing further validation. That classification is useful only if the options belong to the architecture being reviewed. The supplied run exposed a mismatch, so it does not prove correct vendor selection for this scenario.
Observed in the source run: The Vendor Options Workbench projected GB300 NVL72 and Spectrum-4 SN5600 options onto an HGX B300 / Quantum-X800 scenario. The categories were visible; the projection did not match the selected basis.
Do not use this run as proof that Neon ranks the right vendors for the scenario. Revalidate the projection before relying on its options in a bid.
5. Can Neon structure engineering dependencies and handoffs?
Yes. Neon turns architecture into workstreams, dependencies, decisions, handoffs and gates. This helps the delivery team see what must be resolved before another discipline can proceed. It provides an engineering baseline that a project manager can use when building the programme and agreeing responsibility with suppliers.
Observed in the source run: The Delivery Plan Summary identified external dependencies and handoffs derived from the architecture.
The output does not establish commercial dates, available staffing or contractual schedule authority. Those remain delivery-management decisions.
6. Can I trace a logical Clos fabric to devices, ports and links?
Yes, for supported fabrics. Neon connects the logical network to physical connectivity records. A reviewer can start with a link and inspect the endpoint, switch and port identities behind it. This makes it possible to reconcile the architecture with a connectivity ledger before installation teams turn it into site-specific work.
Observed in the source run: Searching LINK-EW-N001-R01 opened a trace sheet containing canonical endpoint, switch, port and link identities alongside the logical Clos view.
The physical ledger is the authority for connectivity. It is not an installation instruction, a cable route or proof of installed link performance.
7. Can Neon generate the Solution Architecture document?
Yes. Neon generates a structured architecture document from the governed state. This keeps quantities and conclusions tied to the design that produced them. The resulting document gives reviewers one place to check the architecture and its evidence, instead of assembling a narrative from disconnected exports and handwritten summaries.
Observed in the source run: The Documentation Compiler produced DOC-GEN-000001 from REV-000003 / BASELINE-000001, with Full Solution Architecture downloads in DOCX and PDF.
A generated review draft is not automatically approved for customer issue. The reviewer still owns that release decision.
8. Can Neon generate an implementation-planning baseline?
Yes. Neon can produce the technical structure of an implementation plan: phases, workstreams, tasks, dependencies, gates and handoffs. This is the downloadable artefact behind the process described in question five. It lets the delivery team start with architecture-derived work and then add people, dates and commercial commitments.
Observed in the source run: The Project Delivery Planning Compiler displayed the architecture-derived baseline and made its documents available to download.
This is not a resource-loaded or contractual programme. Questions five and eight share the same compiler evidence; they are not two independent delivery results.
9. Can Neon assess the security architecture?
Yes, at architecture level. Neon presents trust zones, flows, expected controls, findings and unresolved security decisions. This gives reviewers a way to challenge the proposed boundaries before deployment. It also makes missing engineering information visible, which matters as much as displaying a control that has already been specified.
Observed in the source run: The named build displayed Security Zone Overview and detailed Zones, Findings and Flows for the project.
An architecture screen does not prove deployed tenant isolation, key custody, successful attestation, penetration-test results or certification. Each needs separate operational evidence.
10. Can Neon structure architectural risks and required decisions?
Yes. Neon records architectural conditions, consequences, dependencies, possible mitigations and decisions still needed. Reviewers can put their assessment alongside the design and carry it through checkpoints and governance. That makes risk part of the architecture record, with an explicit human judgement instead of a detached list of warnings.
Observed in the source run: The BARC Architecture Baseline Risk Register carried reviewer-entered impact, likelihood and notes, connected to checkpointing and governance.
Recording a risk or proposing a mitigation does not accept the remaining risk. A responsible person must make and record that decision.
Take the evidence into your bid
For the operational proof a provider must assemble, use the guide to GB300 acceptance evidence.
For the definitions and trace records behind network quantities, read scalable units and fabric evidence.
Then record which requirements you can currently evidence in the NCP requirements self audit.
The brief
How Neon fits your AI factory delivery pipeline
Nine pages for the people who sign: where Neon sits in an enterprise AI factory delivery pipeline, what it owns, what it never touches, and the three questions executives ask. Sent as a PDF.
The Neon briefings explain the design and delivery choices behind the package.
Email me the brief