AIC FOUNDATION: a consistent start for mission software

A new intelligence application should start with a clear requirement and a team ready to build it. Too often, the opening work is familiar administration: repository layout, project structure, build pipelines, configuration conventions and notes explaining how everything fits together. Each decision is small. Repeating them across programmes creates a support burden.

AIC FOUNDATION packages that starting structure into versioned project templates and delivery scaffolding. Teams generate a known baseline, then develop the software their mission requires. FOUNDATION is available now for customer demonstrations using a representative project and the engineering arrangements you need to support.

Establish the project before adding domain complexity

FOUNDATION provides solution templates, a reusable project structure, configuration patterns, engineering guidance and YAML pipeline scaffolding. It works with Microsoft .NET, NuGet templates, Azure DevOps, Git and Visual Studio. These are the foundations of a delivery process that a new developer should be able to inspect and understand.

A consistent starting point helps reviewers find familiar things in familiar places. It also gives teams a basis for explaining deliberate differences. A programme may need a different deployment model or additional review steps. Those changes are easier to discuss when everyone can identify the baseline from which the project began.

The resulting solution remains customer-specific. The point is to make routine setup repeatable while leaving engineers free to implement the required behaviour. An analyst application, a data-processing service and an integration component may share delivery conventions without being forced into the same application design.

Understand the relationship with FOUNDRY

FOUNDATION establishes the project and its delivery structure. AIC FOUNDRY supplies reusable engineering capability through controlled packages. A team can therefore start with a familiar solution layout and add only the package dependencies justified by its requirement.

The distinction helps procurement and engineering teams ask clearer questions. Template distribution concerns how a solution is created and how its baseline is recorded. Package maintenance concerns the implementations the application continues to depend on. The licence, support and update arrangements should explain both where both products are used.

The Constellation product guide explains AIC’s intelligence, engineering and simulation products. FOUNDATION supports the teams building software around those requirements, giving them a consistent project and delivery structure.

Keep security decisions visible

FOUNDATION generates templates into the approved engineering environment and introduces no hosted application-data dependency. That is useful where a customer needs to control the repository, build system and resulting source. The permitted distribution and update route should be agreed for the organisation’s own environment.

The generated solution needs a security design for its purpose and environment. Its team specifies identity, access decisions, encryption, secret handling and release controls. A repeatable project baseline helps engineers apply and review those choices consistently.

An intelligence buyer should therefore ask to see the starting structure and the decisions still to be made. Which pipeline stages are supplied? Which configuration values must the customer provide? Where will environment-specific checks sit? What evidence will the delivery team retain when a baseline or dependency changes?

Test the baseline with the people who will use it

A useful demonstration begins with a small, agreed requirement and an empty project location. Ask AIC to generate the solution, explain the layout and show the build process. Record the setup steps that remain manual. The objective is to understand what the team receives and what it will still need to implement.

Have a developer who did not create the template follow the guidance. They should be able to locate configuration, understand the project boundaries and make a small application change. Their experience gives you a more useful indication of onboarding effort than a demonstration delivered only by someone who already knows the structure.

Then review a project-specific requirement and show how the baseline accommodates it. Record the template version and decide how later template or guidance changes will be assessed for the existing solution. Apply them through the project’s normal engineering review, preserving its customer-specific work.

The FOUNDATION project delivery evaluation describes an illustrative assessment. Use it to agree the evidence your engineers and programme owners want to see before deciding whether the baseline suits the next commission.

Put setup and maintenance effort in the same comparison

The cost argument is straightforward: repeated project setup and inconsistent conventions consume engineering time. The value of a shared baseline depends on the number of projects, the fit with existing practice and the work required to adopt it. Those factors should be tested against the organisation’s current approach.

Include developer onboarding, build configuration, documentation and handover in the comparison. Also include the effort of maintaining exceptions. A template that requires extensive changes for every application may offer less value than one that matches the work your teams regularly deliver.

Book a FOUNDATION demonstration with a description of the software you commission, your development environment and the controls a new project must satisfy. AIC can show the relevant baseline and scope the adoption, support and licensing work around those requirements.