What the first month of a Proximity deployment can establish

The first month of a deployment should make the business problem more concrete.

That does not mean every deployment follows the same four-week sequence or reaches the same technical milestone. A focused workflow with clean data and simple permissions can move into an early working flow quickly. A cross-system process with inconsistent identities, sensitive records, or formal security requirements may spend more of the first month establishing the foundation.

The useful question is not “What is guaranteed in 30 days?” It is “What should the organisation understand, test, and decide before committing to the next stage?”

Begin with one business outcome

The first month starts with an outcome rather than a list of AI features.

Examples include:

• reduce manual coordination needed to answer order-status questions;
• improve fulfilment accuracy;
• shorten supplier qualification review;
• reduce the time required to prepare a project-change decision;
• improve continuity across properties or service teams;
• make management reporting more current and source-linked.

The outcome defines which operation is in scope, which users need to participate, and which measures matter. It also prevents discovery from turning into an open-ended exercise to connect every system.

A useful baseline might include preparation time, repeated data entry, internal status requests, exception age, correction rates, avoidable rework, or decisions delayed by missing evidence. The first month should make these measures credible enough to judge later value.

Understand how the work happens now

The operating area needs to be observed, not only described in an idealised process map.

That means looking at:

• where the work begins;
• which systems, files, messages, and meetings contribute evidence;
• how people identify the current state;
• which exceptions cause manual coordination;
• who owns each decision;
• what requires approval;
• which habits make the process work despite the formal system;
• where users correct, reinterpret, or work around existing data.

This stage frequently changes the original brief. A request for a dashboard may turn out to be a product-identity problem. A request for automated customer replies may depend on reconciling order, inventory, and fulfilment state first. A request for better reporting may reveal that teams do not share the same definition of an approved change.

That is useful progress. It replaces a broad technology request with a testable operating problem.

Audit data, access, and authority

Before a workflow is automated, the approved source data needs to be understood.

The audit covers:

• which sources are in scope;
• which system or role is authoritative for each fact;
• identity conflicts and duplicate records;
• missing, stale, or inconsistently entered data;
• terminology and state differences;
• source timestamps and provenance;
• permissions and purpose boundaries;
• retention, export, revocation, and deletion requirements;
• actions that remain behind human approval.

This work is not an implementation delay. It determines whether a later interface presents a dependable current view or simply gives a clean appearance to unresolved data.

Security and access work also varies materially by deployment. NIST SP 800-53 provides established control families for areas such as access control, audit, identification, system integrity, and risk assessment. A small internal prototype may need a narrow subset. A regulated or enterprise production deployment may require a formal security review, data-processing agreement, detailed control mapping, and evidence from several teams ^{2NIST SP 800-53 Rev. 5, Security and Privacy Controls}.

Design the connected operating model

Once the relevant sources are understood, the first model can define the entities, relationships, states, and terminology needed for the outcome.

For an OEM or ODM order-status workflow, this may connect customer order, order line, product revision, work order, operation, quality state, shipment, promise, and owner. For supplier review, it may connect requirement, supplier, site, quotation, sample, qualification, payment event, logistics event, issue, and decision.

This ontology design should show:

• which identities need reconciliation;
• how state is derived;
• which source remains authoritative;
• how conflicts stay visible;
• which events make the current view stale;
• which role owns an exception;
• which decisions or actions the model is intended to support.

The first month may produce a partial connected model rather than a complete production ontology. The aim is to test whether the proposed relationships explain the operation well enough to support useful review.

Test an early working flow where readiness allows

An early flow should use real materials and real review conditions.

Depending on the outcome, it might be:

• a source-linked order-status view;
• a queue of product or inventory discrepancies;
• a supplier review packet with evidence gaps;
• a project-change view connecting versions, approvals, and owners;
• a management summary linked to current project records;
• a role-specific interface for reviewing an exception.

The prototype is not judged by whether the AI appears impressive. It is judged by whether users can answer practical questions faster and more reliably.

Can they trace the status to a source? Does the view expose rather than hide conflicts? Does it use the language of the work? Does it fit the point in the workflow where a decision is made? Can a user correct an identity, state, or relationship? Is the action boundary clear?

Some deployments will not reach this stage within the first month. If data access requires lengthy approval, integrations need vendor work, or the source state is not reliable enough, a prototype may use a controlled data extract or representative records while the production path is scoped.

That is not the same as claiming the live integration is complete.

Include users before the design hardens

User acceptance testing is not only a final gate before launch.

Operators, reviewers, and decision owners need to test the workflow while its terminology, states, exceptions, and interface are still easy to change. Standard cases show whether the basic route works. Edge cases reveal whether the model fits reality.

Feedback should distinguish several types of problem:

• the source is late or wrong;
• the identity mapping is wrong;
• the ontology does not represent the case;
• the interface hides necessary context;
• the workflow asks for review at the wrong moment;
• the authority boundary is unclear;
• the user's operating habit has not been understood.

This classification matters because each problem needs a different response. Training cannot fix a bad mapping. A new field cannot fix unclear decision rights. Better automation cannot fix data that no team owns.

What the first month may produce

A useful first month can establish a combination of:

• a defined business outcome and baseline;
• a map of the current workflow and decision owners;
• an approved-source and permission inventory;
• a data-quality and reconciliation assessment;
• an initial business ontology;
• an early working flow or prototype;
• feedback from real users and edge cases;
• a security and governance worklist;
• a scoped pilot or production implementation plan;
• success criteria for the next stage.

The balance depends on readiness.

When the foundation is already strong

If sources are accessible, identities are stable, permissions are clear, and the workflow is bounded, the first month can concentrate on the connected model, interface, and early testing.

When data needs substantial work

If product, customer, supplier, asset, or project identities conflict across systems, auditing and reconciliation may dominate. The valuable result is a credible model of what needs to be corrected, not a rushed automation built on disputed state.

When governance is complex

Sensitive, regulated, or multi-party work may require more time for security review, legal agreements, permission design, and approval testing. Those controls shape the production timeline even when a prototype is technically straightforward.

What determines the path to production

Pilot and production timelines depend on several factors:

ISO/IEC 42001 treats AI management as a continuing system of responsibilities, objectives, controls, evaluation, and improvement. That is a better model for deployment than treating launch as a one-time technical completion ^{3ISO/IEC 42001 AI management systems}.

NIST's AI Risk Management Framework similarly organises work around governing, mapping, measuring, and managing risk across the lifecycle and context of use ^{1NIST AI Risk Management Framework}.

The first month is a decision point

The first month should leave the organisation able to make a better decision about what comes next.

It should be clearer:

• whether the outcome is valuable enough to pursue;
• whether the available data can support it;
• which source and process changes are required;
• whether the ontology explains the work;
• how users respond to an early flow;
• what security and governance work remains;
• how the pilot or production stage should be scoped.

That is a more useful standard than promising the same deliverable on the same day for every organisation. The first month creates evidence for the deployment plan. It does not replace the work required to reach dependable production use.

Sources

1. NIST AI Risk Management Framework
2. NIST SP 800-53 Rev. 5, Security and Privacy Controls
3. ISO/IEC 42001 AI management systems