Vector · Frequently asked questions

It is a commercial-intelligence system for grain elevators that detects when there is a concrete reason to contact a producer without confusing a good market price with a good decision for the elevator.

A market signal is useful only if the exact contract pricing formula is correct and the elevator is hedged against the corresponding operation. A price high may be interesting for the producer and financially harmful for the elevator. Vector keeps those two realities separate. Implementation is reviewed with people who understand contracts and positions. Cases that should attract attention and cases that should be rejected are tested. The team can then understand the criterion before authorising contact, rather than allowing automation to create additional unreviewed exposure.

Detect a relevant window against the exact contract formula. Verify position, data freshness and contract-level hedge. Explain why the alert exists. A human approves or rejects contact and selects the channel. The system executes contact, records the reply and escalates to the salesperson when appropriate. The outcome is recorded without automatically claiming causality. Counting sent messages is not enough. Review rejected alerts, data freshness, responses and handoffs. A contact can be appropriate without immediately producing a transaction. Vector preserves that distinction so the team can assess usefulness rather than mistake volume for commercial value.

The first version is read-only by design. Vector consumes positions, contracts and status from the ERP through APIs, read-only access or exports. If integration is unavailable it can operate with controlled manual input, but requires reconfirmation before contact. Test contracts are selected, received values compared and changes or missing information examined. The aim is not connectivity for its own sake: the responsible team must recognise its data and understand the review process. Further integrations are justified by that observed operation.

Human approval is not a technical limitation; it is a commercial safeguard. An alert type should become automatic only after sufficient evidence shows that the criterion behaves reliably over repeated use. When one class of alerts demonstrates consistency, the organisation may consider limited authorisation. That decision needs explicit scope and conditions. Other contracts, channels or circumstances do not automatically inherit the same permission. The goal is less repetitive work without removing the ability to stop, inspect and correct the process.