Organisational Constraints

Organisational Constraints solve the problem that standard RAG fundamentally cannot: proactively checking proposed actions against institutional knowledge that exists only in senior employees' heads. The knowledge that prevents an agent from causing damage - which database is production, which vendor relationships have informal terms, which market segments have brand sensitivities - is almost never in a document. Even if it were, standard retrieval surfaces information in response to queries. Constraints need to be checked against actions, regardless of whether the agent asked about them.

This is inverted retrieval. Normal artifacts are surfaced when an agent queries for information. Constraints are checked when an agent proposes an action. The system asks: "are there any declared constraints whose scope intersects with this action?" The constraint index is scanned against the action, not the query.

Constraints come in four types. Boundary constraints are hard lines: "db-prod-01 is the production database - never run destructive commands against it without explicit operator approval." Relationship constraints encode institutional knowledge about external parties: "Acme Corp has informal net-60 payment terms negotiated directly with the CFO - standard net-30 templates do not apply." Policy constraints capture organisational rules that may not be written down elsewhere: "The APAC market segment had a brand crisis in Q3 2025 - all marketing copy targeting APAC requires CMO review." Context flag constraints provide ambient awareness: "The company is in quiet acquisition talks - IP-related contract clauses are currently existential."

Each constraint declares a severity that controls the system's response: inform (surface the constraint but don't impede), warn (flag with a prominent warning), require_approval (block until a human with the appropriate role approves), or block (hard stop, no override). This graduated response lets organisations calibrate their risk tolerance per constraint rather than treating everything as a binary allow/deny.

Scope matching uses a two-pass process. Pass 1 is structural: if the proposed action names a specific resource, entity, or domain that appears in a constraint's scope identifiers, it matches. This is fast and deterministic. Pass 2 is semantic: the proposed action description is embedded and compared against constraint embeddings. Constraints above a similarity threshold (default 0.78) are returned as potential matches with a confidence score. Both passes run on every check - structural matches are always returned, semantic matches come with confidence for the caller to apply judgment.

The constraint lifecycle is append-only with supersession. Constraints are never mutated. Updates create new constraint records with supersedes pointers to the prior version. Expired constraints transition automatically and stop matching but remain in the audit trail. Constraints with a review interval generate pressure events when review is overdue - the same "memory cannot rot" principle that applies to all platform knowledge.

Agents can also contribute to the constraint surface. The suggest_constraint tool lets any agent propose a constraint discovered during work - for example, that a particular database is production (discovered by reading config files) or that a vendor integration has undocumented rate limits. Suggestions enter a review queue; only humans with appropriate roles can promote them to active constraints. This preserves the authority model while turning every agent session into a potential constraint-discovery exercise.