ಇಂದು ನೀವು ಬಳಸುವ ಪ್ರತಿಯೊಂದು ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಒಂದು ನಿರ್ದಿಷ್ಟ ಕಲ್ಪನೆಯನ್ನು ಆಧರಿಸಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಪರದೆಯ ಮುಂದೆ ಬೆರಳುಗಳಿರುವ ವ್ಯಕ್ತಿಯೊಬ್ಬ ಕುಳಿತಿದ್ದಾನೆ ಎಂಬುದು ಆ ಕಲ್ಪನೆ. ಬಟನ್ಗಳು ಉದ್ದೇಶವನ್ನು ಸೂಚಿಸುತ್ತವೆ. ವಿಜಾರ್ಡ್ಗಳು ಸಂಕೀರ್ಣತೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ. ಫಾರ್ಮ್ಗಳು ಮಾನವನ ಆಲೋಚನೆಗೆ ಒಂದು ಚೌಕಟ್ಟನ್ನು ನೀಡುತ್ತವೆ. ಇತ್ತೀಚಿನವರೆಗೆ ಕೇವಲ ಮನುಷ್ಯರು ಮಾತ್ರ ಕ್ಲಿಕ್ ಮಾಡುತ್ತಿದ್ದರಿಂದ, ಈ ವಾಸ್ತುಶಿಲ್ಪವು ದಶಕಗಳ ಕಾಲ ಉತ್ಪನ್ನ ವಿನ್ಯಾಸವನ್ನು ನಿಯಂತ್ರಿಸಿದೆ.
ಆ ಕಲ್ಪನೆಯು ಈಗ ಮುರಿದುಬಿದ್ದಿದೆ. AI ಏಜೆಂಟ್ಗಳು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ಓದುವುದಿಲ್ಲ. ಅವುಗಳಿಗೆ ಉಪಯುಕ್ತ ಟೂಲ್ಟಿಪ್ಗಳು ಅಥವಾ ಕನ್ಫರ್ಮೇಷನ್ ಡೈಲಾಗ್ಗಳಿಂದ ಯಾವುದೇ ಪ್ರಯೋಜನವಿಲ್ಲ. ಒಂದು ಸ್ವಾಯತ್ತ ವ್ಯವಸ್ಥೆಯು (autonomous system) ಬಳಕೆದಾರರ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕಾದಾಗ, ಇಂಟರ್ಫೇಸ್ನ ವಿನ್ಯಾಸಗಳು (chrome) ಅಡ್ಡಿಯಾಗುತ್ತವೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಉತ್ಪನ್ನಗಳನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಆಧುನಿಕ callers ವಾಸ್ತವವಾಗಿ ಹೇಗೆ ವರ್ತಿಸುತ್ತಾರೆ ಎಂಬ ನಡುವೆ ಬೆಳೆಯುತ್ತಿರುವ ಅಸಮತೋಲನ ಉಂಟಾಗುತ್ತಿದೆ.
ಕ್ಲಿಕ್ ಪ್ಯಾರಡೈಮ್ (The Click Paradigm)
ಸಾಂಪ್ರದಾಯಿಕ ಸಾಫ್ಟ್ವೇರ್ ದೃಶ್ಯ ಒಪ್ಪಂದದ (visual contract) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಮನುಷ್ಯನು ಒಂದು ಬಟನ್ ಅನ್ನು ನೋಡಿ, ಅದರ ಲೇಬಲ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡು, ಅದನ್ನು ಒತ್ತಬೇಕೆ ಅಥವಾ ಬೇಡವೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತಾನೆ. ಕೆಲಸದ ಹರಿವುಗಳನ್ನು (workflows) ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅಡೆತಡೆಗಳೊಂದಿಗೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗುತ್ತದೆ. ಜನರು ತಪ್ಪುಗಳನ್ನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅವರಿಗೆ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳ (guardrails) ಅಗತ್ಯವಿರುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಮಲ್ಟಿ-ಸ್ಟೆಪ್ ವಿಜಾರ್ಡ್ಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ಡ್ರಾಪ್ಡೌನ್ಗಳು ಮತ್ತು ರೇಡಿಯೋ ಬಟನ್ಗಳು ಇನ್ಪುಟ್ ಅನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಮುಕ್ತ ಪಠ್ಯವು (freeform text) ಗೊಂದಲಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.
ಆಪರೇಟರ್ ಒಬ್ಬ ವ್ಯಕ್ತಿಯಾಗಿದ್ದಾಗ ಇದು ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದರೆ ಆಪರೇಟರ್ ಒಬ್ಬ ಏಜೆಂಟ್ ಆಗಿದ್ದಾಗ ಇದು ವಿಫಲವಾಗುತ್ತದೆ. ಚಂದಾದಾರಿಕೆಯನ್ನು ರದ್ದುಗೊಳಿಸಲು ಅಥವಾ ರೆಕಾರ್ಡ್ ಅನ್ನು ಮಾರ್ಪಡಿಸಲು ಯಂತ್ರಕ್ಕೆ ಐದು ಹಂತಗಳ ವಿಜಾರ್ಡ್ ಅಗತ್ಯವಿಲ್ಲ. ಅದಕ್ಕೆ ಯಾವ ಕಾರ್ಯಾಚರಣೆಗಳು ಲಭ್ಯವಿವೆ ಎಂಬ ಸ್ಪಷ್ಟ ಹೇಳಿಕೆ ಮತ್ತು ಅವುಗಳನ್ನು ಮಾಡಲು ಅನುಮತಿಯಿದೆಯೇ ಎಂಬ ನಿರ್ಣಾಯಕ ಉತ್ತರ ಬೇಕು. ತಂಡಗಳು ಇದನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದಾಗ, ಅವರು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಶಾರ್ಟ್ಕಟ್ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ.
ಮೊದಲನೆಯದಾಗಿ, ಅವರು ಏಜೆಂಟ್ಗೆ ಒಂದು API ಕೀ ಅನ್ನು ನೀಡುತ್ತಾರೆ. ಎರಡನೆಯದಾಗಿ, ಅವರು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬಳಕೆದಾರರ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಚಾಟ್ಬಾಟ್ನೊಳಗೆ ಸುತ್ತುವರಿಯುತ್ತಾರೆ ಮತ್ತು ಇಂಟಿಗ್ರೇಷನ್ ಪೂರ್ಣಗೊಂಡಿದೆ ಎಂದು ಕರೆಯುತ್ತಾರೆ. ಈ ಎರಡೂ ವಿಧಾನಗಳು ನೈಜ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ.
API ಕೀಯು, “ಈ ವಿನಂತಿಯು ನಂಬಿಕಾರ್ಹ ಮೂಲದಿಂದ ಬಂದಿದೆಯೇ?” ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಆದರೆ ಇದು ಮುಖ್ಯವಾದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವುದಿಲ್ಲ: “ಈ ನಿರ್ದಿಷ್ಟ caller ಈ ನಿರ್ದಿಷ್ಟ ರೆಕಾರ್ಡ್ ಅನ್ನು ಓದಬಲ್ಲನೇ?” ಕೀ ಎಂಬುದು ಒಂದು ಸ್ಕೆಲೆಟನ್ ಕೀ (skeleton key) ಇದ್ದಂತೆ. ಒಮ್ಮೆ ನೀಡಿದ ನಂತರ, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಸಂದರ್ಭಗಳಾದ್ಯಂತ ವ್ಯಾಪಕ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತದೆ. ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯ ಒಳಗಿನ ವೈಯಕ್ತಿಕ ಕ್ರಿಯೆಗಳನ್ನು ನಿಯಂತ್ರಿಸುವ ನೀತಿಯ ಬಗ್ಗೆ ಅದಕ್ಕೆ ಏನೂ ತಿಳಿದಿರುವುದಿಲ್ಲ.
GUI ಅನ್ನು ಚಾಟ್ಬಾಟ್ನಲ್ಲಿ ಸುತ್ತುವರಿಯುವುದು ಇನ್ನೂ ಹೆಚ್ಚು ದುರ್ಬಲವಾದ ವಿಧಾನವಾಗಿದೆ. ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಅಡಗಿರುವ ಪ್ರತಿಯೊಂದು ಮಾನವ-ಕೇಂದ್ರಿತ ಕಲ್ಪನೆಯನ್ನು ಏಜೆಂಟ್ ಅಳವಡಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಇದು ಸ್ವಾಯತ್ತ ತರ್ಕಕ್ಕಾಗಿ (autonomous logic) ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಫಾರ್ಮ್ಗಳು ಮತ್ತು ಮಾಡಲ್ಗಳ ಮೂಲಕ ಕ್ಲಿಕ್ಗಳನ್ನು ಅನುಕರಿಸುತ್ತದೆ. ಚಾಟ್ಬಾಟ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಬಳಸಬಹುದು, ಆದರೆ ಅದು ಯಾವುದೇ ತಿಳುವಳಿಕೆಯಿಲ್ಲದೆ ಮಾಡುತ್ತದೆ. ಇದು ಕೇವಲ 'ಆಟೋಮೇಷನ್ ಥಿಯೇಟರ್' (automation theater). ಇದರ ಅಡಿಯಲ್ಲಿ, ಏನನ್ನು ಅನುಮತಿಸಲಾಗಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಯಂತ್ರಕ್ಕೆ ಓದಬಹುದಾದ ಯಾವುದೇ ಒಪ್ಪಂದವಿರುವುದಿಲ್ಲ.
ಏಜೆಂಟ್ಗಳಿಗೆ ಬೇಕಾಗಿರುವುದು ಮುಂಭಾಗದ ಬಾಗಿಲಿಗೆ ಮತ್ತೊಂದು ಕೀಯಲ್ಲ. ಅವುಗಳಿಗೆ ಗೇಟ್ಗಳು (gates) ಬೇಕು.
ಗೇಟ್ಗಳು ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡುತ್ತವೆ
ಗೇಟ್ ಎಂಬುದು ನಿಯಂತ್ರಿತ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಪದರವಾಗಿದೆ (governed execution layer). ಕೇವಲ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಅನ್ನು ನಂಬಿ caller ಸರಿಯಾಗಿ ವರ್ತಿಸುತ್ತಾರೆ ಎಂದು ಭಾವಿಸುವ ಬದಲು, ಗೇಟ್ಗಳನ್ನು ಹೊಂದಿರುವ ವ್ಯವಸ್ಥೆಯು ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯನ್ನು ಘೋಷಿತ ನಿಯಮಗಳ ವಿರುದ್ಧ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ. ಈ ನಿಯಮಗಳು ಯಾವುದೇ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುತ್ತವೆ, ಅದು ಮಾನವನ ಇಂಟರ್ಫೇಸ್ ಆಗಿರಲಿ ಅಥವಾ ಬೇರೆಯಾಗಿರಲಿ.
ಒಂದು ಸರಿಯಾದ ಗೇಟ್ ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಉತ್ಪನ್ನದ ಒಳಗಿನ ಯಾವ ಕ್ರಿಯೆಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ ಎಂದು ಅದು ಘೋಷಿಸುತ್ತದೆ. ಯಾವ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಯಾರು ಅವುಗಳನ್ನು ಬಳಸಬಹುದು ಎಂದು ತಿಳಿಸುತ್ತದೆ. ಸೈಡ್ ಎಫೆಕ್ಟ್ಗಳನ್ನು (side effects) ಉಂಟುಮಾಡುವ ಮೊದಲು caller ಯಾವಾಗ ನಿಂತು ಸ್ಪಷ್ಟವಾದ ಸಮ್ಮತಿಯನ್ನು ಕೇಳಬೇಕು ಎಂಬುದನ್ನು ಇದು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ಮತ್ತು ವ್ಯವಸ್ಥೆಯು ಪ್ರತಿಯೊಂದು ನಿರ್ಧಾರವನ್ನು ರಚನಾತ್ಮಕವಾದ, ಪ್ರಶ್ನಿಸಬಹುದಾದ (queriable) ದಾಖಲೆಯಾಗಿ (trail) ದಾಖಲಿಸುವುದನ್ನು ಇದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಇದು ಸಾಂಪ್ರದಾಯಿಕ ಪ್ರವೇಶ ನಿಯಂತ್ರಣಕ್ಕಿಂತ (access control) ಮೂಲಭೂತವಾಗಿ ಭಿನ್ನವಾಗಿದೆ. ರೋಲ್-ಆಧಾರಿತ (Role-based) ವ್ಯವಸ್ಥೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಬಾಗಿಲಲ್ಲಿ, “ನೀವು ಅಡ್ಮಿನಾ?” ಎಂದು ಕೇಳುತ್ತವೆ ಮತ್ತು ನಂತರ ನಿಮ್ಮನ್ನು ಕಟ್ಟಡದಲ್ಲಿ ಸುತ್ತಾಡಲು ಬಿಡುತ್ತವೆ. ಗೇಟ್ಗಳು ಪ್ರತಿ ತಿರುವಿನಲ್ಲಿಯೂ, “ನೀವು ಈಗ ಈ ನಿರ್ದಿಷ್ಟ ಸ್ವಿಚ್
ಯಾವುದೇ ಕರಗತದಾರರು (caller) ಮಾಸ್ಟರ್ API ಕೀಯನ್ನು ಬಳಸಲಿಲ್ಲ. ಯಾವುದೇ ಬ್ಯಾಕ್ಡೋರ್ ಇರಲಿಲ್ಲ, ನೀತಿಯನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ಯಾವುದೇ ಉನ್ನತ ಮಟ್ಟದ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಇರಲಿಲ್ಲ. ಮನುಷ್ಯನಿಗೆ ಪಾಸ್ವರ್ಡ್ ಮತ್ತು ಬ್ರೌಸರ್ ಇರುವುದರಿಂದ ಸಡಿಲವಾದ ನಿರ್ಬಂಧಗಳನ್ನು ನೀಡಲಿಲ್ಲ. ಏಜೆಂಟ್ಗೆ ಮಾನವನ ಫಿಂಗರ್ಪ್ರಿಂಟ್ ಇಲ್ಲದ ಕಾರಣ ಯಾವುದೇ ಅನಗತ್ಯ ನಿರ್ಬಂಧಗಳನ್ನು ಎದುರಿಸಬೇಕಾಗಿಲ್ಲ. ಗೇಟ್ ಆ ಕ್ರಿಯೆ, ಸಂದರ್ಭ ಮತ್ತು ನಿಯಮಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿತು. ಇಡೀ ವಹಿವಾಟು ಅಷ್ಟೇ ಆಗಿತ್ತು.
ಇದರ ಪರಿಣಾಮವಾಗಿ, ಮನುಷ್ಯ ಅಥವಾ ಯಂತ್ರ ಎಂಬ ಹೊಸ ಕರಗತದಾರರನ್ನು ಸೇರಿಸಲು ಅಕ್ಸೆಸ್ ಲಾಜಿಕ್ ಅನ್ನು ಮರುರೂಪಿಸುವ (refactoring) ಅಗತ್ಯವಿಲ್ಲದ ವ್ಯವಸ್ಥೆಯೊಂದು ನಿರ್ಮಾಣವಾಯಿತು. ನೀವು ನೀತಿಯನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಿದಿರಿ. ಗೇಟ್ ಅದನ್ನು ಜಾರಿಗೆ ತಂದಿತು.
ಉತ್ಪನ್ನದ ಪ್ರಶ್ನೆಯನ್ನು ಮರುಪರಿಶೀಲಿಸುವುದು
ನಿಮ್ಮ ತಂಡವು ಪ್ರಸ್ತುತ ಮನುಷ್ಯ ನಿರ್ಮಿಸಿದ ಉತ್ಪನ್ನಕ್ಕೆ AI ಏಜೆಂಟ್ಗಳನ್ನು ಹೇಗೆ ಸೇರಿಸಬೇಕೆಂದು ಯೋಚಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಬಹುಶಃ ತಪ್ಪು ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ. ತಂಡಗಳು ಸಹಜವಾಗಿಯೇ ಒಂದು API ಅನ್ನು ಪ್ರದರ್ಶಿಸಬೇಕೇ (expose) ಎಂದು ಕೇಳುತ್ತವೆ. ಬದಲಾಗಿ, ಪ್ರತಿಯೊಬ್ಬ ಕರಗತದಾರನಿಗೂ ನಿಯಂತ್ರಿತ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಪದರ (governed execution layer) ಇದೆಯೇ ಎಂದು ಕೇಳಬೇಕು.
ಗೇಟ್ ಇಲ್ಲದ API ಕೇವಲ ಅಗಲವಾದ ಬಾಗಿಲಿನಂತೆ ಇರುತ್ತದೆ. ನಿಮ್ಮ ಆಂತರಿಕ ನೀತಿಗಳು ಕೇವಲ ವಿಸಾರ್ಡ್ ಲಾಜಿಕ್ (wizard logic), ಫಾರ್ಮ್ ವ್ಯಾಲಿಡೇಶನ್ ಮತ್ತು ಮನುಷ್ಯರು ಓದಬಲ್ಲ ಸಹಾಯ ಪಠ್ಯಗಳಲ್ಲಿ (help text) ಮಾತ್ರ ಇದ್ದರೆ, ನೀವು ಪ್ರಕಟಿಸುವ ಯಾವುದೇ ಎಂಡ್ಪಾಯಿಂಟ್ ಸ್ವಾಯತ್ತ ಕರಗತದಾರರಿಗೆ (autonomous callers) ಸುರಕ್ಷಿತವಾಗಿರುವುದಿಲ್ಲ. ಏಜೆಂಟ್ ಅಥವಾ તો ಕೀ ಮೂಲಕ ಅತಿಯಾದ ನಂಬಿಕೆಯನ್ನು ಪಡೆಯುತ್ತದೆ ಅಥವಾ ಚಾಟ್ಬಾಟ್ ರ್ಯಾಪರ್ ಮೂಲಕ ಅಸ್ಥಿರವಾದ ಕಾರ್ಯಗಳನ್ನು ಮಾಡುತ್ತದೆ.
ಮೊದಲು ಗೇಟ್ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಎಂದರೆ ನಿಮ್ಮ ಉತ್ಪನ್ನದಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಅರ್ಥಪೂರ್ಣ ಕ್ರಿಯೆಯನ್ನು ಘೋಷಿತ ಕಾರ್ಯಾಚರಣೆಯಾಗಿ (declared operation) ಪಟ್ಟಿ ಮಾಡುವುದು ಎಂದರ್ಥ. ಇದು ಅನುಮತಿ ಪರಿಶೀಲನೆಯನ್ನು ಬಳಕೆದಾರರ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುವುದನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಇದರಿಂದ ಶೆಲ್ (Shell) ಬಳಕೆದಾರ ಮತ್ತು ಬಾಹ್ಯ ಏಜೆಂಟ್ ಇಬ್ಬರೂ ಒಂದೇ ರೀತಿಯ ರನ್ಟೈಮ್ ಜಾರಿ ಎದುರಿಸುತ್ತಾರೆ. ಇದು ವಿನಾಶಕಾರಿ ಕಾರ್ಯಾಚರಣೆಗಳಿಗಾಗಿ ಅಗತ್ಯ ಬರುವ ಮೊದಲೇ ಸಮ್ಮತಿ ಹುಕ್ಗಳನ್ನು (consent hooks) ಸೇರಿಸುವುದನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಏಜೆಂಟ್ ತಪ್ಪಾದ ಡೇಟಾಸೆಟ್ ಅನ್ನು ಅಳಿಸುವ ನಂತರವಲ್ಲ. ಮತ್ತು ಕರಗತದಾರರು ಕಾರ್ಬನ್ ಅಥವಾ ಸಿಲಿಕಾನ್ ಆಗಿದ್ದಾರೆಯೇ ಎಂಬ ಕಾಳಜಿ ಇಲ್ಲದೆ ಭದ್ರತೆ ಮತ್ತು ಅನುಸರಣೆ ತಂಡಗಳು ಪರಿಶೀಲಿಸಬಹುದಾದ ಆಡಿಟ್ ಟ್ರೈಲ್ಗಳನ್ನು (audit trails) ಸೃಷ್ಟಿಸುವುದನ್ನು ಇದು ಸೂಚಿಸುತ್ತದೆ.
ಇದಕ್ಕೆ ನೈಜವಾದ ವಾಸ್ತುಶಿಲ್ಪದ ಬದಲಾವಣೆ (architectural shift) ಅಗತ್ಯವಿದೆ. ಮಾನವ ಕೇಂದ್ರಿತ ವಿನ್ಯಾಸವು ಲಾಜಿಕನ್ನು ಸಹಾನುಭೂತಿ ಮತ್ತು ಅಡೆತಡೆಗಳಲ್ಲಿ ಸುತ್ತುವರಿಯುತ್ತದೆ. ಏಜೆಂಟ್-ಸಿದ್ಧ ವಿನ್ಯಾಸವು ಸ್ಪಷ್ಟವಾದ, ಯಂತ್ರ-ಓದಬಲ್ಲ ಒಪ್ಪಂದಗಳ (machine-readable contracts) ಮೂಲಕ ಲಾಜಿಕನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ಇಂಟರ್ಫೇಸ್ ನೀತಿಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಮ್ಯಾನಿಫೆಸ್ಟ್ (manifest) ನೀತಿಯಾಗುತ್ತದೆ.
ಈ ಪರಿವರ್ತನೆಯು ಮನುಷ್ಯರನ್ನು ಬದಲಾಯಿಸುವ ಬಗ್ಗೆ ಅಲ್ಲ. ನಿಮ್ಮ ಸಾಫ್ಟ್ವೇರ್ ಈಗ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ರೀತಿಯ ಕರಗತದಾರರನ್ನು ಹೊಂದಿದೆ ಎಂಬುದನ್ನು ಗುರುತಿಸುವುದರ ಬಗ್ಗೆ ಆಗಿದೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಒಂದೇ ರೀತಿಯ ಕಟ್ಟುನಿಟ್ಟಿನ ನಿಯಮಗಳಿಗೆ ಅರ್ಹರು.
ನಿಜವಾದ ಸಾರಾಂಶ
ಕ್ಲಿಕ್ಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ನಿಯಮಕ್ಕಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿ. ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯು ಘೋಷಿತ ಕ್ರಿಯೆಗಳು, ಸಂದರ್ಭೋಚಿತ ಅನುಮತಿಗಳು, ಸಮ್ಮತಿ ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ಹಂಚಿಕೆಯ ಆಡಿಟ್ ಟ್ರೈಲ್ಗಳ ಮೂಲಕ ಪ್ರತಿಯೊಬ್ಬ ಕರಗತದಾರರನ್ನು ನಿಯಂತ್ರಿಸಬಲ್ಲದಾದರೆ, ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಯಾರು ಅಥವಾ ಏನು ಇದ್ದರು ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ. ಮನುಷ್ಯ ಅಥವಾ ಏಜೆಂಟ್, ಅವರೆಲ್ಲರೂ ಒಂದೇ ಗೇಟ್ ಅನ್ನು ಎದುರಿಸುತ್ತಾರೆ. ಮೊದಲು ಗೇಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. API ಕೇವಲ ಒಂದು ಬಾಗಿಲು. ನೀತಿಯೇ ಕೋಣೆಯನ್ನು ಸುರಕ್ಷಿತವಾಗಿಡುತ್ತದೆ.